* Re: Re: Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
From: Bezdeka, Florian @ 2026-04-24 6:56 UTC (permalink / raw)
To: willemdebruijn.kernel@gmail.com, 25181214217@stu.xidian.edu.cn
Cc: syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com,
davem@davemloft.net, dsahern@kernel.org, sd@queasysnail.net,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
horms@kernel.org, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com
In-Reply-To: <5eabb1a1.7642.19dbd869da3.Coremail.25181214217@stu.xidian.edu.cn>
On Fri, 2026-04-24 at 11:26 +0800, 王明煜 wrote:
> Hi Sabrina and Jakub,
>
> Before sending out the v3 patch, I synced my tree to the latest mainline and checked the current state of `ip6_make_skb()`.
>
> It turns out that the missing `ip6_cork_release(cork)` in the error path was already naturally resolved by Eric Dumazet's recent refactoring commit:
> b409a7f7176b ("ipv6: colocate inet6_cork in inet_cork_full")
>
> With Eric's changes, the error handling now correctly calls `ip6_cork_release(cork)` if `ip6_setup_cork()` fails, meaning the memory leak is no longer present in the latest tree.
Fine, so mainline is correct now. What about the stable trees? Did you
check them already?
Florian
>
> Please disregard my v1 and v2 patches. I am also telling syzbot to close this report based on Eric's commit.
>
> Thank you all again for your time, the deep code review, and for guiding me to find the true root cause. I learned a huge amount from this discussion!
>
> #syz fix: ipv6: colocate inet6_cork in inet_cork_full
>
> Best regards,
> Mingyu Wang
>
> 2026-04-24 11:16:30 "王明煜" <25181214217@stu.xidian.edu.cn> 写道：
> > Hi,
> >
> > Thank you so much for the review and for pointing me to the correct Fixes tag!
> >
> > You hit the nail on the head regarding `__ip6_append_data()`. After re-evaluating the code path based on your question, I realize my assumption in v2 was incorrect. `__ip6_append_data()` does indeed guarantee that an skb is queued upon success, making the `skb == NULL` path dead code in this context.
> >
> > I traced the `failslab` memory leak back to its true origin: the lockless fast path wrapper `ip6_make_skb()`.
> >
> > Sabrina previously noted that `ip6_setup_cork()` failures correctly release the dst. That is absolutely true for the slow path, where `udp_v6_flush_pending_frames()` eventually handles the cleanup.
> >
> > However, in the fast path, `ip6_make_skb()` calls `ip6_setup_cork()`. Inside `ip6_setup_cork()`, `cork->base.dst` is assigned early. If a subsequent memory allocation fails (e.g., `v6_cork->opt = kzalloc(...)` failing due to failslab), it returns an error. `ip6_make_skb()` then directly returns `ERR_PTR(err)` WITHOUT calling `ip6_cork_release(cork)`.
> >
> > Since `udpv6_sendmsg()` assumes the `dst` reference is stolen by `ip6_make_skb()` and unconditionally jumps to `out_no_dst`, the `dst` is completely leaked.
> >
> > The fix is simply to add `ip6_cork_release(cork)` in the `ip6_setup_cork()` error path inside `ip6_make_skb()`.
> >
> > I will submit a v3 patch shortly addressing this true root cause and using your suggested Fixes tag. Thank you again for steering me in the exact right direction!
> >
> > Best regards,
> > Mingyu Wang
> >
> >
> > > -----原始邮件-----
> > > 发件人: "Willem de Bruijn" <willemdebruijn.kernel@gmail.com>
> > > 发送时间:2026-04-23 22:59:45 (星期四)
> > > 收件人: "Mingyu Wang" <25181214217@stu.xidian.edu.cn>, willemdebruijn.kernel@gmail.com, davem@davemloft.net, dsahern@kernel.org, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com
> > > 抄送: sd@queasysnail.net, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Mingyu Wang" <25181214217@stu.xidian.edu.cn>, syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
> > > 主题: Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
> > >
> > > Mingyu Wang wrote:
> > > > During fuzzing with failslab enabled, a memory leak was observed in the
> > > > IPv6 UDP send path.
> > > >
> > > > The root cause resides in __ip6_make_skb(). In extremely rare cases
> > > > (such as fault injection or specific empty payload conditions),
> > >
> > > Can you elaborate on this? Which fault injection lets
> > > __ip6_append_data succeed without writing data?
> > >
> > > > __ip6_append_data() may succeed but leave the socket's write queue
> > > > empty.
> > > >
> > > > When __ip6_make_skb() is subsequently called, __skb_dequeue(queue)
> > > > returns NULL. The previous logic handled this by executing a 'goto out;',
> > > > which completely bypassed the call to ip6_cork_release(cork).
> > > >
> > > > Since the 'cork' structure actively holds a reference to the routing
> > > > entry (dst_entry) and potentially other allocated options, skipping
> > > > the release cleanly leaks these resources.
> > > >
> > > > Fix this by introducing an 'out_cork_release' label and jumping to it
> > > > when skb is NULL, ensuring the cork state is always properly cleaned up.
> > > > The now-unused 'out' label is also removed to prevent compiler warnings.
> > > >
> > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > >
> > > I think this is
> > >
> > > Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb")
> > >
> > > > Reported-by: syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
> > > > Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
^ permalink raw reply
* Re: Re: Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
From: syzbot @ 2026-04-24 6:56 UTC (permalink / raw)
To: florian.bezdeka
Cc: 25181214217, davem, dsahern, edumazet, florian.bezdeka, horms,
kuba, linux-kernel, netdev, pabeni, sd, willemdebruijn.kernel
In-Reply-To: <68628d54304821fe8410e756ce3f92c60da10e1d.camel@siemens.com>
> On Fri, 2026-04-24 at 11:26 +0800, 王明煜 wrote:
>> Hi Sabrina and Jakub,
>>
>> Before sending out the v3 patch, I synced my tree to the latest mainline and checked the current state of `ip6_make_skb()`.
>>
>> It turns out that the missing `ip6_cork_release(cork)` in the error path was already naturally resolved by Eric Dumazet's recent refactoring commit:
>> b409a7f7176b ("ipv6: colocate inet6_cork in inet_cork_full")
>>
>> With Eric's changes, the error handling now correctly calls `ip6_cork_release(cork)` if `ip6_setup_cork()` fails, meaning the memory leak is no longer present in the latest tree.
>
> Fine, so mainline is correct now. What about the stable trees? Did you
> check them already?
>
> Florian
>
>>
>> Please disregard my v1 and v2 patches. I am also telling syzbot to close this report based on Eric's commit.
>>
>> Thank you all again for your time, the deep code review, and for guiding me to find the true root cause. I learned a huge amount from this discussion!
>>
>> #syz fix: ipv6: colocate inet6_cork in inet_cork_full
>>
>> Best regards,
>> Mingyu Wang
>>
>> 2026-04-24 11:16:30 "王明煜" <25181214217@stu.xidian.edu.cn> 写道：
>> > Hi,
>> >
>> > Thank you so much for the review and for pointing me to the correct Fixes tag!
>> >
>> > You hit the nail on the head regarding `__ip6_append_data()`. After re-evaluating the code path based on your question, I realize my assumption in v2 was incorrect. `__ip6_append_data()` does indeed guarantee that an skb is queued upon success, making the `skb == NULL` path dead code in this context.
>> >
>> > I traced the `failslab` memory leak back to its true origin: the lockless fast path wrapper `ip6_make_skb()`.
>> >
>> > Sabrina previously noted that `ip6_setup_cork()` failures correctly release the dst. That is absolutely true for the slow path, where `udp_v6_flush_pending_frames()` eventually handles the cleanup.
>> >
>> > However, in the fast path, `ip6_make_skb()` calls `ip6_setup_cork()`. Inside `ip6_setup_cork()`, `cork->base.dst` is assigned early. If a subsequent memory allocation fails (e.g., `v6_cork->opt = kzalloc(...)` failing due to failslab), it returns an error. `ip6_make_skb()` then directly returns `ERR_PTR(err)` WITHOUT calling `ip6_cork_release(cork)`.
>> >
>> > Since `udpv6_sendmsg()` assumes the `dst` reference is stolen by `ip6_make_skb()` and unconditionally jumps to `out_no_dst`, the `dst` is completely leaked.
>> >
>> > The fix is simply to add `ip6_cork_release(cork)` in the `ip6_setup_cork()` error path inside `ip6_make_skb()`.
>> >
>> > I will submit a v3 patch shortly addressing this true root cause and using your suggested Fixes tag. Thank you again for steering me in the exact right direction!
>> >
>> > Best regards,
>> > Mingyu Wang
>> >
>> >
>> > > -----原始邮件-----
>> > > 发件人: "Willem de Bruijn" <willemdebruijn.kernel@gmail.com>
>> > > 发送时间:2026-04-23 22:59:45 (星期四)
>> > > 收件人: "Mingyu Wang" <25181214217@stu.xidian.edu.cn>, willemdebruijn.kernel@gmail.com, davem@davemloft.net, dsahern@kernel.org, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com
>> > > 抄送: sd@queasysnail.net, horms@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Mingyu Wang" <25181214217@stu.xidian.edu.cn>, syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
>> > > 主题: Re: [PATCH v2] ipv6: fix memory leak in __ip6_make_skb() when queue is empty
>> > >
>> > > Mingyu Wang wrote:
>> > > > During fuzzing with failslab enabled, a memory leak was observed in the
>> > > > IPv6 UDP send path.
>> > > >
>> > > > The root cause resides in __ip6_make_skb(). In extremely rare cases
>> > > > (such as fault injection or specific empty payload conditions),
>> > >
>> > > Can you elaborate on this? Which fault injection lets
>> > > __ip6_append_data succeed without writing data?
>> > >
>> > > > __ip6_append_data() may succeed but leave the socket's write queue
>> > > > empty.
>> > > >
>> > > > When __ip6_make_skb() is subsequently called, __skb_dequeue(queue)
>> > > > returns NULL. The previous logic handled this by executing a 'goto out;',
>> > > > which completely bypassed the call to ip6_cork_release(cork).
>> > > >
>> > > > Since the 'cork' structure actively holds a reference to the routing
>> > > > entry (dst_entry) and potentially other allocated options, skipping
>> > > > the release cleanly leaks these resources.
>> > > >
>> > > > Fix this by introducing an 'out_cork_release' label and jumping to it
>> > > > when skb is NULL, ensuring the cork state is always properly cleaned up.
>> > > > The now-unused 'out' label is also removed to prevent compiler warnings.
>> > > >
>> > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>> > >
>> > > I think this is
>> > >
>> > > Fixes: 6422398c2ab0 ("ipv6: introduce ipv6_make_skb")
>> > >
>> > > > Reported-by: syzbot+e5d6936b9f4545fd88ab@syzkaller.appspotmail.com
>> > > > Signed-off-by: Mingyu Wang <25181214217@stu.xidian.edu.cn>
I see the command but can't find the corresponding bug.
The email is sent to syzbot+HASH@syzkaller.appspotmail.com address
but the HASH does not correspond to any known bug.
Please double check the address.
^ permalink raw reply
* Re: [PATCH 6/6] arm64: defconfig: Switch Ethernet drivers to modules
From: Linus Walleij @ 2026-04-24 6:56 UTC (permalink / raw)
To: Krzysztof Kozlowski, netdev, Rafał Miłecki
Cc: linux-kernel, linux-arm-kernel, Catalin Marinas, Will Deacon,
Arnd Bergmann, Alexandre Belloni, Drew Fustini, soc
In-Reply-To: <20260412-defconfig-v1-6-a46918286451@oss.qualcomm.com>
On Sun, Apr 12, 2026 at 6:21 PM Krzysztof Kozlowski
<krzysztof.kozlowski@oss.qualcomm.com> wrote:
> Development of Linux kernel progressed over last 10 years and it is easy
> to generate now initramfs for building own kernel, e.g. with Yocto or
> mkosi. Therefore for a few years of reviews on mailing lists, all new
> options enabled in arm64 defconfig were with assumption of having
> initramfs which can load bare minimum of modules to mount filesystem
> from network or disk. Basically network driver as built-in is not
> anymore essential to boot the system, so switch almost all Ethernet
> drivers to modules to save on kernel image size.
>
> Similarly 9P network filesystem for QEMU, especially that testing kernel
> unuder QEMU does not have any size or build process constraints and can
> use initramfs with -initrd argument.
>
> Notable exceptions / diff explanations:
>
> 1. Intel CONFIG_IGB stays as built-in, because of dependency on I2C
> which is also built-in.
>
> 2. CONFIG_BCM4908_ENET and CONFIG_BCMASP appear in the diff, because
> they were default=y (via ARCH_BCMBCA or ARCH_BCM_IPROC).
>
> 3. CONFIG_HNS3_HCLGE and CONFIG_HNS3_ENET are removed, because they are
> default=m.
>
> Moving code to modules has positive impact on kernel image size, thus
> boot time of all users not using above drivers and ability to flash
> fixed-size boot partitions.
>
> Old Image size: 41.11 MiB (Image.gz: 14.69 MiB)
> New Image size: 39.14 MiB (Image.gz: 13.82 MiB)
>
> bloat-o-meter of vmlinux:
> add/remove: 4/6139 grow/shrink: 3/51 up/down: 34547/-2046619 (-2012072)
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
In principle I think this is a sound change.
But looping in netdev and Rafal to touch base on how this might affect
deployed systems. We've had issues with ethernet drivers that don't
really like deferred probe for example.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net] MAINTAINERS: add pcnet_cs to PCMCIA
From: Dominik Brodowski @ 2026-04-24 7:00 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms
In-Reply-To: <20260423220857.3490118-1-kuba@kernel.org>
Am Thu, Apr 23, 2026 at 03:08:57PM -0700 schrieb Jakub Kicinski:
> Per discussion under the Link make sure Dominik can help
> with the patches to drivers/net/ethernet/8390/pcnet_cs.c
>
> cc: linux@dominikbrodowski.net
> Link: https://lore.kernel.org/aeomUh5JqFvkLTH7@scops.dominikbrodowski.net
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
You may also add the other PCMCIA networking drivers there where users
mentioned that they are still in use.
^ permalink raw reply
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: Mathew McBride @ 2026-04-24 7:27 UTC (permalink / raw)
To: kuba; +Cc: netdev, dwmw2, openwrt-devel, guy, philipp_subx, Mathew McBride
In-Reply-To: <20260422041846.2035118-1-kuba@kernel.org>
On Wed, Apr 22, 2026, at 2:18 PM, Jakub Kicinski wrote:
> Remove the ATM protocol modules and PCI/SBUS ATM device drivers
> that are no longer in active use.
>
>
> - solos-pci - Traverse Technologies ADSL2+ PCI
Acked-by: Mathew McBride <matt@traverse.com.au>
We (Traverse) have not made any devices with solos-pci for over 10 years now,
and I assume (based on recent removal trends) that the Geode LX SoC on the
last board that had it (Geos) won't be operable with new kernels for much longer
(IIRC it's feature set isn't quite i586 or i686 level).
I appreciate the folks reaching out about this, however I can
confirm that we are not in a position to provide any further
support for solos-pci devices.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] Add ZTE DingHai Ethernet PF driver
From: han.junyang @ 2026-04-24 7:26 UTC (permalink / raw)
To: andrew
Cc: netdev, davem, andrew+netdev, edumazet, kuba, pabeni, ran.ming,
han.chengfei, zhang.yanze, xu.binbin1, liu.hongxiang
In-Reply-To: <39e6d965-44ee-4edb-a558-859a902ffe54@lunn.ch>
[-- Attachment #1.1.1: Type: text/plain, Size: 1961 bytes --]
Hi Andrew,
Thanks for pointing me to the documentation. I understand now that
net-next is currently closed and I should not have posted new feature
patches during this period. I apologize for the oversight.
I noticed that RFC patches are welcome at any time. Would it be
acceptable if I resubmit this series as RFC in the meantime, so that
I can get early feedback and address any code issues before net-next
reopens?
I will make sure to send the proper [PATCH net-next] version once
the tree reopens.
Thank you for your patience and guidance.
Best regards,
Junyang Han
韩君阳 Hanjunyang
IT开发工程师 IT Development Engineer
ICF四部/无线及算力研究院/系统产品_无线及算力产品经营部 NIV Dept. IV/Wireless Product R＆D Institute/Wireless Product Operation Division
南京市雨花台区宁丹路189号中兴三区A6栋2楼
No.6 HuaShen Road,Yuhuatai District,Nanjing P.R.China
M: +86-18651909520 E: han.junyang@zte.com.cn
www.zte.com.cn
Original
From: AndrewLunn <andrew@lunn.ch>
To: 韩君阳10295231;
Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>;davem@davemloft.net <davem@davemloft.net>;andrew+netdev@lunn.ch <andrew+netdev@lunn.ch>;edumazet@google.com <edumazet@google.com>;kuba@kernel.org <kuba@kernel.org>;pabeni@redhat.com <pabeni@redhat.com>;冉明10033339;韩成飞10333708;张延泽10327417;
Date: 2026年04月23日 00:20
Subject: Re: [PATCH net-next v2 0/3] Add ZTE DingHai Ethernet PF driver
On Wed, Apr 22, 2026 at 10:48:58PM +0800, Junyang Han wrote:
> This series adds initial support for the ZTE DingHai Ethernet controller,
> a high-performance PCIe Ethernet device supporting SR-IOV, hardware
> offloading, and advanced virtualization features.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Please read sections 1.3 and 1.4, particularly the bit in red.
Andrew
---
pw-bot: cr
[-- Attachment #1.1.2: Type: text/html , Size: 9239 bytes --]
[-- Attachment #1.2: 3df7c5f8aa5348cb8a742da79c4c9b64.jpg --]
[-- Type: image/jpeg, Size: 6015 bytes --]
[-- Attachment #1.3: a1e95e1672fd4ba3b589d2354dab315c.jpg --]
[-- Type: image/jpeg, Size: 2064 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] Add ZTE DingHai Ethernet PF driver
From: han.junyang @ 2026-04-24 7:34 UTC (permalink / raw)
To: andrew+netdev
Cc: netdev, davem, andrew+netdev, edumazet, kuba, pabeni, ran.ming,
han.chengfei, zhang.yanze, han.junyang
In-Reply-To: <39e6d965-44ee-4edb-a558-859a902ffe54@lunn.ch>
[-- Attachment #1.1.1: Type: text/plain, Size: 1961 bytes --]
Hi Andrew,
Thanks for pointing me to the documentation. I understand now that
net-next is currently closed and I should not have posted new feature
patches during this period. I apologize for the oversight.
I noticed that RFC patches are welcome at any time. Would it be
acceptable if I resubmit this series as RFC in the meantime, so that
I can get early feedback and address any code issues before net-next
reopens?
I will make sure to send the proper [PATCH net-next] version once
the tree reopens.
Thank you for your patience and guidance.
Best regards,
Junyang Han
韩君阳 Hanjunyang
IT开发工程师 IT Development Engineer
ICF四部/无线及算力研究院/系统产品_无线及算力产品经营部 NIV Dept. IV/Wireless Product R＆D Institute/Wireless Product Operation Division
南京市雨花台区宁丹路189号中兴三区A6栋2楼
No.6 HuaShen Road,Yuhuatai District,Nanjing P.R.China
M: +86-18651909520 E: han.junyang@zte.com.cn
www.zte.com.cn
Original
From: AndrewLunn <andrew@lunn.ch>
To: 韩君阳10295231;
Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>;davem@davemloft.net <davem@davemloft.net>;andrew+netdev@lunn.ch <andrew+netdev@lunn.ch>;edumazet@google.com <edumazet@google.com>;kuba@kernel.org <kuba@kernel.org>;pabeni@redhat.com <pabeni@redhat.com>;冉明10033339;韩成飞10333708;张延泽10327417;
Date: 2026年04月23日 00:20
Subject: Re: [PATCH net-next v2 0/3] Add ZTE DingHai Ethernet PF driver
On Wed, Apr 22, 2026 at 10:48:58PM +0800, Junyang Han wrote:
> This series adds initial support for the ZTE DingHai Ethernet controller,
> a high-performance PCIe Ethernet device supporting SR-IOV, hardware
> offloading, and advanced virtualization features.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Please read sections 1.3 and 1.4, particularly the bit in red.
Andrew
---
pw-bot: cr
[-- Attachment #1.1.2: Type: text/html , Size: 14329 bytes --]
[-- Attachment #1.2: 3df7c5f8aa5348cb8a742da79c4c9b64.jpg --]
[-- Type: image/jpeg, Size: 6015 bytes --]
[-- Attachment #1.3: a1e95e1672fd4ba3b589d2354dab315c.jpg --]
[-- Type: image/jpeg, Size: 2064 bytes --]
^ permalink raw reply
* [syzbot ci] Re: netlink: clean up failed initial dump-start state
From: syzbot ci @ 2026-04-24 7:36 UTC (permalink / raw)
To: davem, edumazet, horms, kees, kuba, kuniyu, linux-kernel,
michael.bommarito, netdev, pabeni, yangfeng
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260423212827.1177552-1-michael.bommarito@gmail.com>
syzbot ci has tested the following series
[v2] netlink: clean up failed initial dump-start state
https://lore.kernel.org/all/20260423212827.1177552-1-michael.bommarito@gmail.com
* [PATCH net-next v2] netlink: clean up failed initial dump-start state
and found the following issues:
* KASAN: slab-use-after-free Read in inet_diag_dump_done
* KASAN: slab-use-after-free Read in netlink_dump_done
* KASAN: slab-use-after-free Read in netlink_rcv_skb
* KASAN: slab-use-after-free Read in rdma_nl_rcv
* KASAN: slab-use-after-free Write in genl_done
Full report is available here:
https://ci.syzbot.org/series/d76773fc-9b84-4669-b27e-791385b0b902
***
KASAN: slab-use-after-free Read in inet_diag_dump_done
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 0b5e8d7999076ac3c490fc18376a404e2626abff
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/cb46a152-33c1-4b5e-bb75-bab2ecb45113/config
syz repro: https://ci.syzbot.org/findings/546e718b-5aa2-4705-85d2-51b88eb73b34/syz_repro
==================================================================
BUG: KASAN: slab-use-after-free in inet_diag_dump_done+0x54/0x90 net/ipv4/inet_diag.c:893
Read of size 8 at addr ffff888110c9a1a0 by task syz.1.18/6001
CPU: 0 UID: 0 PID: 6001 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
inet_diag_dump_done+0x54/0x90 net/ipv4/inet_diag.c:893
netlink_dump_cleanup+0x99/0x120 net/netlink/af_netlink.c:2259
netlink_dump+0xbe9/0xf40 net/netlink/af_netlink.c:2385
__netlink_dump_start+0x5cb/0x7e0 net/netlink/af_netlink.c:2455
netlink_dump_start include/linux/netlink.h:341 [inline]
inet_diag_handler_cmd+0x1e0/0x2c0 net/ipv4/inet_diag.c:978
sock_diag_rcv_msg+0x4cc/0x600 net/core/sock_diag.c:-1
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2565
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1890
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe80d39c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe80e220028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fe80d616090 RCX: 00007fe80d39c819
RDX: 0000000000000000 RSI: 0000200000000200 RDI: 0000000000000003
RBP: 00007fe80d432c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe80d616128 R14: 00007fe80d616090 R15: 00007ffc5edf12b8
</TASK>
Allocated by task 6001:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__kmalloc_cache_noprof+0x31c/0x660 mm/slub.c:5380
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
__inet_diag_dump_start+0x8b/0xbf0 net/ipv4/inet_diag.c:848
__netlink_dump_start+0x469/0x7e0 net/netlink/af_netlink.c:2446
netlink_dump_start include/linux/netlink.h:341 [inline]
inet_diag_handler_cmd+0x1e0/0x2c0 net/ipv4/inet_diag.c:978
sock_diag_rcv_msg+0x4cc/0x600 net/core/sock_diag.c:-1
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2565
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1890
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 5995:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6165 [inline]
kfree+0x1c5/0x640 mm/slub.c:6483
inet_diag_dump_done+0x73/0x90 net/ipv4/inet_diag.c:894
netlink_dump_cleanup+0x99/0x120 net/netlink/af_netlink.c:2259
netlink_dump+0xbe9/0xf40 net/netlink/af_netlink.c:2385
netlink_recvmsg+0x690/0xa50 net/netlink/af_netlink.c:1972
sock_recvmsg_nosec net/socket.c:1078 [inline]
sock_recvmsg+0x172/0x1b0 net/socket.c:1100
____sys_recvmsg+0x1e6/0x4a0 net/socket.c:2812
___sys_recvmsg+0x215/0x590 net/socket.c:2854
__sys_recvmsg net/socket.c:2887 [inline]
__do_sys_recvmsg net/socket.c:2893 [inline]
__se_sys_recvmsg net/socket.c:2890 [inline]
__x64_sys_recvmsg+0x1ba/0x2a0 net/socket.c:2890
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff888110c9a180
which belongs to the cache kmalloc-64 of size 64
The buggy address is located 32 bytes inside of
freed 64-byte region [ffff888110c9a180, ffff888110c9a1c0)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x110c9a
flags: 0x17ff00000000000(node=0|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 017ff00000000000 ffff8881000418c0 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800200020 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 26, tgid 26 (kworker/u9:0), ts 20518825132, free_ts 20518815181
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1868
prep_new_page mm/page_alloc.c:1876 [inline]
get_page_from_freelist+0x24ba/0x2540 mm/page_alloc.c:3956
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5236
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3481
new_slab mm/slub.c:3539 [inline]
refill_objects+0x331/0x3c0 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x2e6/0x730 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
__do_kmalloc_node mm/slub.c:5259 [inline]
__kmalloc_node_noprof+0x577/0x7c0 mm/slub.c:5266
kmalloc_node_noprof include/linux/slab.h:1081 [inline]
__vmalloc_area_node mm/vmalloc.c:3857 [inline]
__vmalloc_node_range_noprof+0x5ef/0x1750 mm/vmalloc.c:4064
__vmalloc_node_noprof+0xc2/0x100 mm/vmalloc.c:4124
alloc_thread_stack_node kernel/fork.c:355 [inline]
dup_task_struct+0x27b/0x800 kernel/fork.c:924
copy_process+0x508/0x3cd0 kernel/fork.c:2050
kernel_clone+0x248/0x8e0 kernel/fork.c:2653
user_mode_thread+0x110/0x180 kernel/fork.c:2729
call_usermodehelper_exec_work+0x5c/0x230 kernel/umh.c:171
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
page last free pid 26 tgid 26 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1412 [inline]
__free_frozen_pages+0xbc7/0xd30 mm/page_alloc.c:2953
__kasan_populate_vmalloc_do mm/kasan/shadow.c:393 [inline]
__kasan_populate_vmalloc+0x1b2/0x1d0 mm/kasan/shadow.c:424
kasan_populate_vmalloc include/linux/kasan.h:580 [inline]
alloc_vmap_area+0xd73/0x14b0 mm/vmalloc.c:2123
__get_vm_area_node+0x1f8/0x300 mm/vmalloc.c:3226
__vmalloc_node_range_noprof+0x36a/0x1750 mm/vmalloc.c:4024
__vmalloc_node_noprof+0xc2/0x100 mm/vmalloc.c:4124
alloc_thread_stack_node kernel/fork.c:355 [inline]
dup_task_struct+0x27b/0x800 kernel/fork.c:924
copy_process+0x508/0x3cd0 kernel/fork.c:2050
kernel_clone+0x248/0x8e0 kernel/fork.c:2653
user_mode_thread+0x110/0x180 kernel/fork.c:2729
call_usermodehelper_exec_work+0x5c/0x230 kernel/umh.c:171
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Memory state around the buggy address:
ffff888110c9a080: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff888110c9a100: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
>ffff888110c9a180: fa fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff888110c9a200: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
ffff888110c9a280: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
==================================================================
***
KASAN: slab-use-after-free Read in netlink_dump_done
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 0b5e8d7999076ac3c490fc18376a404e2626abff
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/cb46a152-33c1-4b5e-bb75-bab2ecb45113/config
syz repro: https://ci.syzbot.org/findings/86101c1f-0d2b-420f-a6bb-cd0260a6b2f5/syz_repro
==================================================================
BUG: KASAN: slab-use-after-free in nlmsg_put_answer include/net/netlink.h:1041 [inline]
BUG: KASAN: slab-use-after-free in netlink_dump_done+0x54d/0x890 net/netlink/af_netlink.c:2228
Read of size 4 at addr ffff8881bb35b9b4 by task syz.0.279/6738
CPU: 0 UID: 0 PID: 6738 Comm: syz.0.279 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
nlmsg_put_answer include/net/netlink.h:1041 [inline]
netlink_dump_done+0x54d/0x890 net/netlink/af_netlink.c:2228
netlink_dump+0xacb/0xf40 net/netlink/af_netlink.c:2365
netlink_recvmsg+0x690/0xa50 net/netlink/af_netlink.c:1972
sock_recvmsg_nosec net/socket.c:1078 [inline]
sock_recvmsg+0x172/0x1b0 net/socket.c:1100
sock_read_iter+0x251/0x320 net/socket.c:1170
new_sync_read fs/read_write.c:493 [inline]
vfs_read+0x582/0xa70 fs/read_write.c:574
ksys_read+0x150/0x270 fs/read_write.c:717
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb5eaf9c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fb5ebe08028 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 00007fb5eb215fa0 RCX: 00007fb5eaf9c819
RDX: 000000000000009b RSI: 00002000000003c0 RDI: 0000000000000004
RBP: 00007fb5eb032c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fb5eb216038 R14: 00007fb5eb215fa0 R15: 00007ffc181c9c68
</TASK>
Allocated by task 6739:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4538 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
kmem_cache_alloc_node_noprof+0x384/0x690 mm/slub.c:4918
__alloc_skb+0x1d0/0x7d0 net/core/skbuff.c:702
netlink_sendmsg+0x5d4/0xb40 net/netlink/af_netlink.c:1865
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 6739:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6165 [inline]
kmem_cache_free+0x189/0x630 mm/slub.c:6295
netlink_unicast_kernel net/netlink/af_netlink.c:1315 [inline]
netlink_unicast+0x817/0x9b0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1890
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff8881bb35b980
which belongs to the cache skbuff_head_cache of size 240
The buggy address is located 52 bytes inside of
freed 240-byte region [ffff8881bb35b980, ffff8881bb35ba70)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff8881bb35b200 pfn:0x1bb35a
head: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x57ff00000000240(workingset|head|node=1|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 057ff00000000240 ffff888160417a00 ffff88816041db88 ffffea0005cae210
raw: ffff8881bb35b200 000000080015000f 00000000f5000000 0000000000000000
head: 057ff00000000240 ffff888160417a00 ffff88816041db88 ffffea0005cae210
head: ffff8881bb35b200 000000080015000f 00000000f5000000 0000000000000000
head: 057ff00000000001 ffffffffffffff81 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000002
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 1, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5552, tgid 5552 (dhcpcd), ts 37959428622, free_ts 37819349212
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1868
prep_new_page mm/page_alloc.c:1876 [inline]
get_page_from_freelist+0x24ba/0x2540 mm/page_alloc.c:3956
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5236
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3481
new_slab mm/slub.c:3539 [inline]
refill_objects+0x331/0x3c0 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x2e6/0x730 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
kmem_cache_alloc_node_noprof+0x441/0x690 mm/slub.c:4918
__alloc_skb+0x1d0/0x7d0 net/core/skbuff.c:702
alloc_skb include/linux/skbuff.h:1383 [inline]
alloc_skb_with_frags+0xc8/0x760 net/core/skbuff.c:6763
sock_alloc_send_pskb+0x878/0x990 net/core/sock.c:2995
unix_dgram_sendmsg+0x460/0x18e0 net/unix/af_unix.c:2127
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
sock_write_iter+0x49b/0x4f0 net/socket.c:1195
do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1
vfs_writev+0x33c/0x990 fs/read_write.c:1059
do_writev+0x154/0x2e0 fs/read_write.c:1105
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
page last free pid 5552 tgid 5552 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1412 [inline]
__free_frozen_pages+0xbc7/0xd30 mm/page_alloc.c:2953
mm_free_pgd kernel/fork.c:585 [inline]
__mmdrop+0xb5/0x750 kernel/fork.c:727
mmdrop include/linux/sched/mm.h:55 [inline]
mmdrop_sched include/linux/sched/mm.h:83 [inline]
mmdrop_lazy_tlb_sched include/linux/sched/mm.h:110 [inline]
finish_task_switch+0x449/0x920 kernel/sched/core.c:5180
context_switch kernel/sched/core.c:5301 [inline]
__schedule+0x15e5/0x52d0 kernel/sched/core.c:6911
__schedule_loop kernel/sched/core.c:6993 [inline]
schedule+0x164/0x360 kernel/sched/core.c:7008
schedule_hrtimeout_range_clock+0x1e7/0x320 kernel/time/sleep_timeout.c:207
poll_schedule_timeout+0xd0/0x1a0 fs/select.c:241
do_poll fs/select.c:954 [inline]
do_sys_poll+0x7e8/0x1120 fs/select.c:1004
__do_sys_ppoll fs/select.c:1106 [inline]
__se_sys_ppoll+0x209/0x2b0 fs/select.c:1086
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff8881bb35b880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc
ffff8881bb35b900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8881bb35b980: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881bb35ba00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc
ffff8881bb35ba80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
***
KASAN: slab-use-after-free Read in netlink_rcv_skb
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 0b5e8d7999076ac3c490fc18376a404e2626abff
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/cb46a152-33c1-4b5e-bb75-bab2ecb45113/config
syz repro: https://ci.syzbot.org/findings/584da8f1-c227-495f-aa8f-564d0bcc212f/syz_repro
==================================================================
BUG: KASAN: slab-use-after-free in netlink_rcv_skb+0x395/0x4b0 net/netlink/af_netlink.c:2574
Read of size 4 at addr ffff8881753dc700 by task syz.2.60/6106
CPU: 1 UID: 0 PID: 6106 Comm: syz.2.60 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
netlink_rcv_skb+0x395/0x4b0 net/netlink/af_netlink.c:2574
nfnetlink_rcv+0x2c0/0x27b0 net/netfilter/nfnetlink.c:669
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1890
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4d3a59c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4d3b3b8028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f4d3a816090 RCX: 00007f4d3a59c819
RDX: 0000000000000080 RSI: 0000200000000100 RDI: 0000000000000003
RBP: 00007f4d3a632c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f4d3a816128 R14: 00007f4d3a816090 R15: 00007ffd69453fe8
</TASK>
Allocated by task 6106:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4538 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
kmem_cache_alloc_node_noprof+0x384/0x690 mm/slub.c:4918
kmalloc_reserve net/core/skbuff.c:613 [inline]
__alloc_skb+0x27d/0x7d0 net/core/skbuff.c:713
netlink_sendmsg+0x5d4/0xb40 net/netlink/af_netlink.c:1865
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 6106:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6165 [inline]
kmem_cache_free+0x189/0x630 mm/slub.c:6295
skb_kfree_head net/core/skbuff.c:1087 [inline]
skb_free_head net/core/skbuff.c:1101 [inline]
skb_release_data+0x81c/0xa80 net/core/skbuff.c:1128
skb_release_all net/core/skbuff.c:1203 [inline]
__kfree_skb+0x5d/0x210 net/core/skbuff.c:1217
netlink_dump+0xbe9/0xf40 net/netlink/af_netlink.c:2385
__netlink_dump_start+0x5cb/0x7e0 net/netlink/af_netlink.c:2455
netlink_dump_start include/linux/netlink.h:341 [inline]
ip_set_dump+0x15b/0x1f0 net/netfilter/ipset/ip_set_core.c:1717
nfnetlink_rcv_msg+0xc00/0x12c0 net/netfilter/nfnetlink.c:302
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2565
nfnetlink_rcv+0x2c0/0x27b0 net/netfilter/nfnetlink.c:669
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1890
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff8881753dc700
which belongs to the cache skbuff_small_head of size 704
The buggy address is located 0 bytes inside of
freed 704-byte region [ffff8881753dc700, ffff8881753dc9c0)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff8881753dfb80 pfn:0x1753dc
head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x57ff00000000240(workingset|head|node=1|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 057ff00000000240 ffff888160419140 ffffea0005d40010 ffffea0006e4bb10
raw: ffff8881753dfb80 000000080012000f 00000000f5000000 0000000000000000
head: 057ff00000000240 ffff888160419140 ffffea0005d40010 ffffea0006e4bb10
head: ffff8881753dfb80 000000080012000f 00000000f5000000 0000000000000000
head: 057ff00000000002 ffffffffffffff01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 2, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5839, tgid 5839 (syz-executor), ts 58323168360, free_ts 35463810625
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1868
prep_new_page mm/page_alloc.c:1876 [inline]
get_page_from_freelist+0x24ba/0x2540 mm/page_alloc.c:3956
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5236
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3481
new_slab mm/slub.c:3539 [inline]
refill_objects+0x331/0x3c0 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x2e6/0x730 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
kmem_cache_alloc_node_noprof+0x441/0x690 mm/slub.c:4918
kmalloc_reserve net/core/skbuff.c:613 [inline]
__alloc_skb+0x27d/0x7d0 net/core/skbuff.c:713
alloc_skb include/linux/skbuff.h:1383 [inline]
nlmsg_new include/net/netlink.h:1055 [inline]
inet6_netconf_notify_devconf+0x10f/0x1d0 net/ipv6/addrconf.c:592
__addrconf_sysctl_register+0x45a/0x4d0 net/ipv6/addrconf.c:7338
addrconf_sysctl_register+0x168/0x1c0 net/ipv6/addrconf.c:7375
ipv6_add_dev+0xd26/0x13a0 net/ipv6/addrconf.c:459
addrconf_notify+0x771/0x1050 net/ipv6/addrconf.c:3654
notifier_call_chain+0x1be/0x400 kernel/notifier.c:85
call_netdevice_notifiers_extack net/core/dev.c:2287 [inline]
call_netdevice_notifiers net/core/dev.c:2301 [inline]
register_netdevice+0x173a/0x1cf0 net/core/dev.c:11462
register_netdev+0x40/0x60 net/core/dev.c:11540
page last free pid 5256 tgid 5256 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1412 [inline]
__free_frozen_pages+0xbc7/0xd30 mm/page_alloc.c:2953
__slab_free+0x263/0x2b0 mm/slub.c:5573
qlink_free mm/kasan/quarantine.c:163 [inline]
qlist_free_all+0x99/0x100 mm/kasan/quarantine.c:179
kasan_quarantine_reduce+0x148/0x160 mm/kasan/quarantine.c:286
__kasan_slab_alloc+0x22/0x80 mm/kasan/common.c:350
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4538 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
kmem_cache_alloc_node_noprof+0x384/0x690 mm/slub.c:4918
__alloc_skb+0x1d0/0x7d0 net/core/skbuff.c:702
netlink_sendmsg+0x5d4/0xb40 net/netlink/af_netlink.c:1865
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff8881753dc600: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff8881753dc680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8881753dc700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881753dc780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881753dc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
***
KASAN: slab-use-after-free Read in rdma_nl_rcv
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 0b5e8d7999076ac3c490fc18376a404e2626abff
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/cb46a152-33c1-4b5e-bb75-bab2ecb45113/config
syz repro: https://ci.syzbot.org/findings/5022ea7e-727a-4c37-8ae5-0c7f5d43822c/syz_repro
==================================================================
BUG: KASAN: slab-use-after-free in rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:248 [inline]
BUG: KASAN: slab-use-after-free in rdma_nl_rcv+0x867/0xa10 drivers/infiniband/core/netlink.c:259
Read of size 4 at addr ffff8881a4036a00 by task syz.1.18/5983
CPU: 1 UID: 0 PID: 5983 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:248 [inline]
rdma_nl_rcv+0x867/0xa10 drivers/infiniband/core/netlink.c:259
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1890
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f737179c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f73725f1028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f7371a16090 RCX: 00007f737179c819
RDX: 0000000020008000 RSI: 0000200000000000 RDI: 0000000000000003
RBP: 00007f7371832c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f7371a16128 R14: 00007f7371a16090 R15: 00007ffeff477318
</TASK>
Allocated by task 5983:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
unpoison_slab_object mm/kasan/common.c:340 [inline]
__kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366
kasan_slab_alloc include/linux/kasan.h:253 [inline]
slab_post_alloc_hook mm/slub.c:4538 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
kmem_cache_alloc_node_noprof+0x384/0x690 mm/slub.c:4918
kmalloc_reserve net/core/skbuff.c:613 [inline]
__alloc_skb+0x27d/0x7d0 net/core/skbuff.c:713
netlink_sendmsg+0x5d4/0xb40 net/netlink/af_netlink.c:1865
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 5983:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6165 [inline]
kmem_cache_free+0x189/0x630 mm/slub.c:6295
skb_kfree_head net/core/skbuff.c:1087 [inline]
skb_free_head net/core/skbuff.c:1101 [inline]
skb_release_data+0x81c/0xa80 net/core/skbuff.c:1128
skb_release_all net/core/skbuff.c:1203 [inline]
__kfree_skb+0x5d/0x210 net/core/skbuff.c:1217
netlink_dump+0xbe9/0xf40 net/netlink/af_netlink.c:2385
__netlink_dump_start+0x5cb/0x7e0 net/netlink/af_netlink.c:2455
netlink_dump_start include/linux/netlink.h:341 [inline]
rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:190 [inline]
rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
rdma_nl_rcv+0x78b/0xa10 drivers/infiniband/core/netlink.c:259
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1890
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff8881a4036a00
which belongs to the cache skbuff_small_head of size 704
The buggy address is located 0 bytes inside of
freed 704-byte region [ffff8881a4036a00, ffff8881a4036cc0)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1a4034
head: order:2 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
flags: 0x57ff00000000040(head|node=1|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 057ff00000000040 ffff888160416c80 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800120012 00000000f5000000 0000000000000000
head: 057ff00000000040 ffff888160416c80 dead000000000100 dead000000000122
head: 0000000000000000 0000000800120012 00000000f5000000 0000000000000000
head: 057ff00000000002 ffffffffffffff01 00000000ffffffff 00000000ffffffff
head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000004
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 2, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5931, tgid 5931 (syz-executor), ts 61730251789, free_ts 58082311635
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1868
prep_new_page mm/page_alloc.c:1876 [inline]
get_page_from_freelist+0x24ba/0x2540 mm/page_alloc.c:3956
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5236
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3481
new_slab mm/slub.c:3539 [inline]
refill_objects+0x331/0x3c0 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x2e6/0x730 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
kmem_cache_alloc_node_noprof+0x441/0x690 mm/slub.c:4918
kmalloc_reserve net/core/skbuff.c:613 [inline]
__alloc_skb+0x27d/0x7d0 net/core/skbuff.c:713
alloc_skb include/linux/skbuff.h:1383 [inline]
nlmsg_new include/net/netlink.h:1055 [inline]
netlink_ack+0x146/0xa50 net/netlink/af_netlink.c:2502
netlink_rcv_skb+0x2b6/0x4b0 net/netlink/af_netlink.c:2571
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1890
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
__sys_sendto+0x672/0x710 net/socket.c:2206
__do_sys_sendto net/socket.c:2213 [inline]
__se_sys_sendto net/socket.c:2209 [inline]
__x64_sys_sendto+0xde/0x100 net/socket.c:2209
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5865 tgid 5865 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1412 [inline]
__free_frozen_pages+0xbc7/0xd30 mm/page_alloc.c:2953
vfree+0x1d1/0x2f0 mm/vmalloc.c:3472
kcov_put kernel/kcov.c:442 [inline]
kcov_close+0x28/0x50 kernel/kcov.c:543
__fput+0x44f/0xa70 fs/file_table.c:469
task_work_run+0x1d9/0x270 kernel/task_work.c:233
exit_task_work include/linux/task_work.h:40 [inline]
do_exit+0x70f/0x22c0 kernel/exit.c:976
do_group_exit+0x21b/0x2d0 kernel/exit.c:1118
get_signal+0x1284/0x1330 kernel/signal.c:3034
arch_do_signal_or_restart+0xbc/0x830 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
exit_to_user_mode_loop+0x86/0x480 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Memory state around the buggy address:
ffff8881a4036900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881a4036980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8881a4036a00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881a4036a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8881a4036b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
***
KASAN: slab-use-after-free Write in genl_done
tree: torvalds
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux
base: 0b5e8d7999076ac3c490fc18376a404e2626abff
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/cb46a152-33c1-4b5e-bb75-bab2ecb45113/config
syz repro: https://ci.syzbot.org/findings/5600aed0-e730-40d2-943c-84f525e427c6/syz_repro
==================================================================
BUG: KASAN: slab-use-after-free in genl_done+0x76/0x220 net/netlink/genetlink.c:1038
Write of size 8 at addr ffff88811b796788 by task syz.0.34/6007
CPU: 0 UID: 0 PID: 6007 Comm: syz.0.34 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_address_description+0x55/0x1e0 mm/kasan/report.c:378
print_report+0x58/0x70 mm/kasan/report.c:482
kasan_report+0x117/0x150 mm/kasan/report.c:595
genl_done+0x76/0x220 net/netlink/genetlink.c:1038
netlink_dump_cleanup+0x99/0x120 net/netlink/af_netlink.c:2259
netlink_dump+0xbe9/0xf40 net/netlink/af_netlink.c:2385
__netlink_dump_start+0x5cb/0x7e0 net/netlink/af_netlink.c:2455
genl_family_rcv_msg_dumpit+0x213/0x310 net/netlink/genetlink.c:1075
genl_family_rcv_msg net/netlink/genetlink.c:1191 [inline]
genl_rcv_msg+0x5e8/0x7a0 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2565
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1890
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fe33999c819
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fe33a8da028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fe339c16090 RCX: 00007fe33999c819
RDX: 0000000000000000 RSI: 0000200000000040 RDI: 0000000000000004
RBP: 00007fe339a32c91 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fe339c16128 R14: 00007fe339c16090 R15: 00007ffe15e728b8
</TASK>
Allocated by task 6007:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
poison_kmalloc_redzone mm/kasan/common.c:398 [inline]
__kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415
kasan_kmalloc include/linux/kasan.h:263 [inline]
__kmalloc_cache_noprof+0x31c/0x660 mm/slub.c:5380
kmalloc_noprof include/linux/slab.h:950 [inline]
genl_dumpit_info_alloc net/netlink/genetlink.c:915 [inline]
genl_start+0x1c9/0x6c0 net/netlink/genetlink.c:985
__netlink_dump_start+0x469/0x7e0 net/netlink/af_netlink.c:2446
genl_family_rcv_msg_dumpit+0x213/0x310 net/netlink/genetlink.c:1075
genl_family_rcv_msg net/netlink/genetlink.c:1191 [inline]
genl_rcv_msg+0x5e8/0x7a0 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2565
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1890
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x972/0x9f0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 6006:
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2685 [inline]
slab_free mm/slub.c:6165 [inline]
kfree+0x1c5/0x640 mm/slub.c:6483
genl_dumpit_info_free net/netlink/genetlink.c:920 [inline]
genl_done+0x1c8/0x220 net/netlink/genetlink.c:1046
netlink_dump_cleanup+0x99/0x120 net/netlink/af_netlink.c:2259
netlink_dump+0xbe9/0xf40 net/netlink/af_netlink.c:2385
netlink_recvmsg+0x690/0xa50 net/netlink/af_netlink.c:1972
sock_recvmsg_nosec net/socket.c:1078 [inline]
sock_recvmsg+0x172/0x1b0 net/socket.c:1100
sock_read_iter+0x251/0x320 net/socket.c:1170
new_sync_read fs/read_write.c:493 [inline]
vfs_read+0x582/0xa70 fs/read_write.c:574
ksys_read+0x150/0x270 fs/read_write.c:717
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ffff88811b796700
which belongs to the cache kmalloc-192 of size 192
The buggy address is located 136 bytes inside of
freed 192-byte region [ffff88811b796700, ffff88811b7967c0)
The buggy address belongs to the physical page:
page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11b796
flags: 0x17ff00000000000(node=0|zone=2|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 017ff00000000000 ffff8881000413c0 dead000000000100 dead000000000122
raw: 0000000000000000 0000000800100010 00000000f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0xd2cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 5922, tgid 5922 (syz-executor), ts 64892204905, free_ts 61400269257
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x231/0x280 mm/page_alloc.c:1868
prep_new_page mm/page_alloc.c:1876 [inline]
get_page_from_freelist+0x24ba/0x2540 mm/page_alloc.c:3956
__alloc_frozen_pages_noprof+0x18d/0x380 mm/page_alloc.c:5236
alloc_slab_page mm/slub.c:3292 [inline]
allocate_slab+0x77/0x660 mm/slub.c:3481
new_slab mm/slub.c:3539 [inline]
refill_objects+0x331/0x3c0 mm/slub.c:7175
refill_sheaf mm/slub.c:2812 [inline]
__pcs_replace_empty_main+0x2e6/0x730 mm/slub.c:4615
alloc_from_pcs mm/slub.c:4717 [inline]
slab_alloc_node mm/slub.c:4851 [inline]
__do_kmalloc_node mm/slub.c:5259 [inline]
__kmalloc_node_noprof+0x577/0x7c0 mm/slub.c:5266
kmalloc_node_noprof include/linux/slab.h:1081 [inline]
alloc_slab_obj_exts+0xbf/0x250 mm/slub.c:2167
__memcg_slab_post_alloc_hook+0x5c4/0xe80 mm/memcontrol.c:3466
memcg_slab_post_alloc_hook mm/slub.c:2457 [inline]
slab_post_alloc_hook mm/slub.c:4549 [inline]
slab_alloc_node mm/slub.c:4866 [inline]
kmem_cache_alloc_noprof+0x347/0x650 mm/slub.c:4873
vm_area_dup+0x2b/0x680 mm/vma_init.c:123
dup_mmap+0x8b1/0x1d90 mm/mmap.c:1786
dup_mm kernel/fork.c:1531 [inline]
copy_mm+0x13b/0x4a0 kernel/fork.c:1583
copy_process+0x18b6/0x3cd0 kernel/fork.c:2223
kernel_clone+0x248/0x8e0 kernel/fork.c:2653
__do_sys_clone kernel/fork.c:2794 [inline]
__se_sys_clone kernel/fork.c:2778 [inline]
__x64_sys_clone+0x1b6/0x230 kernel/fork.c:2778
page last free pid 10 tgid 10 stack trace:
reset_page_owner include/linux/page_owner.h:25 [inline]
__free_pages_prepare mm/page_alloc.c:1412 [inline]
__free_frozen_pages+0xbc7/0xd30 mm/page_alloc.c:2953
kasan_depopulate_vmalloc_pte+0x6d/0x90 mm/kasan/shadow.c:484
apply_to_pte_range mm/memory.c:3322 [inline]
apply_to_pmd_range mm/memory.c:3366 [inline]
apply_to_pud_range mm/memory.c:3402 [inline]
apply_to_p4d_range mm/memory.c:3438 [inline]
__apply_to_page_range+0xbdc/0x1420 mm/memory.c:3474
__kasan_release_vmalloc+0xa2/0xd0 mm/kasan/shadow.c:602
kasan_release_vmalloc include/linux/kasan.h:593 [inline]
kasan_release_vmalloc_node mm/vmalloc.c:2284 [inline]
purge_vmap_node+0x220/0x960 mm/vmalloc.c:2306
__purge_vmap_area_lazy+0x779/0xb70 mm/vmalloc.c:2396
drain_vmap_area_work+0x27/0x40 mm/vmalloc.c:2430
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
Memory state around the buggy address:
ffff88811b796680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88811b796700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88811b796780: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
^
ffff88811b796800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88811b796880: 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc
==================================================================
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* Re: [PATCH net v2] net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind
From: Rémi Denis-Courmont @ 2026-04-24 8:01 UTC (permalink / raw)
To: Morduan Zang, Remi Denis-Courmont, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, linux-kernel, syzkaller-bugs,
syzbot+706f5eb79044e686c794, zhanjun
In-Reply-To: <87A8960A2045AF3C+20260423010557.138124-1-zhangdandan@uniontech.com>
Le 23 avril 2026 04:05:57 GMT+03:00, Morduan Zang <zhangdandan@uniontech.com> a écrit :
>syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via
>pn_socket_autobind():
>
> kernel BUG at net/phonet/socket.c:213!
> RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline]
> RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421
> Call Trace:
> sock_sendmsg_nosec+0x112/0x150 net/socket.c:797
> __sock_sendmsg net/socket.c:812 [inline]
> __sys_sendto+0x402/0x590 net/socket.c:2280
> ...
>
>pn_socket_autobind() calls pn_socket_bind() with port 0 and, on
>-EINVAL, assumes the socket was already bound and asserts that the
>port is non-zero:
>
> err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn));
> if (err != -EINVAL)
> return err;
> BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
> return 0; /* socket was already bound */
>
>However pn_socket_bind() also returns -EINVAL when sk->sk_state is not
>TCP_CLOSE, even when the socket has never been bound and pn_port() is
>still 0. In that case the BUG_ON() fires and panics the kernel from a
>user-triggerable path.
>
>Treat the "bind returned -EINVAL but pn_port() is still 0" case as a
>regular error and propagate -EINVAL to the caller instead of crashing.
>Existing callers already translate a non-zero return from
>pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here
>only changes behaviour from panic to a normal errno.
>
>Fixes: ba113a94b750 ("Phonet: common socket glue")
>Reported-by: syzbot+706f5eb79044e686c794@syzkaller.appspotmail.com
>Closes: https://syzkaller.appspot.com/bug?extid=706f5eb79044e686c794
>Suggested-by: Remi Denis-Courmont <courmisch@gmail.com>
>Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
>Signed-off-by: zhanjun <zhanjun@uniontech.com>
Acked-by: Rémi Denis-Courmont <remi@remlab.net>
^ permalink raw reply
* Re: [PATCH v3 net 01/11] octeontx2-af: npc: cn20k: Propagate MCAM key-type errors on cn20k
From: Ratheesh Kannoth @ 2026-04-24 8:21 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, davem, edumazet, kuba, pabeni, andrew+netdev,
Suman Ghosh, Dan Carpenter
In-Reply-To: <20260423104317.2707923-2-rkannoth@marvell.com>
On 2026-04-23 at 16:13:07, Ratheesh Kannoth (rkannoth@marvell.com) wrote:
> npc_mcam_idx_2_key_type() can fail; callers used to ignore it and still
> used kw_type when enabling, configuring, copying, and reading MCAM
> entries. That could program or decode hardware with an undefined key
> type.
>
> Return -EINVAL when key-type lookup fails. Return -EINVAL from
> npc_cn20k_copy_mcam_entry() when src and dest key types differ instead
> of failing silently.
>
> Change npc_cn20k_{enable,config,copy,read}_mcam_entry() to return int on
> success or error. Thread those errors through the cn20k MCAM write and
> read mbox handlers, the cn20k baseline steer read path, NPC defrag
> move (disable/copy/enable with dev_err and -EFAULT), and the DMAC
> update path in rvu_npc_fs.c.
>
> Make npc_copy_mcam_entry() return int so the cn20k branch can return
> npc_cn20k_copy_mcam_entry() without a void/int mismatch, and fail
> NPC_MCAM_SHIFT_ENTRY when copy fails.
>
> Cc: Suman Ghosh <sumang@marvell.com>
> Cc: Dan Carpenter <error27@gmail.com>
> Fixes: 6d1e70282f76 ("octeontx2-af: npc: cn20k: Use common APIs")
> Link: https://lore.kernel.org/netdev/adiQJvuKlEhq2ILx@stanley.mountain/
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
> ---
> .../ethernet/marvell/octeontx2/af/cn20k/npc.c | 109 ++++++++++++------
> .../ethernet/marvell/octeontx2/af/cn20k/npc.h | 20 ++--
> .../ethernet/marvell/octeontx2/af/rvu_npc.c | 18 ++-
> .../marvell/octeontx2/af/rvu_npc_fs.c | 20 ++--
> 4 files changed, 111 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> index 7291fdb89b03..49b5cd2838b5 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> index 7291fdb89b03..49b5cd2838b5 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
[ ... ]
> @@ -3607,9 +3627,30 @@ int npc_defrag_move_vdx_to_free(struct rvu *rvu,
> NPC_AF_CN20K_MCAMEX_BANKX_STAT_EXT(midx,
> bank));
>
> - npc_cn20k_enable_mcam_entry(rvu, blkaddr, old_midx, false);
> - npc_cn20k_copy_mcam_entry(rvu, blkaddr, old_midx, new_midx);
> - npc_cn20k_enable_mcam_entry(rvu, blkaddr, new_midx, true);
> + /* If bug happened during copy/enable mcam, then there is a bug in allocation
> + * algorithm itself. There is no point in rewinding and returning, as it
> + * will face further issue. Return error after printing error
> + */
> + if (npc_cn20k_enable_mcam_entry(rvu, blkaddr, old_midx, false)) {
> + dev_err(rvu->dev,
> + "%s: Error happened while disabling old_mid=%u\n",
> + __func__, old_midx);
> + return -EFAULT;
> + }
> +
> + if (npc_cn20k_copy_mcam_entry(rvu, blkaddr, old_midx, new_midx)) {
> + dev_err(rvu->dev,
> + "%s: Error happened to while copying old_midx=%u new_midx=%u\n",
^^
This isn't a bug, but there's an extra 'to' here. The message should say
'Error happened while copying' rather than 'Error happened to while copying'.
> + __func__, old_midx, new_midx);
> + return -EFAULT;
> + }
> +
> + if (npc_cn20k_enable_mcam_entry(rvu, blkaddr, new_midx, true)) {
> + dev_err(rvu->dev,
> + "%s: Error happened while enabling new_mid=%u\n",
> + __func__, new_midx);
> + return -EFAULT;
> + }
>
> midx = new_midx % mcam->banksize;
> bank = new_midx / mcam->banksize;
AI review report: https://netdev-ai.bots.linux.dev/ai-review.html?id=9923f145-31df-46b0-84e8-b15f1e307ad2#patch-10
pw-bot: changes-requested
Grammatical mistake in string will fix it in next patch version.
^ permalink raw reply
* [PATCH iwl-net 1/1] igc: skip RX timestamp header for frame preemption verification
From: KhaiWenTan @ 2026-04-24 7:59 UTC (permalink / raw)
To: anthony.l.nguyen, przemyslaw.kitszel, andrew+netdev, davem,
edumazet, kuba, pabeni, chwee.lin.choong, vladimir.oltean,
vinicius.gomes
Cc: faizal.abdul.rahim, intel-wired-lan, netdev, linux-kernel,
khai.wen.tan, hong.aun.looi, faizal.abdul.rahim, KhaiWenTan
When RX hardware timestamping is enabled, a 16-byte inline timestamp header
is added to the start of the packet buffer, causing FPE handshake
verification to fail.
Because an incorrect packet buffer is passed to igc_fpe_handle_mpacket(),
the mem_is_zero() check inspects the timestamp metadata instead of the
actual mPacket payload. As a result, valid Verify/Response mPackets can be
missed when inline RX timestamps are present.
Pass pktbuf + pkt_offset to igc_fpe_handle_mpacket() so it inspects the
actual mPacket payload instead of the timestamp header.
Fixes: 5422570c0010 ("igc: add support for frame preemption verification")
Co-developed-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Signed-off-by: KhaiWenTan <khai.wen.tan@linux.intel.com>
---
drivers/net/ethernet/intel/igc/igc_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
index 8ac16808023c..c470d2354ce8 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -2649,7 +2649,7 @@ static int igc_clean_rx_irq(struct igc_q_vector *q_vector, const int budget)
}
if (igc_fpe_is_pmac_enabled(adapter) &&
- igc_fpe_handle_mpacket(adapter, rx_desc, size, pktbuf)) {
+ igc_fpe_handle_mpacket(adapter, rx_desc, size, pktbuf + pkt_offset)) {
/* Advance the ring next-to-clean */
igc_is_non_eop(rx_ring, rx_desc);
cleaned_count++;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 net 04/11] octeontx2-af: npc: cn20k: Make default entries as x4.
From: Ratheesh Kannoth @ 2026-04-24 8:26 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, davem, edumazet, kuba, pabeni, andrew+netdev
In-Reply-To: <20260423104317.2707923-5-rkannoth@marvell.com>
On 2026-04-23 at 16:13:10, Ratheesh Kannoth (rkannoth@marvell.com) wrote:
> X4 profile users won't alloc x2 entries. Allocating x2 entries
> would cause under utilized subbanks(X2). Avoid this in X4 kex
> profile, all allocations will be from x4 subbank.
>
> Fixes: 09d3b7a1403f ("octeontx2-af: npc: cn20k: Allocate default MCAM indexes")
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
>> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>> index 8630a6a73387..97acba77ff88 100644
>> --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>
>[ ... ]
>
>> @@ -4274,10 +4289,16 @@ int npc_cn20k_dft_rules_alloc(struct rvu *rvu, u16 pcifunc)
>> pfvf = rvu_get_pfvf(rvu, pcifunc);
>> pfvf->hw_prio = NPC_DFT_RULE_PRIO;
>>
>> + if (npc_priv.kw == NPC_MCAM_KEY_X4) {
>> + req.kw_type = NPC_MCAM_KEY_X4;
>> + req.ref_entry = eidx & (npc_priv.bank_depth - 1);
>> + } else {
>> + req.kw_type = NPC_MCAM_KEY_X2;
>> + req.ref_entry = eidx;
>> + }
>> +
>> req.contig = false;
>> req.ref_prio = NPC_MCAM_HIGHER_PRIO;
>> - req.ref_entry = eidx;
>> - req.kw_type = NPC_MCAM_KEY_X2;
>> req.count = cnt;
>> req.hdr.pcifunc = pcifunc;
>>
>> @@ -4299,8 +4320,9 @@ int npc_cn20k_dft_rules_alloc(struct rvu *rvu, u16 pcifunc)
>>
>> req = otx2_mbox_alloc_msg_npc_mcam_alloc_entry(&pf->mbox);
>> req->contig = false;
>> - req->ref_entry = eidx + 1;
>> req->kw_type = NPC_MCAM_KEY_X2;
>> + req->ref_entry = eidx + 1;
>
>The VF fallback path still hardcodes req.kw_type = NPC_MCAM_KEY_X2. Does this
>violate the commit message's claim that "X4 profile users won't alloc x2
>entries"? When the first allocation attempt fails for a VF on an X4 system,
>wouldn't this retry path still allocate from X2 subbanks?
>
>Also, should the ref_entry here be masked with (npc_priv.bank_depth - 1)
>similar to the primary allocation path for X4 profiles?
AI review report: https://netdev-ai.bots.linux.dev/ai-review.html?id=9923f145-31df-46b0-84e8-b15f1e307ad2#patch-10
pw-bot: changes-requested
Simon suggested to remove this from net, and post it as enhancement when net-next opens. So Dropping it for now.
Will post it in net-next after fixing this comment.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net] iavf: iavf_virtchnl_completion: drop duplicate ether_addr_equal() test
From: Corinna Vinschen @ 2026-04-24 8:32 UTC (permalink / raw)
To: Simon Horman
Cc: intel-wired-lan, stable, Jose Ignacio Tornos Martinez, netdev,
Corinna Vinschen
In-Reply-To: <20260423185530.GI900403@horms.kernel.org>
On Apr 23 19:55, Simon Horman wrote:
> On Tue, Apr 21, 2026 at 01:12:36PM +0200, Corinna Vinschen wrote:
> > This is just a simple cleanup fix. Commit 35a2443d0910f ("iavf: Add
> > waiting for response from PF in set mac") introduced a duplicate
> > ether_addr_equal() check, so the current code tests the new MAC twice
> > against the former MAC.
> >
> > Remove the outer ether_addr_equal() test, remnant of commit c5c922b3e09b
> > ("iavf: fix MAC address setting for VFs when filter is rejected")
> >
> > Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
> > Fixes: 35a2443d0910f ("iavf: Add waiting for response from PF in set mac")
> > Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > ---
> > Added CC: stable@vger.kernel.org
>
> Hi,
>
> This feels more like a cleanup for net-next (without a Fixes tag)
> than a fix for net. I'm missing where the bug is here.
Yeah, it's not a bug, the "Fixes" tag was just supposed to point out the
patch introducing the duplicate test.
Shall I create a v3 or is it ok as is and just goes to net-next instead
of net?
Thanks,
Corinna
^ permalink raw reply
* Re: [PATCH RFC net-next 1/4] net: pse-pd: scope pse_control regulator handle to kref lifetime
From: Kory Maincent @ 2026-04-24 8:36 UTC (permalink / raw)
To: Corey Leavitt via B4 Relay
Cc: corey, Oleksij Rempel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Heiner Kallweit, Russell King,
Andrew Lunn, netdev, linux-kernel
In-Reply-To: <20260423-pse-notifier-decouple-v1-1-86ed750a9d62@leavitt.info>
On Thu, 23 Apr 2026 01:42:14 -0600
Corey Leavitt via B4 Relay <devnull+corey.leavitt.info@kernel.org> wrote:
> From: Corey Leavitt <corey@leavitt.info>
>
> __pse_control_release() drops psec->ps via devm_regulator_put(), which
> only succeeds if the devres entry added by the matching
> devm_regulator_get_exclusive() is still present on pcdev->dev at the
> time the pse_control's kref hits zero.
>
> In practice that assumption does not hold when the controller is
> unbound while any pse_control still has consumers: pcdev->dev's
> devres list is released LIFO, so every per-attach regulator-GET
> devres runs (and regulator_put()s the underlying regulator) before
> pse_controller_unregister() itself is invoked. Any later
> pse_control_put() from that unbind path then reads psec->ps as a
> dangling pointer inside devm_regulator_put() and WARNs at
> drivers/regulator/devres.c:232 (devres_release() fails to find the
> already-released match).
>
> The pse_control's consumer handle is logically scoped to the
> pse_control's refcount, not to pcdev->dev's devres lifetime. Switch
> to the plain regulator_get_exclusive() / regulator_put() pair so
> __pse_control_release() does the right put regardless of whether
> the controller's devres has already been unwound.
>
> No change to the regulator-framework-visible refcount or lifetime of
> the underlying regulator: a single get paired with a single put. The
> existing devm_regulator_register() for the per-PI rails is unchanged
> (those ARE correctly scoped to the controller's lifetime).
Acked-by: Kory Maincent <kory.maincent@bootlin.com>
Thank you!
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] net: ne2k-pci: fix missing residual byte in block output for 32-bit IO
From: Simon Horman @ 2026-04-24 8:59 UTC (permalink / raw)
To: Titouan Ameline de Cadeville
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni,
linux-kernel
In-Reply-To: <20260421145736.15949-1-titouan.ameline@gmail.com>
On Tue, Apr 21, 2026 at 04:57:36PM +0200, Titouan Ameline de Cadeville wrote:
> ne2k_pci_block_output() handles residual bytes after the main outsl()
> loop when the transfer count is not a multiple of 4. It correctly
> handles the 2-byte residual case with outw(), but is missingg the
> 1 byte residual case. This means for packets where count % 4 == 1 or
> count % 4 == 3, the final byte is never written to the NIC's data
> port.
>
> In practice, this is masked by the count being rounded up to a 4-byte
> boundary earlier in the function for ONLY_32BIT_IO cards, but that
> rounding itself causes a little information leak by sending
> uninitialized kernel buffer bytes on the wire
It seems to me that the code being updated by this patch is for
!ONLY_32BIT_IO cards. And in that case count is rounded up to
the next even value if it is odd.
if (ei_status.ne2k_flags & ONLY_32BIT_IO)
count = (count + 3) & 0xFFFC;
else
if (count & 0x01)
count++;
Regarding the information leak. I believe this is only from
the Kernel to the device. But not from the device onto the wire
as the device doesn't send data beyond the end of the packet data.
It isn't at obvious to me that this is a problem that warrants fixing.
>
> Add the missing outb() call for the odd byte case, mirroring what
> ne2k_pci_block_input() already does correctly.
>
> Signed-off-by: Titouan Ameline de Cadeville <titouan.ameline@gmail.com>
> ---
> drivers/net/ethernet/8390/ne2k-pci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/8390/ne2k-pci.c b/drivers/net/ethernet/8390/ne2k-pci.c
> index 1a34da07c0db..1bd5b94b5d22 100644
> --- a/drivers/net/ethernet/8390/ne2k-pci.c
> +++ b/drivers/net/ethernet/8390/ne2k-pci.c
> @@ -632,6 +632,8 @@ static void ne2k_pci_block_output(struct net_device *dev, int count,
> outw(le16_to_cpu(*b++), NE_BASE + NE_DATAPORT);
> buf = (char *)b;
> }
> + if (count & 1)
> + outb(*buf, NE_BASE + NE_DATAPORT);
Because count is even this condition will never be met.
> }
> }
--
pw-bot: changes-requested
^ permalink raw reply
* [PATCH net] net: airoha: Do not read uninitialized fragment address in airoha_dev_xmit()
From: Lorenzo Bianconi @ 2026-04-24 9:00 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev,
Lorenzo Bianconi
The transmit loop in airoha_dev_xmit() reads fragment address and length
during its final iteration, when the loop index equals
skb_shinfo(skb)->nr_frags, at which point the fragment data is
uninitialized. While these values are never consumed, the read itself is
unsafe and may trigger a page fault. Fix this by avoiding the fragment
read on the last iteration.
Additionally, move the skb pointer from the first to the last used packet
descriptor, so that airoha_qdma_tx_napi_poll() defers freeing the skb
until the final descriptor is processed.
Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 2bb0a3ff9810..d3a841908c82 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1997,8 +1997,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
struct netdev_queue *txq;
struct airoha_queue *q;
LIST_HEAD(tx_list);
+ int i = 0, qid;
void *data;
- int i, qid;
u16 index;
u8 fport;
@@ -2057,7 +2057,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
list);
index = e - q->entry;
- for (i = 0; i < nr_frags; i++) {
+ while (true) {
struct airoha_qdma_desc *desc = &q->desc[index];
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
dma_addr_t addr;
@@ -2069,7 +2069,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
goto error_unmap;
list_move_tail(&e->list, &tx_list);
- e->skb = i ? NULL : skb;
+ e->skb = i == nr_frags - 1 ? skb : NULL;
e->dma_addr = addr;
e->dma_len = len;
@@ -2088,6 +2088,9 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
WRITE_ONCE(desc->msg1, cpu_to_le32(msg1));
WRITE_ONCE(desc->msg2, cpu_to_le32(0xffff));
+ if (++i == nr_frags)
+ break;
+
data = skb_frag_address(frag);
len = skb_frag_size(frag);
}
---
base-commit: e728258debd553c95d2e70f9cd97c9fde27c7130
change-id: 20260423-airoha-xmit-fix-read-frag-dc6aa001ca4b
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH v3 net 05/11] octeontx2-af: npc: cn20k: Align MCAM X2/X4 use with KEX profile
From: Ratheesh Kannoth @ 2026-04-24 9:06 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, davem, edumazet, kuba, pabeni, andrew+netdev
In-Reply-To: <20260423104317.2707923-6-rkannoth@marvell.com>
On 2026-04-23 at 16:13:11, Ratheesh Kannoth (rkannoth@marvell.com) wrote:
> Flow install derives whether an NPC MCAM line must be X2 or X4 from the
> effective key width (>256 bits needs X4). That is only valid when the
> global KEX profile allows X4 keys; if the profile is X2-only, fail the
> install with -EOPNOTSUPP instead of allocating a mismatched entry.
> Default L2 rules allocation always requested X2 keys. When npc_priv.kw
> is X4, request X4 MCAM entries and wrap the reference index to the MCAM
> bank depth so default rules match the active key mode.
>
> Fixes: 9000cada7aa9 ("octeontx2-af: npc: cn20k: Allocate MCAM entry for flow installation")
> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
>> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>> index 8630a6a73387..97acba77ff88 100644
>> --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>
>[ ... ]
>
>> @@ -4274,10 +4289,16 @@ int npc_cn20k_dft_rules_alloc(struct rvu *rvu, u16 pcifunc)
>> pfvf = rvu_get_pfvf(rvu, pcifunc);
>> pfvf->hw_prio = NPC_DFT_RULE_PRIO;
>>
>> + if (npc_priv.kw == NPC_MCAM_KEY_X4) {
>> + req.kw_type = NPC_MCAM_KEY_X4;
>> + req.ref_entry = eidx & (npc_priv.bank_depth - 1);
>> + } else {
>> + req.kw_type = NPC_MCAM_KEY_X2;
>> + req.ref_entry = eidx;
>> + }
>> +
>> req.contig = false;
>> req.ref_prio = NPC_MCAM_HIGHER_PRIO;
>> - req.ref_entry = eidx;
>> - req.kw_type = NPC_MCAM_KEY_X2;
>> req.count = cnt;
>> req.hdr.pcifunc = pcifunc;
>>
>> @@ -4299,8 +4320,9 @@ int npc_cn20k_dft_rules_alloc(struct rvu *rvu, u16 pcifunc)
>>
>> req = otx2_mbox_alloc_msg_npc_mcam_alloc_entry(&pf->mbox);
>> req->contig = false;
>> - req->ref_entry = eidx + 1;
>> req->kw_type = NPC_MCAM_KEY_X2;
>> + req->ref_entry = eidx + 1;
>
>The VF fallback path still hardcodes req.kw_type = NPC_MCAM_KEY_X2. Does this
>violate the commit message's claim that "X4 profile users won't alloc x2
>entries"? When the first allocation attempt fails for a VF on an X4 system,
>wouldn't this retry path still allocate from X2 subbanks?
>
>Also, should the ref_entry here be masked with (npc_priv.bank_depth - 1)
>similar to the primary allocation path for X4 profiles?
AI review report: https://netdev-ai.bots.linux.dev/ai-review.html?id=9923f145-31df-46b0-84e8-b15f1e307ad2#patch-10
pw-bot: changes-requested
This patch has some dependency on patch number #4, Since we plan to post patch #4 in net-next(simon asked to do so),
dropping this patch as well from this series.
^ permalink raw reply
* Re: [PATCH v3 net 10/11] octeontx2-af: npc: cn20k: Tear down default MCAM rules explicitly on free
From: Ratheesh Kannoth @ 2026-04-24 9:11 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, davem, edumazet, kuba, pabeni, andrew+netdev
In-Reply-To: <20260423104317.2707923-11-rkannoth@marvell.com>
On 2026-04-23 at 16:13:16, Ratheesh Kannoth (rkannoth@marvell.com) wrote:
>
octeontx2-af: npc: cn20k: Tear down default MCAM rules explicitly on free
This patch changes npc_cn20k_dft_rules_free() to explicitly tear down
each default MCAM rule by clearing the bitmap, disabling the MCAM line,
and calling npc_cn20k_idx_free(), instead of using the "free all" path.
It also updates npc_mcam_free_all_entries() to skip bitmap clear and
idx_free for cn20k default-rule indices.
>> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>> index 6d3166960a3f..54a25d9c5505 100644
>> --- a/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>> +++ b/drivers/net/ethernet/marvell/octeontx2/af/cn20k/npc.c
>
>[ ... ]
>
>> @@ -4228,14 +4228,47 @@ void npc_cn20k_dft_rules_free(struct rvu *rvu, u16 pcifunc)
>> }
>>
>> free_rules:
>> + blkaddr = rvu_get_blkaddr(rvu, BLKTYPE_NPC, 0);
>> + if (blkaddr < 0)
>> + return;
>> + for (int i = 0; i < 4; i++) {
>> + if (ptr[i] == USHRT_MAX)
>> + continue;
>>
>> - free_req.hdr.pcifunc = pcifunc;
>> - free_req.all = 1;
>> - rc = rvu_mbox_handler_npc_mcam_free_entry(rvu, &free_req, &rsp);
>> - if (rc)
>> - dev_err(rvu->dev,
>> - "%s: Error deleting default entries (pcifunc=%#x\n",
>> - __func__, pcifunc);
>> + mutex_lock(&mcam->lock);
>> + npc_mcam_clear_bit(mcam, ptr[i]);
>> + mcam->entry2pfvf_map[ptr[i]] = NPC_MCAM_INVALID_MAP;
>> + npc_cn20k_enable_mcam_entry(rvu, blkaddr, ptr[i], false);
>> + mcam->entry2target_pffunc[ptr[i]] = 0x0;
>> + mutex_unlock(&mcam->lock);
>> +
>> + rc = npc_cn20k_idx_free(rvu, &ptr[i], 1);
>> + if (rc) {
>> + /* Non recoverable error. Let us WARN and return. Keep system alive to
>> + * enable debugging
>> + */
>> + WARN(1, "%s Error deleting default entries (pcifunc=%#x) mcam_idx=%u\n",
>> + __func__, pcifunc, ptr[i]);
>> +
>> + /* Clear entries from mcam_rules, whose indexes are successfully freed
>> + * by npc_cn20k_idx_free().
>> + */
>> + ptr[i] = USHRT_MAX;
>> + }
>
>The comment says "Let us WARN and return" and the commit message says
>"WARN and stop so the box stays up for analysis," but after setting
>ptr[i] = USHRT_MAX, the loop continues processing remaining indices.
>Should the code break or return here to match the comment and commit
>message? Or if continuing is intentional, should the comment say
>"WARN and continue" instead?
AI review report: https://netdev-ai.bots.linux.dev/ai-review.html?id=9923f145-31df-46b0-84e8-b15f1e307ad2#patch-10
pw-bot: changes-requested
Will fix it by returning error code.
>
^ permalink raw reply
* Re: [PATCH v3 net 11/11] octeontx2-af: npc: cn20k: Reject missing default-rule MCAM indices
From: Ratheesh Kannoth @ 2026-04-24 9:15 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, davem, edumazet, kuba, pabeni, andrew+netdev,
Suman Ghosh
In-Reply-To: <20260423104317.2707923-12-rkannoth@marvell.com>
On 2026-04-23 at 16:13:17, Ratheesh Kannoth (rkannoth@marvell.com) wrote:
>> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
>> index 5d349d131fdb..611cd7fce245 100644
>> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
>> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
>
>[ ... ]
>
>> @@ -3897,6 +4006,13 @@ int rvu_mbox_handler_npc_read_base_steer_rule(struct rvu *rvu,
>> /* Read the default ucast entry if there is no pkt steering rule */
>> index = npc_get_nixlf_mcam_index(mcam, pcifunc, nixlf,
>> NIXLF_UCAST_ENTRY);
>> + if (index < 0) {
>> + dev_err(rvu->dev,
>> + "%s: Error to get ucast entry for pcifunc=%#x\n",
>> + __func__, pcifunc);
>> + goto out;
>> + }
>> +
>> read_entry:
>> /* Read the mcam entry */
>> npc_read_mcam_entry(rvu, mcam, blkaddr, index, &rsp->entry, &intf,
>
>Does this 'goto out' leak mcam->lock? Looking at the function entry,
>the lock is acquired before the for-loop:
>
>rvu_mbox_handler_npc_read_base_steer_rule() {
> ...
> mutex_lock(&mcam->lock);
>
> for (idx = 0; idx < pfvf->def_ucast_rule.count; idx++) {
> ...
> }
>
> /* Read the default ucast entry if there is no pkt steering rule */
> index = npc_get_nixlf_mcam_index(...);
> if (index < 0) {
> goto out;
> }
>
>and the 'out' label just returns without unlocking:
>
>out:
> return rc;
>
>The nix_get_nixlf() failure path just before this does:
>
> if (rc) {
> mutex_unlock(&mcam->lock);
> goto out;
> }
>
>Should this new error path match that pattern?
AI review report: https://netdev-ai.bots.linux.dev/ai-review.html?id=9923f145-31df-46b0-84e8-b15f1e307ad2#patch-10
pw-bot: changes-requested
Will fix in next version.
^ permalink raw reply
* Re: [PATCH] NFC: trf7970a: Ignore antenna noise when checking for RF field
From: Krzysztof Kozlowski @ 2026-04-24 9:39 UTC (permalink / raw)
To: Paul Geurts, mgreer, sameo, linux-wireless, netdev, linux-kernel
Cc: martijn.de.gouw
In-Reply-To: <20260422100930.581237-1-paul.geurts@prodrive-technologies.com>
On 22/04/2026 12:09, Paul Geurts wrote:
> The main channel Received Signal Strength Indicator (RSSI) measurement
> is used to determine whether an RF field is present or not. RSSI != 0
> is interpreted as an RF Field is present. This does not take RF noise
> and measurement inaccuracy into account, and results in false positives
> in the field.
>
> Define a noise level and make sure the RF field is only interpreted as
> present when the RSSI is above the noise level.
>
> Fixes: 851ee3cbf850 ("NFC: trf7970a: Don't turn on RF if there is already an RF field")
> Signed-off-by: Paul Geurts <paul.geurts@prodrive-technologies.com>
> ---
> drivers/nfc/trf7970a.c | 3 ++-
Looks reasonable so a poor man's review:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH net] net: macb: drop in-flight Tx SKBs on close
From: Théo Lebrun @ 2026-04-24 10:01 UTC (permalink / raw)
To: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Haavard Skinnemoen,
Jeff Garzik
Cc: Paolo Valerio, Conor Dooley, Nicolai Buchwitz, netdev,
linux-kernel, Vladimir Kondratiev, Gregory CLEMENT,
Benoît Monin, Tawfik Bayouk, Thomas Petazzoni,
Maxime Chevallier, Théo Lebrun
The MACB driver has since forever leaked the outgoing SKBs that have not
yet been marked as completed. They live in queue->tx_skb which gets
freed without remorse nor checking.
macb_free_consistent() gets called in a few codepaths, but only
close will trigger the added expressions. In macb_open() and
macb_alloc_consistent() failure cases, tx_skb just got allocated
and is empty.
Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
drivers/net/ethernet/cadence/macb_main.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index a12aa21244e8..3ffd60b852f8 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2649,6 +2649,7 @@ static unsigned int macb_rx_ring_size_per_queue(struct macb *bp)
static void macb_free_consistent(struct macb *bp)
{
struct device *dev = &bp->pdev->dev;
+ unsigned int dropped, tail;
struct macb_queue *queue;
unsigned int q;
size_t size;
@@ -2668,6 +2669,14 @@ static void macb_free_consistent(struct macb *bp)
dma_free_coherent(dev, size, bp->queues[0].rx_ring, bp->queues[0].rx_ring_dma);
for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
+ dropped = CIRC_CNT(queue->tx_head, queue->tx_tail,
+ bp->tx_ring_size);
+ queue->stats.tx_dropped += dropped;
+ bp->dev->stats.tx_dropped += dropped;
+
+ for (tail = queue->tx_tail; tail != queue->tx_head; tail++)
+ macb_tx_unmap(bp, macb_tx_skb(queue, tail), 0);
+
kfree(queue->tx_skb);
queue->tx_skb = NULL;
queue->tx_ring = NULL;
---
base-commit: 41517b5a932a35c6f59a997ab3b7fa7746c273bd
change-id: 20260423-macb-drop-tx-f9ce72720d05
Best regards,
--
Théo Lebrun <theo.lebrun@bootlin.com>
^ permalink raw reply related
* RE: [PATCH net v4 4/4] ice: skip unnecessary VF reset when setting trust
From: Jose Ignacio Tornos Martinez @ 2026-04-24 10:32 UTC (permalink / raw)
To: aleksandr.loktionov
Cc: anthony.l.nguyen, davem, edumazet, horms, intel-wired-lan,
jacob.e.keller, jesse.brandeburg, jtornosm, kuba, netdev, pabeni,
przemyslaw.kitszel
In-Reply-To: <IA3PR11MB89862412A9F682D59474841DE52A2@IA3PR11MB8986.namprd11.prod.outlook.com>
Hello Aleksandr,
> For me it looks like cc: stable@vger.kernel.org must be added
I am not sure about that, because the bugs fixed here (vf->trusted
ordering and race condition) only trigger when MAC LLDP filters exist,
which is an uncommon scenario.
And most users will benefit from the performance improvement that is an
optimization rather than the bug fixes.
I mean, I included the commit fixed as a reference but due to optimization
as the main reason, I didn't dare to request this for older versions.
> You declare ice_vf_clear_all_promisc_modes() returning int, but ignore
> the return value.
> Looks suspicious isn't it?
Well, it is used like that when the funciton is called locally (the
function is not modifiedi, just made public), and really my intention was
to clean as much as possible (so error checking is not necessary).
In my opinion it would be enough to warn about the possible problems
(already done in the existing function).
Anyway, if, despite the reasons I have tried to explain, you still think
the same way, please let me know so I can adjust them (if you don't mind,
I would wait for more reviews to include them in a next version).
Thanks
Best regards
Jose Ignacio
^ permalink raw reply
* RE: [PATCH net v4 4/4] ice: skip unnecessary VF reset when setting trust
From: Loktionov, Aleksandr @ 2026-04-24 10:37 UTC (permalink / raw)
To: Jose Ignacio Tornos Martinez
Cc: Nguyen, Anthony L, davem@davemloft.net, edumazet@google.com,
horms@kernel.org, intel-wired-lan@lists.osuosl.org,
Keller, Jacob E, jesse.brandeburg@intel.com, kuba@kernel.org,
netdev@vger.kernel.org, pabeni@redhat.com, Kitszel, Przemyslaw
In-Reply-To: <20260424103233.622318-1-jtornosm@redhat.com>
> -----Original Message-----
> From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> Sent: Friday, April 24, 2026 12:33 PM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>;
> davem@davemloft.net; edumazet@google.com; horms@kernel.org; intel-
> wired-lan@lists.osuosl.org; Keller, Jacob E
> <jacob.e.keller@intel.com>; jesse.brandeburg@intel.com;
> jtornosm@redhat.com; kuba@kernel.org; netdev@vger.kernel.org;
> pabeni@redhat.com; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>
> Subject: RE: [PATCH net v4 4/4] ice: skip unnecessary VF reset when
> setting trust
>
> Hello Aleksandr,
>
> > For me it looks like cc: stable@vger.kernel.org must be added
> I am not sure about that, because the bugs fixed here (vf->trusted
> ordering and race condition) only trigger when MAC LLDP filters exist,
> which is an uncommon scenario.
> And most users will benefit from the performance improvement that is
> an optimization rather than the bug fixes.
> I mean, I included the commit fixed as a reference but due to
> optimization as the main reason, I didn't dare to request this for
> older versions.
Ok I see your point. As it's optimization, you are right.
>
> > You declare ice_vf_clear_all_promisc_modes() returning int, but
> ignore
> > the return value.
> > Looks suspicious isn't it?
> Well, it is used like that when the funciton is called locally (the
> function is not modifiedi, just made public), and really my intention
> was to clean as much as possible (so error checking is not necessary).
> In my opinion it would be enough to warn about the possible problems
> (already done in the existing function).
Can you go extra mile and add error code handling?
Or at least document it in the code why you don't do it?
>
> Anyway, if, despite the reasons I have tried to explain, you still
> think the same way, please let me know so I can adjust them (if you
> don't mind, I would wait for more reviews to include them in a next
> version).
>
> Thanks
>
> Best regards
> Jose Ignacio
Thank you
Alex
^ permalink raw reply
* Re: [PATCH net] net: macb: drop in-flight Tx SKBs on close
From: Nicolai Buchwitz @ 2026-04-24 10:30 UTC (permalink / raw)
To: Théo Lebrun
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Haavard Skinnemoen,
Jeff Garzik, Paolo Valerio, Conor Dooley, netdev, linux-kernel,
Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
Tawfik Bayouk, Thomas Petazzoni, Maxime Chevallier
In-Reply-To: <20260424-macb-drop-tx-v1-1-b3ecb787d84d@bootlin.com>
Hi Théo,
thanks for your patch.
On 24.4.2026 12:01, Théo Lebrun wrote:
> [...]
>
> for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
> + dropped = CIRC_CNT(queue->tx_head, queue->tx_tail,
> + bp->tx_ring_size);
> + queue->stats.tx_dropped += dropped;
> + bp->dev->stats.tx_dropped += dropped;
AFAIUI CIRC_CNT counts descriptor slots, not packets. A fragmented
skb uses multiple slots so tx_dropped would be overcounted?
> +
> + for (tail = queue->tx_tail; tail != queue->tx_head; tail++)
> + macb_tx_unmap(bp, macb_tx_skb(queue, tail), 0);
I might be missing something, but couldn't this crash on the
macb_alloc_consistent() -> out_err path after a previous close
with in-flight frames?
1. First close: the new loop runs and frees skbs, but tx_head and
tx_tail are not reset. kfree(tx_skb) sets it to NULL.
2. Second open: macb_alloc_consistent() fails early (e.g. the tx
dma_alloc_coherent on the first line) and jumps to out_err.
3. macb_free_consistent() runs again. CIRC_CNT is non-zero (stale
from previous session). macb_tx_skb() dereferences queue->tx_skb
which is NULL.
Or if the failure happens later, the loop would iterate over a
freshly kmalloc'd (uninitialized) tx_skb array and macb_tx_unmap()
would read garbage mapping/skb pointers.
Maybe reset tx_head = tx_tail = 0 after the loop, or guard with
if (queue->tx_skb)?
> +
> kfree(queue->tx_skb);
> queue->tx_skb = NULL;
> queue->tx_ring = NULL;
>
> [...]
Thanks,
Nicolai
^ permalink raw reply
* [PATCH bpf v2 0/3] bpf: prevent offloaded programs from running on host via tcx/netkit
From: Jiayuan Chen @ 2026-04-24 10:41 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Daniel Borkmann, Nikolay Aleksandrov, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Martin KaFai Lau, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Simon Horman, Jesper Dangaard Brouer, Willem de Bruijn,
Samiullah Khawaja, Hangbin Liu, Krishna Kumar, Kuniyuki Iwashima,
Toke Høiland-Jørgensen, netdev, linux-kernel
Yinhao reported a splat [1] when attaching a BPF program loaded with
prog_ifindex (targeted at an offload-capable device such as netdevsim)
to the software path via BPF_TCX_EGRESS. The program's bpf_func had
already been replaced by bpf_prog_warn_on_exec() during offload compile,
so the first packet that reaches tcx_run() trips the WARN:
[ 19.592982] ------------[ cut here ]------------
[ 19.594654] attempt to execute device eBPF program on the host!
[ 19.594659] WARNING: kernel/bpf/offload.c:420 at 0x0, CPU#0: poc/337
[ 19.599906] Modules linked in:
[ 19.600680] CPU: 0 UID: 0 PID: 337 Comm: poc Not tainted
6.18.0-rc7-next-20251125 #10 PREEMPT(none)
[ 19.601659] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX,
1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[ 19.602684] RIP: 0010:bpf_prog_warn_on_exec+0xc/0x20
[ 19.603241] Code: 28 00 48 89 ef e8 74 44 2f 00 eb d7 66 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 8d 3d a4 eb 95
06 <67> 48 0f b9 3a 31 c0 e9 83 76 44 ff 0f 1f 84 00 00 00 00 00 90 90
[ 19.605093] RSP: 0018:ffff8881066e73d8 EFLAGS: 00010246
[ 19.605663] RAX: ffffffff81cbca70 RBX: ffff8881013c4210 RCX:
0000000000000004
[ 19.606378] RDX: 1ffff11020278842 RSI: ffffc90000563060 RDI:
ffffffff8861b620
[ 19.607107] RBP: ffff8881010d0640 R08: ffff8881013c4210 R09:
ffff8881010d06b0
[ 19.607827] R10: ffff8881010d06c3 R11: ffffc90000563000 R12:
ffffc90000563000
[ 19.608751] R13: ffff8881010d06b4 R14: ffff888115eb1a34 R15:
dffffc0000000000
[ 19.609478] FS: 000000000294c380(0000) GS:ffff8881911e9000(0000)
knlGS:0000000000000000
[ 19.610316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 19.610943] CR2: 000057f6b9eb38c0 CR3: 00000001010ea000 CR4:
0000000000750ef0
[ 19.611712] PKRU: 55555554
[ 19.612006] Call Trace:
[ 19.612281] <TASK>
[ 19.612523] __dev_queue_xmit+0x22cb/0x3530
[ 19.617607] ip_finish_output2+0x621/0x1a60
[ 19.621371] ip_output+0x170/0x2e0
[ 19.624586] ip_send_skb+0x129/0x180
[ 19.624940] udp_send_skb+0x65d/0x1300
[ 19.625316] udp_sendmsg+0x13bf/0x2000
[ 19.629960] __sys_sendto+0x396/0x470
[ 19.633720] __x64_sys_sendto+0xdc/0x1b0
[ 19.635066] do_syscall_64+0x76/0x10a0
[ 19.641701] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 19.642240] RIP: 0033:0x4240d7
[ 19.642597] Code: 00 89 01 e9 c1 fe ff ff e8 f6 03 00 00 66 0f 1f 44
00 00 f3 0f 1e fa 80 3d 8d 3f 09 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f
05 <48> 3d 00 f0 ff ff 77 69 c3 55 48 89 e5 53 48 83 ec 38 44 89 4d d0
[ 19.646088] RSP: 002b:00007fffcb9ecb68 EFLAGS: 00000202 ORIG_RAX:
000000000000002c
[ 19.648938] RAX: ffffffffffffffda RBX: 0000000000000001 RCX:
00000000004240d7
[ 19.652116] RDX: 0000000000000008 RSI: 00007fffcb9ecce0 RDI:
0000000000000005
[ 19.653148] RBP: 00007fffcb9eccf0 R08: 00007fffcb9ecbb0 R09:
0000000000000010
[ 19.653951] R10: 0000000000000000 R11: 0000000000000202 R12:
00007fffcb9ece08
[ 19.654760] R13: 00007fffcb9ece18 R14: 00000000004b2868 R15:
0000000000000001
[ 19.657462] </TASK>
[ 19.657703] ---[ end trace 0000000000000000 ]---
The reason is that tcx and netkit never checked for offloaded programs
on attach, unlike XDP which already rejects this in dev_xdp_attach().
While auditing the other link entry points, bpf_xdp_link_update() turned
out to have the same gap: it calls dev_xdp_install() directly and skips
the dev_xdp_attach() offload check, so an XDP link created in SKB/native
mode can still be swapped to an offloaded program via BPF_LINK_UPDATE.
This series adds the same guard to all three so offloaded programs can't
be attached to (or swapped into) the software path.
v1 -> v2:
- tcx/netkit: also reject offloaded progs in the link update callback
(tcx_link_update/netkit_link_update), not just attach; pointed out
by the AI review on v1.
- Add patch 3/3 for the same hole in bpf_xdp_link_update().
v1: https://lore.kernel.org/bpf/20260423033609.252464-1-jiayuan.chen@linux.dev/
[1]: https://lore.kernel.org/bpf/64d8e2b5-a214-4f3c-b9e8-bcedbcb2c602@hust.edu.cn/
Jiayuan Chen (3):
bpf, tcx: reject offloaded programs on attach
bpf, netkit: reject offloaded programs on attach
bpf, xdp: reject offloaded programs on link update
drivers/net/netkit.c | 9 +++++++++
kernel/bpf/tcx.c | 9 +++++++++
net/core/dev.c | 5 +++++
3 files changed, 23 insertions(+)
--
2.43.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox