From: bot+bpf-ci@kernel.org
To: a.s.protopopov@gmail.com,bpf@vger.kernel.org,linux-security-module@vger.kernel.org,netdev@vger.kernel.org,ast@kernel.org,daniel@iogearbox.net,andrii@kernel.org,eddyz87@gmail.com,memxor@gmail.com,kpsingh@kernel.org,matt@bobrowski.net,john.fastabend@gmail.com,brauner@kernel.org,paul@paul-moore.com,torvalds@linux-foundation.org,edumazet@google.com,kuba@kernel.org,pabeni@redhat.com
Cc: a.s.protopopov@gmail.com,ast@kernel.org,andrii@kernel.org,daniel@iogearbox.net,martin.lau@kernel.org,eddyz87@gmail.com,yonghong.song@linux.dev,mason@kernel.org,ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 2/7] net, bpf: Add a generic netlink hook on msg_rcv
Date: Mon, 31 Aug 2026 12:07:13 +0000 (UTC) [thread overview]
Message-ID: <7396552568004928dc8c7d43c5a8b3de699e698f37f6fc555ea49312a5116a9f@mail.kernel.org> (raw)
In-Reply-To: <20260831110934.241898-3-a.s.protopopov@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6860 bytes --]
> commit 18faf289d6ccb694a2ce1ae68f5c3cf881de2fd4
> Author: Anton Protopopov <a.s.protopopov@gmail.com>
>
> 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 <a.s.protopopov@gmail.com>
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).
> 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?
[ ... ]
> @@ -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
next prev parent reply other threads:[~2026-08-31 12:07 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 11:09 [PATCH bpf-next 0/7] Add new way to add BPF LSM hooks Anton Protopopov
2026-08-31 11:09 ` [PATCH bpf-next 1/7] bpf: Allow BPF LSM programs to attach to more hooks Anton Protopopov
2026-08-31 11:50 ` bot+bpf-ci
2026-08-31 12:48 ` Anton Protopopov
2026-08-31 22:42 ` Paul Moore
2026-09-01 13:36 ` Anton Protopopov
2026-09-01 22:15 ` Paul Moore
2026-09-02 15:31 ` Anton Protopopov
2026-09-02 19:43 ` Paul Moore
2026-08-31 11:09 ` [PATCH bpf-next 2/7] net, bpf: Add a generic netlink hook on msg_rcv Anton Protopopov
2026-08-31 12:07 ` bot+bpf-ci [this message]
2026-08-31 13:22 ` Anton Protopopov
2026-08-31 11:09 ` [PATCH bpf-next 3/7] net, bpf: Add bpf hooks for ethtool control path Anton Protopopov
2026-08-31 11:09 ` [PATCH bpf-next 4/7] selftests/bpf: Extract some helpers from tests to the netlink library Anton Protopopov
2026-08-31 11:09 ` [PATCH bpf-next 5/7] selftests/bpf: Add netdevsim helper library Anton Protopopov
2026-08-31 12:07 ` bot+bpf-ci
2026-08-31 12:55 ` Anton Protopopov
2026-08-31 11:09 ` [PATCH bpf-next 6/7] selftests/bpf: Add tests for the generic netlink BPF hook Anton Protopopov
2026-08-31 12:07 ` bot+bpf-ci
2026-08-31 13:01 ` Anton Protopopov
2026-08-31 11:09 ` [PATCH bpf-next 7/7] selftests/bpf: Add tests for BPF ethtool hooks Anton Protopopov
2026-08-31 12:07 ` bot+bpf-ci
2026-08-31 13:12 ` Anton Protopopov
2026-08-31 22:34 ` [PATCH bpf-next 0/7] Add new way to add BPF LSM hooks Jakub Kicinski
2026-09-01 12:29 ` Anton Protopopov
2026-09-02 0:49 ` Jakub Kicinski
2026-09-02 15:11 ` Anton Protopopov
2026-09-02 18:07 ` Alexei Starovoitov
2026-09-02 19:31 ` Anton Protopopov
2026-09-03 12:16 ` Justin Suess
2026-09-03 13:23 ` Anton Protopopov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7396552568004928dc8c7d43c5a8b3de699e698f37f6fc555ea49312a5116a9f@mail.kernel.org \
--to=bot+bpf-ci@kernel.org \
--cc=a.s.protopopov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=ihor.solodrai@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=mason@kernel.org \
--cc=matt@bobrowski.net \
--cc=memxor@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paul@paul-moore.com \
--cc=torvalds@linux-foundation.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).