[PATCH net] netlink: fix out-of-bounds bitmap access clearing stale mc groups

[PATCH net] netlink: fix out-of-bounds bitmap access clearing stale mc groups

[Henry Martin]

netlink_realloc_groups() sizes nlk->groups to the number of groups
that exist at bind/ADD_MEMBERSHIP time.  When more multicast groups
are registered later (e.g. a new genl family), existing sockets keep
their smaller bitmap.

__netlink_clear_multicast_users() however iterates every group of
the departing family and calls netlink_update_socket_mc() for each
socket on mc_list, which does test_bit()/__assign_bit() on group - 1
with no regard to nlk->ngroups.  A stale socket therefore gets bits
read and cleared past its bitmap allocation, corrupting whichever
heap object follows it; the corruption repeats on every family
unregister.

Skip groups that lie beyond the socket's bitmap: such a socket could
never have joined them.

This issue was discovered by Tencent CodeBuddy Security.

Cc: stable@vger.kernel.org
Fixes: b4ff4f0419ae ("[NETLINK]: allocate group bitmaps dynamically")
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
---
 net/netlink/af_netlink.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 9fdf964224ab4..8cc655aa927f1 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1657,6 +1657,12 @@ static void netlink_update_socket_mc(struct netlink_sock *nlk,
 {
 	int old, new = !!is_new, subscriptions;
 
+	/* A socket whose bitmap predates this group can never be a member;
+	 * don't touch bits beyond its allocation.
+	 */
+	if (group - 1 >= nlk->ngroups)
+		return;
+
 	old = test_bit(group - 1, nlk->groups);
 	subscriptions = nlk->subscriptions - old + new;
 	__assign_bit(group - 1, nlk->groups, new);
-- 
2.43.7

Re: [PATCH net] netlink: fix out-of-bounds bitmap access clearing stale mc groups

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net] netlink: fix out-of-bounds bitmap access clearing stale mc groups

[Eric Dumazet]

Le sam. 10 oct. 2026 à 09:26, Henry Martin <bsdhenrymartin@gmail.com> a écrit :
>
> netlink_realloc_groups() sizes nlk->groups to the number of groups
> that exist at bind/ADD_MEMBERSHIP time.  When more multicast groups
> are registered later (e.g. a new genl family), existing sockets keep
> their smaller bitmap.
>
> __netlink_clear_multicast_users() however iterates every group of
> the departing family and calls netlink_update_socket_mc() for each
> socket on mc_list, which does test_bit()/__assign_bit() on group - 1
> with no regard to nlk->ngroups.  A stale socket therefore gets bits
> read and cleared past its bitmap allocation, corrupting whichever
> heap object follows it; the corruption repeats on every family
> unregister.

Do you have a KASAN report, or is this from static analysis only ?

nl_table[NETLINK_GENERIC].groups only grows when group ids no longer
fit in mc_groups_longs * BITS_PER_LONG.

On 64bit, 59 ids are free in the initial bitmap. I count 58 genl
multicast groups in the whole tree, 4 of them using reserved ids
(ctrl, quota, pmcraid, NET_DM), so 54 dynamically allocated ones
if every family was loaded at the same time.

I do not see how a 64bit kernel with in-tree families can get there.
32bit kernels could, and then only from genl_unregister_family(),
i.e. at module unload.

The check itself looks fine and matches what do_one_broadcast()
does, but the changelog should describe the real conditions instead
of suggesting a generic heap corruption.

Unless you have a reproducer, I think this is net-next material,
without the Cc: stable.

>
> Skip groups that lie beyond the socket's bitmap: such a socket could
> never have joined them.
>
> This issue was discovered by Tencent CodeBuddy Security.
>
> Cc: stable@vger.kernel.org
> Fixes: b4ff4f0419ae ("[NETLINK]: allocate group bitmaps dynamically")

This commit did not add netlink_update_socket_mc() or
netlink_clear_multicast_users(). This should be

Fixes: 84659eb529b3 ("[NETLIKN]: Allow removing multicast groups.")

> Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
> ---
>  net/netlink/af_netlink.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 9fdf964224ab4..8cc655aa927f1 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -1657,6 +1657,12 @@ static void netlink_update_socket_mc(struct netlink_sock *nlk,
>  {
>         int old, new = !!is_new, subscriptions;
>
> +       /* A socket whose bitmap predates this group can never be a member;
> +        * don't touch bits beyond its allocation.
> +        */
> +       if (group - 1 >= nlk->ngroups)
> +               return;
> +
>         old = test_bit(group - 1, nlk->groups);
>         subscriptions = nlk->subscriptions - old + new;
>         __assign_bit(group - 1, nlk->groups, new);
> --
> 2.43.7
>

Re: [PATCH net] netlink: fix out-of-bounds bitmap access clearing stale mc groups

[henry martin]

Hi Eric,

Thanks for the careful review, you're right on all points.

This came from static analysis; I don't have a KASAN report.  For
what it's worth, 32-bit x86 cannot provide one either, since
HAVE_ARCH_KASAN there is X86_64-only, and on 64-bit a reproducer
would need an out-of-tree family to push the table past the initial
bitmap.

v2 corrects the Fixes tag to 84659eb529b3, scopes the changelog to
the actual reachability (32-bit kernels with in-tree families, at
module unload) instead of implying generic corruption, and drops
Cc: stable.

Regards,
Henry

Eric Dumazet <edumazet@kernel.org> 于2026年10月10日周六 16:26写道：
>
> Le sam. 10 oct. 2026 à 09:26, Henry Martin <bsdhenrymartin@gmail.com> a écrit :
> >
> > netlink_realloc_groups() sizes nlk->groups to the number of groups
> > that exist at bind/ADD_MEMBERSHIP time.  When more multicast groups
> > are registered later (e.g. a new genl family), existing sockets keep
> > their smaller bitmap.
> >
> > __netlink_clear_multicast_users() however iterates every group of
> > the departing family and calls netlink_update_socket_mc() for each
> > socket on mc_list, which does test_bit()/__assign_bit() on group - 1
> > with no regard to nlk->ngroups.  A stale socket therefore gets bits
> > read and cleared past its bitmap allocation, corrupting whichever
> > heap object follows it; the corruption repeats on every family
> > unregister.
>
> Do you have a KASAN report, or is this from static analysis only ?
>
> nl_table[NETLINK_GENERIC].groups only grows when group ids no longer
> fit in mc_groups_longs * BITS_PER_LONG.
>
> On 64bit, 59 ids are free in the initial bitmap. I count 58 genl
> multicast groups in the whole tree, 4 of them using reserved ids
> (ctrl, quota, pmcraid, NET_DM), so 54 dynamically allocated ones
> if every family was loaded at the same time.
>
> I do not see how a 64bit kernel with in-tree families can get there.
> 32bit kernels could, and then only from genl_unregister_family(),
> i.e. at module unload.
>
> The check itself looks fine and matches what do_one_broadcast()
> does, but the changelog should describe the real conditions instead
> of suggesting a generic heap corruption.
>
> Unless you have a reproducer, I think this is net-next material,
> without the Cc: stable.
>
> >
> > Skip groups that lie beyond the socket's bitmap: such a socket could
> > never have joined them.
> >
> > This issue was discovered by Tencent CodeBuddy Security.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: b4ff4f0419ae ("[NETLINK]: allocate group bitmaps dynamically")
>
> This commit did not add netlink_update_socket_mc() or
> netlink_clear_multicast_users(). This should be
>
> Fixes: 84659eb529b3 ("[NETLIKN]: Allow removing multicast groups.")
>
> > Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
> > ---
> >  net/netlink/af_netlink.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> > index 9fdf964224ab4..8cc655aa927f1 100644
> > --- a/net/netlink/af_netlink.c
> > +++ b/net/netlink/af_netlink.c
> > @@ -1657,6 +1657,12 @@ static void netlink_update_socket_mc(struct netlink_sock *nlk,
> >  {
> >         int old, new = !!is_new, subscriptions;
> >
> > +       /* A socket whose bitmap predates this group can never be a member;
> > +        * don't touch bits beyond its allocation.
> > +        */
> > +       if (group - 1 >= nlk->ngroups)
> > +               return;
> > +
> >         old = test_bit(group - 1, nlk->groups);
> >         subscriptions = nlk->subscriptions - old + new;
> >         __assign_bit(group - 1, nlk->groups, new);
> > --
> > 2.43.7
> >

[PATCH net v2] netlink: fix out-of-bounds bitmap access clearing stale mc groups

[Henry Martin]

netlink_realloc_groups() sizes nlk->groups to the number of groups
that exist at bind/ADD_MEMBERSHIP time.  When more multicast groups
are registered later (e.g. a new genl family), existing sockets keep
their smaller bitmap.

When clearing a multicast group of a departing family,
__netlink_clear_multicast_users() runs netlink_update_socket_mc() on
each socket on mc_list, which does test_bit()/__assign_bit() on
group - 1 with no regard to nlk->ngroups.  Skip groups that lie
beyond the socket's bitmap: such a socket could never have joined
them.  This is the same guard do_one_broadcast() already applies.

With in-tree families the overflow is only reachable on 32-bit
kernels: the ~54 dynamically allocated genl groups fit the initial
64-bit bitmap on 64-bit kernels but exceed the 32-bit one, so the
table can grow there, and a later module unload then touches bits
past the bitmap of stale sockets.

This issue was discovered by Tencent CodeBuddy Security.

Fixes: 84659eb529b3 ("[NETLIKN]: Allow removing multicast groups.")
Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com>
---

v2: Correct the Fixes tag (the clear path was added by 84659eb529b3,
    not by the dynamic bitmap commit), drop Cc: stable and describe
    the actual reachability (32-bit kernels with in-tree families)
    instead of implying generic heap corruption.

 net/netlink/af_netlink.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 9fdf964224ab4..8cc655aa927f1 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1657,6 +1657,12 @@ static void netlink_update_socket_mc(struct netlink_sock *nlk,
 {
 	int old, new = !!is_new, subscriptions;
 
+	/* A socket whose bitmap predates this group can never be a member;
+	 * don't touch bits beyond its allocation.
+	 */
+	if (group - 1 >= nlk->ngroups)
+		return;
+
 	old = test_bit(group - 1, nlk->groups);
 	subscriptions = nlk->subscriptions - old + new;
 	__assign_bit(group - 1, nlk->groups, new);
-- 
2.43.7

Re: [PATCH net v2] netlink: fix out-of-bounds bitmap access clearing stale mc groups

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net v2] netlink: fix out-of-bounds bitmap access clearing stale mc groups

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The code guard is correct.

--

netlink: fix out-of-bounds bitmap access clearing stale mc groups

This patch adds a bounds check to netlink_update_socket_mc().  With it,
__netlink_clear_multicast_users() no longer tests or clears bits past a
socket's nlk->groups bitmap.  Sockets whose bitmap was sized before the
multicast group table grew are skipped for groups beyond nlk->ngroups.

> With in-tree families the overflow is only reachable on 32-bit
> kernels: the ~54 dynamically allocated genl groups fit the initial
> 64-bit bitmap on 64-bit kernels but exceed the 32-bit one, so the
> table can grow there, and a later module unload then touches bits
> past the bitmap of stale sockets.

[Severity: Medium]
The guard looks correct on every architecture.  Is the claim that only
32-bit kernels are affected accurate, though?

genl_allocate_reserve_groups() in net/netlink/genetlink.c does a first-fit
search for a contiguous range.  It grows the table whenever that range ends
past the current capacity:

net/netlink/genetlink.c:genl_allocate_reserve_groups() {
    ...
		if (id + n_groups > mc_groups_longs * BITS_PER_LONG) {
			unsigned long new_longs = mc_groups_longs +
						  BITS_TO_LONGS(n_groups);
    ...
}

genl_unregister_mc_groups() frees IDs with clear_bit(), and nothing
compacts the remaining allocations.  So the number of live groups does not
limit the highest group ID.

The initial bitmap also starts with five bits reserved:

static unsigned long mc_group_start = 0x3 | BIT(GENL_ID_CTRL) |
				      BIT(GENL_ID_VFS_DQUOT) |
				      BIT(GENL_ID_PMCRAID);

That leaves 59 free IDs on a 64-bit kernel, only about 5 more than the ~54
in-tree groups.

With most in-tree families loaded, can an unload/reload sequence fragment
the free space enough to force growth on 64-bit?  For example:

  unload nl80211 (7 groups with CONFIG_NL80211_TESTMODE) and psample
  load psample, which takes part of nl80211's old range
  load nl80211, which no longer fits in any free 7-bit gap

At that point id + n_groups > 64, mc_groups_longs becomes 2, and
__netlink_change_ngroups() raises tbl->groups to 128.  Sockets that
subscribed earlier still have nlk->ngroups == 64 and an 8-byte bitmap.

A later unload of nl80211 then reaches:

genl_unregister_mc_groups()
  __netlink_clear_multicast_users()
    netlink_update_socket_mc()
      test_bit(group - 1, nlk->groups)        /* bit 64 */
      __assign_bit(group - 1, nlk->groups, 0)

Without this patch, that would be an out-of-bounds access on a 64-bit
kernel with only in-tree modules.

The v2 notes say Cc: stable was dropped because of this reachability
description.  Could this paragraph be reworded so backporters don't
conclude that 64-bit kernels are unaffected?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20261013023859.3075601-1-bsdhenrymartin%40gmail.com