Re: [PATCH bpf-next 2/7] net, bpf: Add a generic netlink hook on msg_rcv

On 26/08/31 12:07PM, bot+bpf-ci@kernel.org wrote:

quoted

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).

Yeah, thanks, I will consider this.

quoted

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?

yes

[ ... ]

quoted

@@ -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?

ok

quoted

 	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