Re: [PATCH bpf-next 0/7] Add new way to add BPF LSM hooks

On 26/09/01 05:49PM, Jakub Kicinski wrote:

On Tue, 1 Sep 2026 12:29:15 +0000 Anton Protopopov wrote:

quoted

On 26/08/31 03:34PM, Jakub Kicinski wrote:

quoted

On Mon, 31 Aug 2026 11:09:25 +0000 Anton Protopopov wrote:  

quoted

The BPF LSM programs are allowed to attach to LSM hooks. This enables
operators to mitigate known bugs without a need to reboot or livepatch
machines.  BPF has shown very useful to create such runtime policies.
However, many APIs and parts of kernel aren't covered by existing LSM
hooks and this would be beneficial to extend the coverage.  

Dunno. Do you have any reason to believe that any of the CVEs your LLM
gathered for you here are actually getting exploited? Spot checking 
a few they seem to be mostly driver bugs. What security model do you
have in mind? Untrusted/malicious users with physical NIC access?  

For the untrusted part, here are some existing examples:

  * old untrusted bugs: CVE-2022-50651, CVE-2025-40255
  * "namespace CAP_NET_ADMIN" bugs: CVE-2024-43836, CVE-2025-21921

These span 4 years.

quoted

Also, the recent copy-fail is a stronger example (though not generic
netlink-related).

Yes, if anything it proves that serious security issues are usually
on the datapath for networking, not what you're covering.

I've skimmed through the kernelCTF list. The one ethtool-related CVE
which is addressed by ethtool hooks in this series is CVE-2025-21701
The more prominent producers there are net/sched (CVE-2026-23074,
14 bugs from 2025), nftables (CVE-2026-23111, CVE-2026-23231,
CVE-2026-23272, CVE-2026-23278, CVE-2026-23351, CVE-2026-23392),
rtnetlink (CVE-2026-23209). So bugs do occur in netlink-related paths,
and are used to capture flags.

The generic netlink was chosen as the first one, as the patch is only 10
lines long, but the hook would allow to block ~200 [historical] bugs.
End users might find the new hooks useful when they encounter
new bugs on their systems, which will be blockable by these hooks.
But to do this, hooks should be present before bugs occur.

quoted

The general idea is that we gate the common de-multiplexors such that
not only known bugs, but mainly those which will appear in future are
covered. Rough numbers for coverage: around 5% of known cves are
covered with existing LSM hooks. Another ~5-7% can be covered if we
add netlink-related hooks [this series + net/sched, nftables,
rtnetlink, others smaller]. So, statistically, we know where
bugs had appeared in the past, so we can "predict" where new
will appear. Some of them might be severe, so this would be
good to have hooks in place to be able to "mitigate" them.

Easy to PoC stuff with LLMs these days. I'd like to hear from
an end user who would find these hooks useful, in more detail.
Anyone with an ounce of gray matter will run untrusted workloads
_at least_ in a VM today.

quoted

Just in case, to test this patch locally, I've found around 10 new
ethtool-related bug candidates. I've sent a fix to one, d09c98a6da21
("virtio_net: Fix resize of the RX ring"), which was easy to
reproduce in a VM. Others require specific hardware, though popular,
so I can try to reproduce some, and was planning to do this later.
Of those findings one is unprivileged, it triggers a OOB read.

Please send the fixes along. The hash you mention requires
CAP_NET_ADMIN on a real interface, not a serious security
issue.

I wasn't saying it was. (It was just fun to test the patch with
a bug which wasn't already fixed/published.)