Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive

On Tue, May 26, 2026 at 03:10:45PM +0200, Daniel Borkmann wrote:
>On 5/23/26 3:41 PM, Sasha Levin wrote:
>>On Thu, May 21, 2026 at 11:16:46AM -0700, Song Liu wrote:
>>>On Thu, May 21, 2026 at 8:31 AM Sasha Levin <[email protected]> wrote:
>>>>On Thu, May 21, 2026 at 11:11:16AM +0200, Daniel Borkmann wrote:
>>>>>On 5/19/26 9:57 PM, Sasha Levin wrote:
>>>>>>Sure, this would also work. How do you see this happening? Can we let a certain
>>>>>>user/pid/etc disable the allowlist if they choose to?
>>>>>
>>>>>I don't think we should, given then we're back to square one where root
>>>>>or some other user would be able to just override/bypass an LSM.
>>>>
>>>>killswitch already disables itself when lockdown is active. We can easily
>>>>disable it too when one of the LSMs that cares about this is active.
>>>>
>>>>>[...]
>>>>>>How do you see this working with the allowlist?
>>>>>
>>>>>We should look at the underlying areas where most of the CVE-like fixes
>>>>>took place (these days should be more easily doable given Claude and friends)
>>>>>and based on that either extend ALLOW_ERROR_INJECTION() or (better) create
>>>>>new hooks which BPF LSM can consume where you can then have a policy to reject
>>>>>requests and tighten the attack surface. For example, the AF_ALG stuff you
>>>>
>>>>So we could grow the LSM tentacles deeper into the kernel, and we can see where
>>>>current CVEs are happening, which I suspect is the darker corners of the kernel
>>>>(old unmaintained, rarely used code), but this definitely won't stay the case,
>>>>right? Newer and better LLMs will discover issues elsewhere, and once the low
>>>>hanging fruits are picked off of the current target subsystems, researchers
>>>>will move elsewhere. We will be dooming ourselves to an endless cat and mouse
>>>>game where we go add LSM hooks after some big security issue goes public.
>>>
>>>Do we really need to add new LSM hooks for recent CVEs?
>>>
>>>The LSM hooks are designed to cover all the user-kernel interfaces. Then
>>>with properly designed policies, we should have coverage for potential CVEs.
>>>Existing LSM hooks may not be perfect, but we can improve the hooks,
>>>potentially with the help of smart LLMs, so that these hooks can cover
>>>future security issues. In some cases, we will need new policies, but I don't
>>>think new hooks will be needed for most of these CVEs.
>>
>>Running a quick LLM evaluation on the last ~70 severe CVEs, it seems that about
>>40% is doable with the current hooks.
>
>
>Interesting, do you have some more details in which areas your eval sees new
>lsm hooks missing?

The recent ones I saw fall into about 5 buckets:

1. Kernel-thread / workqueue context: LSM hooks fire but current is a worker,
not the actual attacker. Lots of ksmbd, ceph-msgr, and async cleanup races land
here.

2. Driver: pci_driver.probe, notifier_call_chain, ib_* RDMA callbacks, ndo_*,
bus dispatch tables all sit below any LSM hook. Big chunk of mlx5, RDMA, USB,
i3c, DRM bugs.

3. Per-packet softirq RX: security_sock_rcv_skb only fires inside
sk_filter_trim_cap, which UDP encap_rcv bypasses and L2/bridge protocols never
reach. Covers Bluetooth softirq, bond, IPv6 softirq, TCP-MD5/AO timing leaks,
etc.

4. Netfilter: config path is well-gated via security_netlink_send, but
per-match callbacks, set GC, and flowtable cleanup have nothing. That's where
most of the recent netfilter CVEs actually fire.

5. Crypto subsystem + io_uring per-opcode: crypto/ has zero LSM hooks.

-- 
Thanks,
Sasha