Re: [PATCH bpf-next 2/7] net, bpf: Add a generic netlink hook on msg_rcv
From: bot+bpf-ci@kernel.org
Date: 2026-08-31 12:07:14
Also in:
bpf, netdev
commit 18faf289d6ccb694a2ce1ae68f5c3cf881de2fd4
Author: Anton Protopopov [off-list ref]
net, bpf: Add a generic netlink hook on msg_rcv
Add a new bpf_lsm_genl_family_rcv_msg() BPF hook called from within
the genl_family_rcv_msg() function. The hook sees the genl family,
net, cmd, and nlmsg_flags. As the hook receives all the information
pre-parsed, it is not put into the sleepable list.
There is already an existing LSM hook sitting right at netlink_send,
however, it looks to be too coarse-grained to be used directly. The
netlink_send hook sees the struct sock and struct skb, and thus must
duplicate all the parsing inside BPF. The messages can actually contain
multiple netlink datagrams, dynamic info (see e.g., selinux_nlmsg_lookup()
in context of generic netlink), etc.
The purpose of this hook is to mitigate, in a coarse-grained way,
CVEs reachable via the corresponding control path: genl recvmsg.
While looking at the recent CVEs, robots found ~300 CVEs reachable
via the genl_rcv. We can roughly split them as follows:
* Around 100 are ethtool-related. For more detailed information,
see the following commit which adds even more finer-grained
ethtool hooks.
* Around 100 of the remaining are fully dominated by the new hook.
* Around 100 remaining aren't fully mitigatable, as other control
paths, besides the genl, lead to the buggy code.
To be more precise, the following CVEs are properly mitigated by the
new hook:
* CVE-2021-47518 CVE-2021-47594 CVE-2021-47612 CVE-2022-48687
CVE-2022-49060 CVE-2022-49085 CVE-2022-49300 CVE-2022-49862
CVE-2022-49959 CVE-2022-50656 CVE-2022-50834 CVE-2022-50854
CVE-2023-52698 CVE-2023-52702 CVE-2023-52977 CVE-2023-53113
CVE-2023-53298 CVE-2023-53686 CVE-2023-53843 CVE-2024-26608
CVE-2024-26663 CVE-2024-26754 CVE-2024-26811 CVE-2024-26950
CVE-2024-27025 CVE-2024-27410 CVE-2024-36941 CVE-2024-38562
CVE-2024-43912 CVE-2024-45010 CVE-2024-46711 CVE-2024-49937
CVE-2024-50085 CVE-2025-21706 CVE-2025-21787 CVE-2025-21862
CVE-2025-21875 CVE-2025-21947 CVE-2025-22024 CVE-2025-38184
CVE-2025-38443 CVE-2025-40084 CVE-2025-68263 CVE-2025-68366
CVE-2026-23297 CVE-2026-23436 CVE-2026-43252 CVE-2026-43394
CVE-2026-53128 CVE-2026-53227 CVE-2026-53233 CVE-2026-53238
CVE-2026-53257
The following are mitigated as well, but, theoretically, could
benefit from a finer-grained hook, running after a deeper
parsing/taking locks (this is however out of scope for now to
add finer-grained hooks for each involved subsystems, as, unlike
ethtool, they are more-or-less evenly distributed):
* CVE-2021-47250 CVE-2021-47257 CVE-2021-47554 CVE-2022-48915
CVE-2022-49374 CVE-2022-49505 CVE-2022-50042 CVE-2022-50678
CVE-2023-52845 CVE-2023-53141 CVE-2023-53543 CVE-2023-53652
CVE-2023-54031 CVE-2024-26725 CVE-2024-26951 CVE-2024-42073
CVE-2024-42154 CVE-2024-46676 CVE-2024-47687 CVE-2024-50028
CVE-2025-21973 CVE-2025-38020 CVE-2025-38628 CVE-2025-40254
CVE-2025-40321 CVE-2025-68785 CVE-2025-71091 CVE-2025-71297
CVE-2026-23321 CVE-2026-31707 CVE-2026-31744 CVE-2026-43012
CVE-2026-43467 CVE-2026-43481 CVE-2026-45840 CVE-2026-52978
CVE-2026-52979 CVE-2023-53570 CVE-2024-42114 CVE-2024-53189
CVE-2024-56663 CVE-2025-21909 CVE-2026-53182
Policies for selected CVEs are added in the corresponding
selftests patch.
Signed-off-by: Anton Protopopov [off-list ref]This isn't a bug, but would it be worth trimming the two CVE enumerations or pointing at where the classification lives so the coarse-grained-vs- netlink_send rationale is not outnumbered roughly 3:1 by bare IDs? The selftests patch is already referenced for the policies. The tail of the second CVE list also breaks the ascending order it starts with (CVE-2026-52979 is followed by CVE-2023-53570).
quoted hunk ↗ jump to hunk
diff --git a/include/linux/bpf_lsm.h b/include/linux/bpf_lsm.h index 1e54c7cca27ad..452b9d1d7c494 100644 --- a/include/linux/bpf_lsm.h +++ b/include/linux/bpf_lsm.h@@ -12,6 +12,8 @@ #include <linux/bpf_verifier.h> #include <linux/lsm_hooks.h> +struct genl_family; /* for the bpf_lsm_genl_family_rcv_msg hook */ + #ifdef CONFIG_BPF_LSM extern bool bpf_lsm_initialized __ro_after_init;diff --git a/include/linux/bpf_lsm_hook_defs.h b/include/linux/bpf_lsm_hook_defs.h index 29bc0b514d168..3f57022744a31 100644 --- a/include/linux/bpf_lsm_hook_defs.h +++ b/include/linux/bpf_lsm_hook_defs.h@@ -4,3 +4,10 @@ * This is a set of BPF LSM hooks, which are _not_ fully implemented * as LSM hooks. Thus, they only can be used by BPF LSM programs. */ + +#ifdef CONFIG_NET + +LSM_HOOK(int, 0, genl_family_rcv_msg, const struct genl_family *family, + const struct net *net, u32 cmd, u16 nlmsg_flags) + +#endif /* CONFIG_NET */diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c index 0da39eaed255f..12b4f49c72534 100644 --- a/net/netlink/genetlink.c +++ b/net/netlink/genetlink.c@@ -17,6 +17,7 @@ #include <linux/skbuff.h> #include <linux/mutex.h> #include <linux/bitmap.h> +#include <linux/bpf_lsm.h> #include <linux/rwsem.h> #include <linux/idr.h> #include <net/sock.h>@@ -1161,6 +1162,7 @@ static int genl_family_rcv_msg(const struct genl_family *family, struct genlmsghdr *hdr = nlmsg_data(nlh); struct genl_split_ops op; int hdrlen; + int err; u8 flags;
This isn't a bug, but would int err sit better after u8 flags so the declaration block stays longest-to-shortest, per the reverse xmas tree ordering in Documentation/process/maintainer-netdev.rst? [ ... ]
quoted hunk ↗ jump to hunk
@@ -1187,6 +1189,10 @@ static int genl_family_rcv_msg(const struct genl_family *family, !netlink_ns_capable(skb, net->user_ns, CAP_NET_ADMIN)) return -EPERM; + err = bpf_lsm_hook(genl_family_rcv_msg, family, net, hdr->cmd, nlh->nlmsg_flags); + if (err) + return err; +
This isn't a bug, but could the bpf_lsm_hook() call be wrapped the way the genl_family_rcv_msg_dumpit() / _doit() calls just below it are, so it stays under 80 columns like the rest of the file?
if (flags & GENL_CMD_CAP_DUMP) return genl_family_rcv_msg_dumpit(family, skb, nlh, extack, &op, hdrlen, net);
--- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33386073074