* Re: [PATCH net] slip: fix slab-out-of-bounds write in slhc_uncompress()
From: Simon Horman @ 2026-04-19 14:32 UTC (permalink / raw)
To: Weiming Shi
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Andrew Morton, Hans Verkuil, Alex Deucher,
Ian Rogers, Jonathan Cameron, Kees Cook, Ingo Molnar, Alan Cox,
netdev
In-Reply-To: <20260419142720.GJ280379@horms.kernel.org>
On Sun, Apr 19, 2026 at 03:27:26PM +0100, Simon Horman wrote:
> On Thu, Apr 16, 2026 at 05:34:00AM +0800, Weiming Shi wrote:
> > sl_bump() reserves only 80 bytes of expansion headroom before calling
> > slhc_uncompress(), but the reconstructed IP + TCP header is up to
> > ip->ihl*4 + thp->doff*4 bytes. IHL and TCP doff are 4-bit fields and
> > both can legitimately reach 15, so the header can grow to 2*15*4 =
> > 120 bytes. A VJ-uncompressed primer with ihl=15, doff=15 followed by
> > a compressed frame of size buffsize - 80 therefore writes up to
> > 33 bytes past the kmalloc(buffsize + 4) rbuff allocation, with
> > attacker-controlled content:
> >
> > BUG: KASAN: slab-out-of-bounds in slhc_uncompress
> > Write of size 1069 at addr ffff88800ba93078 by task kworker/u8:1/32
> > Workqueue: events_unbound flush_to_ldisc
> > Call Trace:
> > __asan_memmove+0x3f/0x70
> > slhc_uncompress (drivers/net/slip/slhc.c:614)
> > slip_receive_buf (drivers/net/slip/slip.c:342)
> > tty_ldisc_receive_buf
> > flush_to_ldisc
> >
> > Raise the reservation to match the real worst case. The ppp_generic
> > receive path already enforces skb_tailroom >= 124 and is unaffected.
> >
> > Fixes: b5451d783ade ("slip: Move the SLIP drivers")
> > Reported-by: Simon Horman <horms@kernel.org>
>
> FTR, I was mainly passing on information flagged by Sashiko.
>
> > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
>
> Reviewed-by: Simon Horman <horms@kernel.org>
I'm very sorry but the text below below was for a different,
albeit related, patch:
- [PATCH net] slip: bound decode() reads against the compressed packet length
https://lore.kernel.org/netdev/20260416100147.531855-5-bestswngs@gmail.com/
The corresponding text relating to this patch was posted as:
https://lore.kernel.org/netdev/20260419142710.GI280379@horms.kernel.org/
Sorry for the mix up!
> Let me summarise my understanding of Sashiko's review of this patch.
>
> TL;DR: I don't think that review should block progress of this patch.
>
> 1. The issue wrt concurrent MTU changes appears to be a separate,
> pre-existing problem. Maybe you've looked into it already,
> if not, you may wish to.
>
> 2. The bounds checking problems are addressed by other patches in flight.
>
> - [PATCH net v2] slip: reject VJ receive packets on instances with no rstate array
> https://lore.kernel.org/netdev/20260415204130.258866-2-bestswngs@gmail.com/
>
> - [PATCH net] slip: fix slab-out-of-bounds write in slhc_uncompress()
> https://lore.kernel.org/netdev/20260415213359.335657-2-bestswngs@gmail.com/
>
> In future you might want to consider creating patch sets for related
> patches. But I think it's too late in the case of these patches.
>
> ...
^ permalink raw reply
* Re: [PATCH net v2 1/1] net: l3mdev: Ignore non-L3 uppers in l3mdev_fib_table_rcu
From: Haoze Xie @ 2026-04-19 14:38 UTC (permalink / raw)
To: Ido Schimmel, Ao Zhou
Cc: netdev, David Ahern, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Ido Schimmel,
Jiri Pirko, Yifan Wu, Juefei Pu, Yuan Tan, Xin Liu, royenheart
In-Reply-To: <6eb15ec6-6994-4b24-9a53-48a653b96860@gmail.com>
On 4/19/2026 11:49 AM, Haoze Xie wrote:
>
> On 4/6/2026 11:48 PM, Ido Schimmel wrote:
>> On Mon, Apr 06, 2026 at 09:28:16PM +0800, Ao Zhou wrote:
>>> From: Haoze Xie <royenheart@gmail.com>
>>>
>>> l3mdev_fib_table_rcu() assumes that any upper device observed for
>>> an IFF_L3MDEV_SLAVE device is an L3 master and dereferences
>>> master->l3mdev_ops unconditionally.
>>>
>>> VRF slave setup sets IFF_L3MDEV_SLAVE before the upper link is fully
>>> switched, so readers can transiently observe a non-L3 upper such as a
>>> bridge and follow a NULL l3mdev_ops pointer. Require the current upper
>>> to still be an L3 master before consulting its FIB table.
>>>
>>> Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking")
>>> Reported-by: Yifan Wu <yifanwucs@gmail.com>
>>> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
>>> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
>>> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
>>> Suggested-by: Xin Liu <bird@lzu.edu.cn>
>>> Reviewed-by: David Ahern <dsahern@kernel.org>
>>> Signed-off-by: Haoze Xie <royenheart@gmail.com>
>>> Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
>>> ---
>>> changes in v2:
>>> - point Fixes to the VRF slave ordering change identified by David Ahern
>>> - add David Ahern's Reviewed-by trailer
>>>
>>> net/l3mdev/l3mdev.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/net/l3mdev/l3mdev.c b/net/l3mdev/l3mdev.c
>>> index 5432a5f2dfc8..b8a3030cb2c4 100644
>>> --- a/net/l3mdev/l3mdev.c
>>> +++ b/net/l3mdev/l3mdev.c
>>> @@ -177,7 +177,7 @@ u32 l3mdev_fib_table_rcu(const struct net_device *dev)
>>> const struct net_device *master;
>>>
>>> master = netdev_master_upper_dev_get_rcu(_dev);
>>> - if (master &&
>>> + if (master && netif_is_l3_master(master) &&
>>> master->l3mdev_ops->l3mdev_fib_table)
>>
>> Don't we have the same problem in l3mdev_l3_rcv() and l3mdev_l3_out()?
>> If so, please check if I missed more places and include them in v3.
>>
>
> I checked the same pattern in the other slave-side helpers, and v3 now
> extends the fix to both `l3mdev_l3_rcv()` and `l3mdev_l3_out()` in
> addition to `l3mdev_fib_table_rcu()`.
>
> All three helpers resolve the current upper with
> `netdev_master_upper_dev_get_rcu()` and then use `master->l3mdev_ops`.
> So v3 consistently requires the resolved upper to still satisfy
> `netif_is_l3_master(master)` before dereferencing `l3mdev_ops`.
>
While updating the patch, I found that `l3mdev_l3_rcv()` must keep
working for existing `IFF_L3MDEV_RX_HANDLER` users such as
`ipvlan_l3s`. The v3 patch keeps that direct RX-handler path
intact and applies the extra master check only to the slave-resolved
upper case.
the smoke test, it should ping succeffully:
===> BEGIN smoke test cmd <===
ip netns add ipvl_ns
ip link add ipvl_host type veth peer name ipvl_peer
ip link set ipvl_peer netns ipvl_ns
ip link set ipvl_host up
ip link add link ipvl_host name ipvl0 type ipvlan mode l3s
ip addr add 198.51.100.1/24 dev ipvl0
ip link set ipvl0 up
ip netns exec ipvl_ns ip link set lo up
ip netns exec ipvl_ns ip link set ipvl_peer up
ip netns exec ipvl_ns ip addr add 198.51.100.2/24 dev ipvl_peer
ip netns exec ipvl_ns ping -c 3 198.51.100.1
===> END smoke test cmd <===
>> And I think that the part that I was missing earlier is that we don't
>> have RCU synchronization in the unslaving path, so an RCU reader can
>> either see the original master, NULL or a new master (e.g., bridge
>> instead of the original VRF master).
>>
>>> tb_id = master->l3mdev_ops->l3mdev_fib_table(master);
>>> }
>>> --
>>> 2.53.0
>>>
>
^ permalink raw reply
* Re: [PATCH net] slip: bound decode() reads against the compressed packet length
From: Simon Horman @ 2026-04-19 14:56 UTC (permalink / raw)
To: Weiming Shi
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev
In-Reply-To: <20260416100147.531855-5-bestswngs@gmail.com>
On Thu, Apr 16, 2026 at 06:01:51PM +0800, Weiming Shi wrote:
> slhc_uncompress() parses a VJ-compressed TCP header by advancing a
> pointer through the packet via decode() and pull16(). Neither helper
> bounds-checks against isize, and decode() masks its return with
> & 0xffff so it can never return the -1 that callers test for -- those
> error paths are dead code.
>
> A short compressed frame whose change byte requests optional fields
> lets decode() read past the end of the packet. The over-read bytes
> are folded into the cached cstate and reflected into subsequent
> reconstructed packets.
>
> Make decode() and pull16() take the packet end pointer and return -1
> when exhausted. Add a bounds check before the TCP-checksum read.
> The existing == -1 tests now do what they were always meant to.
>
> Fixes: b5451d783ade ("slip: Move the SLIP drivers")
AI generated review points out that the cited patch only moves code,
so it isn't the origin of the bug. It seems that the problem has been
present since the beginning of git history. So:
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: Simon Horman <horms@kernel.org>
FTR, I believe I was mainly passing on AI generated review
> Closes: https://lore.kernel.org/netdev/20260414134126.758795-2-horms@kernel.org/
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
> ---
> drivers/net/slip/slhc.c | 43 ++++++++++++++++++++++++-----------------
> 1 file changed, 25 insertions(+), 18 deletions(-)
As usual I'll comment on the review of this patch by Sashiko.
TL;DR: I don't think it should block progress of this patch.
The review by Sashiko flags out of bounds errors. However,
these are addressed by one of your other patches:
- [PATCH net] slip: fix slab-out-of-bounds write in slhc_uncompress()
https://lore.kernel.org/netdev/20260415213359.335657-2-bestswngs@gmail.com/
As noted in my review of that patch, while it seems too late for these
patches, please consider bundling related patches in a patchset in future.
^ permalink raw reply
* Re: [PATCH net] slip: fix slab-out-of-bounds write in slhc_uncompress()
From: Simon Horman @ 2026-04-19 14:56 UTC (permalink / raw)
To: Weiming Shi
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Andrew Morton, Hans Verkuil, Alex Deucher,
Ian Rogers, Jonathan Cameron, Kees Cook, Ingo Molnar, Alan Cox,
netdev
In-Reply-To: <20260419142710.GI280379@horms.kernel.org>
On Sun, Apr 19, 2026 at 03:27:10PM +0100, Simon Horman wrote:
> On Thu, Apr 16, 2026 at 05:34:00AM +0800, Weiming Shi wrote:
> > sl_bump() reserves only 80 bytes of expansion headroom before calling
> > slhc_uncompress(), but the reconstructed IP + TCP header is up to
> > ip->ihl*4 + thp->doff*4 bytes. IHL and TCP doff are 4-bit fields and
> > both can legitimately reach 15, so the header can grow to 2*15*4 =
> > 120 bytes. A VJ-uncompressed primer with ihl=15, doff=15 followed by
> > a compressed frame of size buffsize - 80 therefore writes up to
> > 33 bytes past the kmalloc(buffsize + 4) rbuff allocation, with
> > attacker-controlled content:
> >
> > BUG: KASAN: slab-out-of-bounds in slhc_uncompress
> > Write of size 1069 at addr ffff88800ba93078 by task kworker/u8:1/32
> > Workqueue: events_unbound flush_to_ldisc
> > Call Trace:
> > __asan_memmove+0x3f/0x70
> > slhc_uncompress (drivers/net/slip/slhc.c:614)
> > slip_receive_buf (drivers/net/slip/slip.c:342)
> > tty_ldisc_receive_buf
> > flush_to_ldisc
> >
> > Raise the reservation to match the real worst case. The ppp_generic
> > receive path already enforces skb_tailroom >= 124 and is unaffected.
> >
> > Fixes: b5451d783ade ("slip: Move the SLIP drivers")
> > Reported-by: Simon Horman <horms@kernel.org>
>
> FTR, I was mainly passing on a review generated by Sashiko
>
> > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
>
> Reviewed-by: Simon Horman <horms@kernel.org>
>
> As usual I'll comment on the review of this patch by Sashiko.
>
> TL;DR: I don't think it should block progress of this patch.
>
> The review by Sashiko flags out of bounds errors. However,
> these are addressed by one of your other patches:
>
> - [PATCH net] slip: bound decode() reads against the compressed packet length
> https://lore.kernel.org/netdev/20260416100147.531855-5-bestswngs@gmail.com/
>
> As noted in my review of that patch, while it seems too late for these
> patches, please consider bundling related patches in a patchset in future.
I'm very sorry but the text above results from me muddling
up my response to different slip patches.
I'll post the correct text for this patch elsewhere in this thread.
^ permalink raw reply
* Re: [PATCH net] slip: fix slab-out-of-bounds write in slhc_uncompress()
From: Simon Horman @ 2026-04-19 14:57 UTC (permalink / raw)
To: Weiming Shi
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Andrew Morton, Hans Verkuil, Alex Deucher,
Ian Rogers, Jonathan Cameron, Kees Cook, Ingo Molnar, Alan Cox,
netdev
In-Reply-To: <20260419143233.GK280379@horms.kernel.org>
On Sun, Apr 19, 2026 at 03:32:33PM +0100, Simon Horman wrote:
> On Sun, Apr 19, 2026 at 03:27:26PM +0100, Simon Horman wrote:
> > On Thu, Apr 16, 2026 at 05:34:00AM +0800, Weiming Shi wrote:
> > > sl_bump() reserves only 80 bytes of expansion headroom before calling
> > > slhc_uncompress(), but the reconstructed IP + TCP header is up to
> > > ip->ihl*4 + thp->doff*4 bytes. IHL and TCP doff are 4-bit fields and
> > > both can legitimately reach 15, so the header can grow to 2*15*4 =
> > > 120 bytes. A VJ-uncompressed primer with ihl=15, doff=15 followed by
> > > a compressed frame of size buffsize - 80 therefore writes up to
> > > 33 bytes past the kmalloc(buffsize + 4) rbuff allocation, with
> > > attacker-controlled content:
> > >
> > > BUG: KASAN: slab-out-of-bounds in slhc_uncompress
> > > Write of size 1069 at addr ffff88800ba93078 by task kworker/u8:1/32
> > > Workqueue: events_unbound flush_to_ldisc
> > > Call Trace:
> > > __asan_memmove+0x3f/0x70
> > > slhc_uncompress (drivers/net/slip/slhc.c:614)
> > > slip_receive_buf (drivers/net/slip/slip.c:342)
> > > tty_ldisc_receive_buf
> > > flush_to_ldisc
> > >
> > > Raise the reservation to match the real worst case. The ppp_generic
> > > receive path already enforces skb_tailroom >= 124 and is unaffected.
> > >
> > > Fixes: b5451d783ade ("slip: Move the SLIP drivers")
AI review flags that this patch moved the code, rather than
adding the bug. It suggests the bug has been present since the
beginning of git history, so:
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > Reported-by: Simon Horman <horms@kernel.org>
> >
> > FTR, I was mainly passing on information flagged by Sashiko.
> >
> > > Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> >
> > Reviewed-by: Simon Horman <horms@kernel.org>
>
> I'm very sorry but the text below below was for a different,
> albeit related, patch:
>
> - [PATCH net] slip: bound decode() reads against the compressed packet length
> https://lore.kernel.org/netdev/20260416100147.531855-5-bestswngs@gmail.com/
>
> The corresponding text relating to this patch was posted as:
>
> https://lore.kernel.org/netdev/20260419142710.GI280379@horms.kernel.org/
>
> Sorry for the mix up!
Actually, that's not right either.
I will try one more time:
TL;DR: I don't think that review should block progress of this patch.
1. The issue wrt concurrent MTU changes appears to be a separate,
pre-existing problem. Maybe you've looked into it already,
if not, you may wish to.
2. The bounds checking problems are addressed by other patches in flight.
- [PATCH net v2] slip: reject VJ receive packets on instances with no rstate array
https://lore.kernel.org/netdev/20260415204130.258866-2-bestswngs@gmail.com/
- [PATCH net] slip: bound decode() reads against the compressed packet length
https://lore.kernel.org/netdev/20260416100147.531855-5-bestswngs@gmail.com/
In future you might want to consider creating patch sets for related
patches. But I think it's too late in the case of these patches.
^ permalink raw reply
* [PATCH net v3 1/1] net: l3mdev: Reject non-L3 uppers in slave helpers
From: Ren Wei @ 2026-04-19 14:53 UTC (permalink / raw)
To: netdev, idosch
Cc: dsahern, davem, edumazet, kuba, pabeni, horms, jiri, yifanwucs,
tomapufckgml, yuantan098, bird, royenheart, n05ec
From: Haoze Xie <royenheart@gmail.com>
Several l3mdev slave-side helpers resolve an upper device and then use
l3mdev_ops without first proving that the resolved device is still a
valid L3 master.
During slave transition, an RCU reader can transiently observe an upper
that is not an L3 master. Guard the affected slave-resolved paths by
requiring the resolved upper to still be an L3 master before using
l3mdev_ops, while keeping existing L3 RX handler providers intact.
Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking")
Cc: stable@kernel.org
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Haoze Xie <royenheart@gmail.com>
Signed-off-by: Haoze Xie <royenheart@gmail.com>
Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
---
Changes in v3:
- Extend the same guard to l3mdev_l3_rcv() and l3mdev_l3_out().
- Keep existing IFF_L3MDEV_RX_HANDLER providers such as ipvlan_l3s
working by only applying the extra master check to the slave-resolved
upper case in l3mdev_l3_rcv().
- v2 Link:
https://lore.kernel.org/all/429dd4a81d4ca5624ab9f6d7b53c5fe08552c734.1775443332.git.royenheart@gmail.com/
Changes in v2:
- Point Fixes to the VRF slave ordering change identified in review.
- Add David Ahern's Reviewed-by trailer in that revision.
- v1 Link:
https://lore.kernel.org/all/b3b88cddc7e79d4b43756b26ae5db965678f3ba9.1775062214.git.royenheart@gmail.com/
include/net/l3mdev.h | 18 +++++++++++-------
net/l3mdev/l3mdev.c | 2 +-
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/include/net/l3mdev.h b/include/net/l3mdev.h
index 710e98665eb3..aed52bf03956 100644
--- a/include/net/l3mdev.h
+++ b/include/net/l3mdev.h
@@ -180,14 +180,17 @@ struct sk_buff *l3mdev_l3_rcv(struct sk_buff *skb, u16 proto)
{
struct net_device *master = NULL;
- if (netif_is_l3_slave(skb->dev))
+ if (netif_is_l3_slave(skb->dev)) {
master = netdev_master_upper_dev_get_rcu(skb->dev);
- else if (netif_is_l3_master(skb->dev) ||
- netif_has_l3_rx_handler(skb->dev))
+ if (master && netif_is_l3_master(master) &&
+ master->l3mdev_ops->l3mdev_l3_rcv)
+ skb = master->l3mdev_ops->l3mdev_l3_rcv(master, skb, proto);
+ } else if (netif_is_l3_master(skb->dev) ||
+ netif_has_l3_rx_handler(skb->dev)) {
master = skb->dev;
-
- if (master && master->l3mdev_ops->l3mdev_l3_rcv)
- skb = master->l3mdev_ops->l3mdev_l3_rcv(master, skb, proto);
+ if (master->l3mdev_ops->l3mdev_l3_rcv)
+ skb = master->l3mdev_ops->l3mdev_l3_rcv(master, skb, proto);
+ }
return skb;
}
@@ -215,7 +218,8 @@ struct sk_buff *l3mdev_l3_out(struct sock *sk, struct sk_buff *skb, u16 proto)
struct net_device *master;
master = netdev_master_upper_dev_get_rcu(dev);
- if (master && master->l3mdev_ops->l3mdev_l3_out)
+ if (master && netif_is_l3_master(master) &&
+ master->l3mdev_ops->l3mdev_l3_out)
skb = master->l3mdev_ops->l3mdev_l3_out(master, sk,
skb, proto);
}
diff --git a/net/l3mdev/l3mdev.c b/net/l3mdev/l3mdev.c
index 5432a5f2dfc8..b8a3030cb2c4 100644
--- a/net/l3mdev/l3mdev.c
+++ b/net/l3mdev/l3mdev.c
@@ -177,7 +177,7 @@ u32 l3mdev_fib_table_rcu(const struct net_device *dev)
const struct net_device *master;
master = netdev_master_upper_dev_get_rcu(_dev);
- if (master &&
+ if (master && netif_is_l3_master(master) &&
master->l3mdev_ops->l3mdev_fib_table)
tb_id = master->l3mdev_ops->l3mdev_fib_table(master);
}
--
2.53.0
^ permalink raw reply related
* [PATCH net] ipv6: validate extension header length before copying to cmsg
From: Qi Tang @ 2026-04-19 15:03 UTC (permalink / raw)
To: davem, dsahern, edumazet, kuba, pabeni, horms
Cc: netdev, linux-kernel, Qi Tang
ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR}
cmsgs (and their IPV6_2292* legacy counterparts) by trusting the
on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length.
The length was validated only at parse time (ipv6_parse_hopopts(),
etc.). An nftables payload-write expression can rewrite hdrlen after
parsing and before the skb reaches recvmsg; the write itself is
in-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040
bytes from an 8-byte header. nftables is reachable from an unprivi-
leged user namespace, so this is an unprivileged slab-out-of-bounds
read:
BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540
put_cmsg+0x3ac/0x540
udpv6_recvmsg+0xca0/0x1250
sock_recvmsg+0xdf/0x190
____sys_recvmsg+0x1b1/0x620
Clamp each cmsg length against skb_tail_pointer(skb) before calling
put_cmsg(). Extension headers are kept in the linear skb area by
pskb_may_pull() during input, so skb_tail_pointer() is the correct
bound. The check is replicated at each call site (one HbH, four
RFC2292 sites, and four switch cases in the DSTOPTS/RTHDR/AH walk)
rather than hoisted out of the switch, to keep the fix minimal and
backportable; a follow-up cleanup can factor it out. In the walk
loop a failed check also aborts the walk, since subsequent offsets
depend on the tampered length.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Qi Tang <tpluszz77@gmail.com>
---
net/ipv6/datagram.c | 35 ++++++++++++++++++++++++++++++-----
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index ca3605acb..a7b9f5a24 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -643,7 +643,10 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
/* HbH is allowed only once */
if (np->rxopt.bits.hopopts && (opt->flags & IP6SKB_HOPBYHOP)) {
u8 *ptr = nh + sizeof(struct ipv6hdr);
- put_cmsg(msg, SOL_IPV6, IPV6_HOPOPTS, (ptr[1]+1)<<3, ptr);
+ u16 hbhlen = (ptr[1] + 1) << 3;
+
+ if (ptr + hbhlen <= skb_tail_pointer(skb))
+ put_cmsg(msg, SOL_IPV6, IPV6_HOPOPTS, hbhlen, ptr);
}
if (opt->lastopt &&
@@ -668,27 +671,37 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
case IPPROTO_DSTOPTS:
nexthdr = ptr[0];
len = (ptr[1] + 1) << 3;
+ if (ptr + len > skb_tail_pointer(skb))
+ goto ext_hdr_done;
if (np->rxopt.bits.dstopts)
put_cmsg(msg, SOL_IPV6, IPV6_DSTOPTS, len, ptr);
break;
case IPPROTO_ROUTING:
nexthdr = ptr[0];
len = (ptr[1] + 1) << 3;
+ if (ptr + len > skb_tail_pointer(skb))
+ goto ext_hdr_done;
if (np->rxopt.bits.srcrt)
put_cmsg(msg, SOL_IPV6, IPV6_RTHDR, len, ptr);
break;
case IPPROTO_AH:
nexthdr = ptr[0];
len = (ptr[1] + 2) << 2;
+ if (ptr + len > skb_tail_pointer(skb))
+ goto ext_hdr_done;
break;
default:
nexthdr = ptr[0];
len = (ptr[1] + 1) << 3;
+ if (ptr + len > skb_tail_pointer(skb))
+ goto ext_hdr_done;
break;
}
off += len;
}
+ext_hdr_done:
+ ;
}
/* socket options in old style */
@@ -705,19 +718,31 @@ void ip6_datagram_recv_specific_ctl(struct sock *sk, struct msghdr *msg,
}
if (np->rxopt.bits.ohopopts && (opt->flags & IP6SKB_HOPBYHOP)) {
u8 *ptr = nh + sizeof(struct ipv6hdr);
- put_cmsg(msg, SOL_IPV6, IPV6_2292HOPOPTS, (ptr[1]+1)<<3, ptr);
+ u16 hbhlen = (ptr[1] + 1) << 3;
+
+ if (ptr + hbhlen <= skb_tail_pointer(skb))
+ put_cmsg(msg, SOL_IPV6, IPV6_2292HOPOPTS, hbhlen, ptr);
}
if (np->rxopt.bits.odstopts && opt->dst0) {
u8 *ptr = nh + opt->dst0;
- put_cmsg(msg, SOL_IPV6, IPV6_2292DSTOPTS, (ptr[1]+1)<<3, ptr);
+ u16 doptlen = (ptr[1] + 1) << 3;
+
+ if (ptr + doptlen <= skb_tail_pointer(skb))
+ put_cmsg(msg, SOL_IPV6, IPV6_2292DSTOPTS, doptlen, ptr);
}
if (np->rxopt.bits.osrcrt && opt->srcrt) {
struct ipv6_rt_hdr *rthdr = (struct ipv6_rt_hdr *)(nh + opt->srcrt);
- put_cmsg(msg, SOL_IPV6, IPV6_2292RTHDR, (rthdr->hdrlen+1) << 3, rthdr);
+ u16 rtlen = (rthdr->hdrlen + 1) << 3;
+
+ if ((u8 *)rthdr + rtlen <= skb_tail_pointer(skb))
+ put_cmsg(msg, SOL_IPV6, IPV6_2292RTHDR, rtlen, rthdr);
}
if (np->rxopt.bits.odstopts && opt->dst1) {
u8 *ptr = nh + opt->dst1;
- put_cmsg(msg, SOL_IPV6, IPV6_2292DSTOPTS, (ptr[1]+1)<<3, ptr);
+ u16 doptlen = (ptr[1] + 1) << 3;
+
+ if (ptr + doptlen <= skb_tail_pointer(skb))
+ put_cmsg(msg, SOL_IPV6, IPV6_2292DSTOPTS, doptlen, ptr);
}
if (np->rxopt.bits.rxorigdstaddr) {
struct sockaddr_in6 sin6;
--
2.47.3
^ permalink raw reply related
* [PATCH v2 sched_ext/for-7.1-fixes] sched_ext: Mark scx_sched_hash insecure_elasticity
From: Tejun Heo @ 2026-04-19 15:33 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Graf, David Vernet, Andrea Righi, Changwoo Min,
Emil Tsalapatis, linux-crypto, sched-ext, linux-kernel,
Florian Westphal, netdev, NeilBrown
In-Reply-To: <aeLhQRFPEY24ySIq@gondor.apana.org.au>
scx_sched_hash is inserted into under scx_sched_lock (raw_spinlock_irq)
in scx_link_sched(). rhashtable's sync grow path calls get_random_u32()
and does a GFP_ATOMIC allocation; both acquire regular spinlocks, which
is unsafe under raw_spinlock_t. Set insecure_elasticity to skip the
sync grow.
v2:
- Dropped dsq_hash changes. Insertion is not under raw_spin_lock.
- Switched from no_sync_grow flag to insecure_elasticity.
Fixes: 25037af712eb ("sched_ext: Add rhashtable lookup for sub-schedulers")
Signed-off-by: Tejun Heo <tj@kernel.org>
---
kernel/sched/ext.c | 1 +
1 file changed, 1 insertion(+)
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -32,6 +32,7 @@ static const struct rhashtable_params sc
.key_len = sizeof_field(struct scx_sched, ops.sub_cgroup_id),
.key_offset = offsetof(struct scx_sched, ops.sub_cgroup_id),
.head_offset = offsetof(struct scx_sched, hash_node),
+ .insecure_elasticity = true, /* inserted under scx_sched_lock */
};
static struct rhashtable scx_sched_hash;
^ permalink raw reply
* Re: [PATCH v2 sched_ext/for-7.1-fixes] sched_ext: Mark scx_sched_hash insecure_elasticity
From: Tejun Heo @ 2026-04-19 15:34 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Graf, David Vernet, Andrea Righi, Changwoo Min,
Emil Tsalapatis, linux-crypto, sched-ext, linux-kernel,
Florian Westphal, netdev, NeilBrown
In-Reply-To: <aeT11WIF6kzvifm7@slm.duckdns.org>
Applying the rhashtable patch and sched_ext fix to sched_ext/for-7.1-fixes.
Herbert, if this wasn't what you meant and want the rhashtable patch routed
differently, please let me know.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH net v2] net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()
From: Simon Horman @ 2026-04-19 16:12 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260416-airoha-txq-potential-stall-v2-1-42c732074540@kernel.org>
On Thu, Apr 16, 2026 at 12:30:12PM +0200, Lorenzo Bianconi wrote:
> Since multiple net_device TX queues can share the same hw QDMA TX queue,
> there is no guarantee we have inflight packets queued in hw belonging to a
> net_device TX queue stopped in the xmit path because hw QDMA TX queue
> can be full. In this corner case the net_device TX queue will never be
> re-activated. In order to avoid any potential net_device TX queue stall,
> we need to wake all the net_device TX queues feeding the same hw QDMA TX
> queue in airoha_qdma_tx_napi_poll routine.
>
> Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> Changes in v2:
> - Add txq_stopped parameter to avoid any possible corner cases where the
> netdev queue stalls.
> - Link to v1: https://lore.kernel.org/r/20260413-airoha-txq-potential-stall-v1-1-7830363b1543@kernel.org
Reviewed-by: Simon Horman <horms@kernel.org>
FTR, I believe Sashiko's review does not need to block progress of this
patch as it flags pre-existing conditions.
^ permalink raw reply
* Re: [PATCH net-next v3 12/12] selftests: net: Add a test for BIG TCP in UDP tunnels
From: Alice Mikityanska @ 2026-04-19 16:24 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Alice Mikityanska, Daniel Borkmann, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Xin Long, David Ahern,
Nikolay Aleksandrov, Shuah Khan, Stanislav Fomichev, Andrew Lunn,
Simon Horman, Florian Westphal, netdev
In-Reply-To: <willemdebruijn.kernel.cb6bcf72d6ec@gmail.com>
On Thu, 16 Apr 2026 at 14:06, Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> Alice Mikityanska wrote:
> > From: Alice Mikityanska <alice@isovalent.com>
> >
> > The test sets up VXLAN and GENEVE tunnels over IPv4 and IPv6 and runs
> > IPv4 and IPv6 traffic through them with BIG TCP enabled. It checks that
> > a non-negligible amount of big aggregated packets are seen in tcpdump.
> >
> > Signed-off-by: Alice Mikityanska <alice@isovalent.com>
> > ---
> > tools/testing/selftests/net/Makefile | 1 +
> > .../testing/selftests/net/big_tcp_tunnels.sh | 145 ++++++++++++++++++
> > 2 files changed, 146 insertions(+)
> > create mode 100755 tools/testing/selftests/net/big_tcp_tunnels.sh
> >
> > diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
> > index cab74ebdaced..c8ea9d4bb94f 100644
> > --- a/tools/testing/selftests/net/Makefile
> > +++ b/tools/testing/selftests/net/Makefile
> > @@ -13,6 +13,7 @@ TEST_PROGS := \
> > arp_ndisc_untracked_subnets.sh \
> > bareudp.sh \
> > big_tcp.sh \
> > + big_tcp_tunnels.sh \
> > bind_bhash.sh \
> > bpf_offload.py \
> > bridge_vlan_dump.sh \
> > diff --git a/tools/testing/selftests/net/big_tcp_tunnels.sh b/tools/testing/selftests/net/big_tcp_tunnels.sh
> > new file mode 100755
> > index 000000000000..b819911519ac
> > --- /dev/null
> > +++ b/tools/testing/selftests/net/big_tcp_tunnels.sh
> > @@ -0,0 +1,145 @@
> > +#!/usr/bin/env bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +#
> > +# Testing for IPv4 and IPv6 BIG TCP over VXLAN and GENEVE tunnels.
> > +
> > +SERVER_NS=$(mktemp -u server-XXXXXXXX)
> > +SERVER_IP4="192.168.1.1"
> > +SERVER_IP6="2001:db8::1:1"
> > +SERVER_IP4_TUN="192.168.2.1"
> > +SERVER_IP6_TUN="2001:db8::2:1"
> > +
> > +CLIENT_NS=$(mktemp -u client-XXXXXXXX)
> > +CLIENT_IP4="192.168.1.2"
> > +CLIENT_IP6="2001:db8::1:2"
> > +CLIENT_IP4_TUN="192.168.2.2"
> > +CLIENT_IP6_TUN="2001:db8::2:2"
> > +
> > +PACKETS_THRESHOLD=10000
> > +
> > +# Kselftest framework requirement - SKIP code is 4.
> > +ksft_skip=4
> > +
> > +setup() {
> > + ip netns add "$SERVER_NS"
> > + ip netns add "$CLIENT_NS"
> > + ip -netns "$SERVER_NS" link add link1 type veth peer name link0 netns "$CLIENT_NS"
> > +
> > + ip -netns "$CLIENT_NS" link set link0 up
> > + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP4/24" dev link0
> > + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP6/112" dev link0 nodad
> > + ip -netns "$CLIENT_NS" link set link0 \
> > + gso_max_size 196608 gso_ipv4_max_size 196608 \
> > + gro_max_size 196608 gro_ipv4_max_size 196608
> > + ip -netns "$SERVER_NS" link set link1 up
> > + ip -netns "$SERVER_NS" addr replace "$SERVER_IP4/24" dev link1
> > + ip -netns "$SERVER_NS" addr replace "$SERVER_IP6/112" dev link1 nodad
> > + ip -netns "$SERVER_NS" link set link1 \
> > + gso_max_size 196608 gso_ipv4_max_size 196608 \
> > + gro_max_size 196608 gro_ipv4_max_size 196608
> > +
> > + ip netns exec "$SERVER_NS" netserver >/dev/null
> > +}
> > +
> > +setup_tunnel() {
> > + if [ "$2" = 4 ]; then
> > + SERVER_IP="$SERVER_IP4"
> > + CLIENT_IP="$CLIENT_IP4"
> > + echo "Setting up ${1^^} over IPv4"
> > + else
> > + SERVER_IP="$SERVER_IP6"
> > + CLIENT_IP="$CLIENT_IP6"
> > + echo "Setting up ${1^^} over IPv6"
> > + fi
> > +
> > + if [ "$1" = vxlan ]; then
> > + ip -netns "$CLIENT_NS" link add tun0 type vxlan \
> > + id 5001 remote "$SERVER_IP" local "$CLIENT_IP" dev link0 dstport 4789
> > + else
> > + ip -netns "$CLIENT_NS" link add tun0 type geneve \
> > + id 5001 remote "$SERVER_IP"
> > + fi
> > + ip -netns "$CLIENT_NS" link set tun0 up
> > + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP4_TUN/24" dev tun0
> > + ip -netns "$CLIENT_NS" addr replace "$CLIENT_IP6_TUN/112" dev tun0 nodad
> > + ip -netns "$CLIENT_NS" link set tun0 \
> > + gso_max_size 196608 gso_ipv4_max_size 196608 \
> > + gro_max_size 196608 gro_ipv4_max_size 196608
> > + if [ "$1" = vxlan ]; then
> > + ip -netns "$SERVER_NS" link add tun1 type vxlan \
> > + id 5001 remote "$CLIENT_IP" local "$SERVER_IP" dev link1 dstport 4789
> > + else
> > + ip -netns "$SERVER_NS" link add tun1 type geneve \
> > + id 5001 remote "$CLIENT_IP"
> > + fi
> > + ip -netns "$SERVER_NS" link set tun1 up
> > + ip -netns "$SERVER_NS" addr replace "$SERVER_IP4_TUN/24" dev tun1
> > + ip -netns "$SERVER_NS" addr replace "$SERVER_IP6_TUN/112" dev tun1 nodad
> > + ip -netns "$SERVER_NS" link set tun1 \
> > + gso_max_size 196608 gso_ipv4_max_size 196608 \
> > + gro_max_size 196608 gro_ipv4_max_size 196608
> > +}
> > +
> > +cleanup_tunnel() {
> > + ip -netns "$CLIENT_NS" link del tun0
> > + ip -netns "$SERVER_NS" link del tun1
> > +}
> > +
> > +cleanup() {
> > + ip netns exec "$SERVER_NS" killall netserver
> > + ip netns del "$SERVER_NS"
> > + ip netns del "$CLIENT_NS"
> > +}
> > +
> > +do_test() {
> > + exec 3< <(ip netns exec "$SERVER_NS" tcpdump -nn -i link1 greater 65536 2> /dev/null)
> > + TCPDUMP_SERVER_PID="$!"
> > + exec 4< <(wc -l <&3)
> > + exec 5< <(ip netns exec "$CLIENT_NS" tcpdump -nn -i link0 greater 65536 2> /dev/null)
> > + TCPDUMP_CLIENT_PID="$!"
> > + exec 6< <(wc -l <&5)
> > +
> > + if [ "$1" = 4 ]; then
> > + SERVER_IP="$SERVER_IP4_TUN"
> > + echo "Running IPv4 traffic in the tunnel"
> > + else
> > + SERVER_IP="$SERVER_IP6_TUN"
> > + echo "Running IPv6 traffic in the tunnel"
> > + fi
> > +
> > + ip netns exec "$CLIENT_NS" netperf -t TCP_STREAM -l 5 -H "$SERVER_IP" -- \
> > + -r 80000:80000 > /dev/null
>
> is -r valid for TCP_STREAM
Yes, it controls how much data is sent in one send() syscall. If I set
a smaller size, the kernel will still try to aggregate the packets,
but there will be much fewer BIG TCP packets.
> > + kill "$TCPDUMP_SERVER_PID" "$TCPDUMP_CLIENT_PID"
> > + wait "$TCPDUMP_SERVER_PID" "$TCPDUMP_CLIENT_PID"
> > + PACKETS_SERVER=$(cat <&4)
> > + PACKETS_CLIENT=$(cat <&6)
> > + exec 3>&- 4>&- 5>&- 6>&-
> > +
> > + # One line is empty, each packet is two lines (inner and outer).
> > + echo "Captured BIG TCP GRO packets: $(((PACKETS_SERVER - 1) / 2))"
> > + echo "Captured BIG TCP GSO packets: $(((PACKETS_CLIENT - 1) / 2))"
> > + [ "$PACKETS_SERVER" -gt "$(( PACKETS_THRESHOLD * 2 + 1))" ] || return 1
> > + [ "$PACKETS_CLIENT" -gt "$(( PACKETS_THRESHOLD * 2 + 1))" ] || return 1
> > +}
> > +
> > +if ! netperf -V &> /dev/null; then
> > + echo "SKIP: Could not run test without netperf tool"
> > + exit "$ksft_skip"
> > +fi
> > +
> > +if ! ip link help 2>&1 | grep gso_ipv4_max_size &> /dev/null; then
> > + echo "SKIP: Could not run test without gso/gro_ipv4_max_size supported in ip-link"
> > + exit "$ksft_skip"
> > +fi
> > +
> > +trap cleanup EXIT
> > +setup
> > +for tunnel in vxlan geneve; do
> > + for tun_family in 4 6; do
> > + for traffic_family in 4 6; do
> > + setup_tunnel "$tunnel" "$tun_family" || exit "$?"
> > + do_test "$traffic_family" || exit "$?"
> > + cleanup_tunnel
> > + done
> > + done
> > +done
> > --
> > 2.53.0
> >
>
>
^ permalink raw reply
* [PATCH bpf] bpf: Fix NULL pointer dereference in bpf_skb_fib_lookup()
From: Weiming Shi @ 2026-04-19 17:01 UTC (permalink / raw)
To: Martin KaFai Lau, Daniel Borkmann, Alexei Starovoitov,
Andrii Nakryiko, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: John Fastabend, Stanislav Fomichev, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Simon Horman,
Jesper Dangaard Brouer, bpf, netdev, Xiang Mei, Weiming Shi
When tot_len is not provided by the user, bpf_skb_fib_lookup()
resolves the FIB result's output device via dev_get_by_index_rcu()
to check skb forwardability and fill in mtu_result. The returned
pointer is dereferenced without a NULL check. If the device is
concurrently unregistered, dev_get_by_index_rcu() returns NULL and
is_skb_forwardable() crashes at dev->flags:
KASAN: null-ptr-deref in range
[0x00000000000000b0-0x00000000000000b7]
Call Trace:
is_skb_forwardable (include/linux/netdevice.h:4365)
bpf_skb_fib_lookup (net/core/filter.c:6446)
bpf_prog_test_run_skb (net/bpf/test_run.c)
__sys_bpf (kernel/bpf/syscall.c)
Add the missing NULL check, returning -ENODEV to be consistent
with how bpf_ipv4_fib_lookup() and bpf_ipv6_fib_lookup() handle
the same condition.
Fixes: e1850ea9bd9e ("bpf: bpf_fib_lookup return MTU value as output when looked up")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
net/core/filter.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index 78b548158fb0..3e56b567bd18 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -6450,6 +6450,8 @@ BPF_CALL_4(bpf_skb_fib_lookup, struct sk_buff *, skb,
* against MTU of FIB lookup resulting net_device
*/
dev = dev_get_by_index_rcu(net, params->ifindex);
+ if (!dev)
+ return -ENODEV;
if (!is_skb_forwardable(dev, skb))
rc = BPF_FIB_LKUP_RET_FRAG_NEEDED;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] net: dsa: realtek: rtl8365mb: fix mode mask calculation
From: Luiz Angelo Daros de Luca @ 2026-04-19 19:08 UTC (permalink / raw)
To: Mieczyslaw Nalewaj, alrazj.abdulkader; +Cc: netdev
In-Reply-To: <c1519cfa-5a66-48b6-a578-e0ac03a57484@yahoo.com>
> The RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK macro was shifting
> the 4-bit mask (0xF) by only (_extint % 2) bits instead of
> (_extint % 2) * 4. This caused the mask to overlap with the adjacent
> nibble when configuring odd-numbered external interfaces, selecting
> the wrong bits entirely.
>
> Align the shift calculation with the existing ...MODE_OFFSET macro.
>
> Signed-off-by: Abdulkader Alrezej <alrazj.abdulkader@gmail.com>
> Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
> ---
> drivers/net/dsa/realtek/rtl8365mb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/realtek/rtl8365mb.c b/drivers/net/dsa/realtek/rtl8365mb.c
> index ad7044b295ec..b85c99216648 100644
> --- a/drivers/net/dsa/realtek/rtl8365mb.c
> +++ b/drivers/net/dsa/realtek/rtl8365mb.c
> @@ -216,7 +216,7 @@
> (_extint) == 2 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG1 : \
> 0x0)
> #define RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK(_extint) \
> - (0xF << (((_extint) % 2)))
> + (0xF << (((_extint) % 2) * 4))
> #define RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_OFFSET(_extint) \
> (((_extint) % 2) * 4)
>
Hello Abdulkader and Mieczyslaw,
This bug has been present since the subdriver submission. I renamed
the macro (d18b59f48b318) but I didn't change the logic. Maybe we just
got luck with defaults. The patch is good. You still missed the Fixes
tag. Just add before the first Signed-off-by:
Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver
for RTL8365MB-VC")
With that addiction, you can submit v2 with my Reviewed-by:
Regards,
Luiz
^ permalink raw reply
* [PATCH] idpf: do not perform flow ops when netdev is detached
From: Li Li @ 2026-04-19 19:25 UTC (permalink / raw)
To: Tony Nguyen, Przemek Kitszel, David S. Miller, Jakub Kicinski,
Eric Dumazet, intel-wired-lan
Cc: netdev, linux-kernel, David Decotigny, Anjali Singhai,
Sridhar Samudrala, Brian Vazquez, Li Li, emil.s.tantilov
Even though commit 2e281e1155fc ("idpf: detach and close netdevs while
handling a reset") prevents ethtool -N/-n operations to operate on
detached netdevs, we found that out-of-tree workflows like OpenOnload
can bypass ethtool core locks and call idpf_set_rxnfc directly during
an idpf HW reset. When this happens, we could get kernel crashes like
the following:
[ 4045.787439] BUG: kernel NULL pointer dereference, address: 0000000000000070
[ 4045.794420] #PF: supervisor read access in kernel mode
[ 4045.799580] #PF: error_code(0x0000) - not-present page
[ 4045.804739] PGD 0
[ 4045.806772] Oops: Oops: 0000 [#1] SMP NOPTI
...
[ 4045.836425] Workqueue: onload-wqueue oof_do_deferred_work_fn [onload]
[ 4045.842926] RIP: 0010:idpf_del_flow_steer+0x24/0x170 [idpf]
...
[ 4045.946323] Call Trace:
[ 4045.948796] <TASK>
[ 4045.950915] ? show_trace_log_lvl+0x1b0/0x2f0
[ 4045.955293] ? show_trace_log_lvl+0x1b0/0x2f0
[ 4045.959672] ? idpf_set_rxnfc+0x6f/0x80 [idpf]
[ 4045.964142] ? __die_body.cold+0x8/0x12
[ 4045.968000] ? page_fault_oops+0x148/0x160
[ 4045.972117] ? exc_page_fault+0x6f/0x160
[ 4045.976060] ? asm_exc_page_fault+0x22/0x30
[ 4045.980262] ? idpf_del_flow_steer+0x24/0x170 [idpf]
[ 4045.985245] idpf_set_rxnfc+0x6f/0x80 [idpf]
[ 4045.989535] af_xdp_filter_remove+0x7c/0xb0 [sfc_resource]
[ 4045.995069] oo_hw_filter_clear_hwports+0x6f/0xa0 [onload]
[ 4046.000589] oo_hw_filter_update+0x65/0x210 [onload]
[ 4046.005587] oof_hw_filter_update.constprop.0+0xe7/0x140 [onload]
[ 4046.011716] oof_manager_update_all_filters+0xad/0x270 [onload]
[ 4046.017671] __oof_do_deferred_work+0x15e/0x190 [onload]
[ 4046.023014] oof_do_deferred_work+0x2c/0x40 [onload]
[ 4046.028018] oof_do_deferred_work_fn+0x12/0x30 [onload]
[ 4046.033277] process_one_work+0x174/0x330
[ 4046.037304] worker_thread+0x246/0x390
[ 4046.041074] ? __pfx_worker_thread+0x10/0x10
[ 4046.045364] kthread+0xf6/0x240
[ 4046.048530] ? __pfx_kthread+0x10/0x10
[ 4046.052297] ret_from_fork+0x2d/0x50
[ 4046.055896] ? __pfx_kthread+0x10/0x10
[ 4046.059664] ret_from_fork_asm+0x1a/0x30
[ 4046.063613] </TASK>
To prevent this, we need to add checks in idpf_set_rxnfc and
idpf_get_rxnfc to error out if the netdev is already detached.
Tested: implemented the following patch to synthetically force idpf into
a HW reset:
diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
index 4fc0bb14c5b1..27476d57bcf0 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
@@ -10,6 +10,9 @@
#define idpf_tx_buf_next(buf) (*(u32 *)&(buf)->priv)
LIBETH_SQE_CHECK_PRIV(u32);
+static bool SIMULATE_TX_TIMEOUT;
+module_param(SIMULATE_TX_TIMEOUT, bool, 0644);
+
/**
* idpf_chk_linearize - Check if skb exceeds max descriptors per packet
* @skb: send buffer
@@ -46,6 +49,8 @@ void idpf_tx_timeout(struct net_device *netdev, unsigned int txqueue)
adapter->tx_timeout_count++;
+ SIMULATE_TX_TIMEOUT = false;
+
netdev_err(netdev, "Detected Tx timeout: Count %d, Queue %d\n",
adapter->tx_timeout_count, txqueue);
if (!idpf_is_reset_in_prog(adapter)) {
@@ -2225,6 +2230,8 @@ static bool idpf_tx_clean_complq(struct idpf_compl_queue *complq, int budget,
goto fetch_next_desc;
}
tx_q = complq->txq_grp->txqs[rel_tx_qid];
+ if (unlikely(SIMULATE_TX_TIMEOUT && (tx_q->idx % 2 == 1)))
+ goto fetch_next_desc;
/* Determine completion type */
ctype = le16_get_bits(tx_desc->common.qid_comptype_gen,
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
index be66f9b2e101..ba5da2a86c15 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
@@ -8,6 +8,9 @@
#include "idpf_virtchnl.h"
#include "idpf_ptp.h"
+static bool VIRTCHNL_FAILED;
+module_param(VIRTCHNL_FAILED, bool, 0644);
+
/**
* struct idpf_vc_xn_manager - Manager for tracking transactions
* @ring: backing and lookup for transactions
@@ -3496,6 +3499,11 @@ int idpf_vc_core_init(struct idpf_adapter *adapter)
switch (adapter->state) {
case __IDPF_VER_CHECK:
err = idpf_send_ver_msg(adapter);
+
+ if (unlikely(VIRTCHNL_FAILED)) {
+ err = -EIO;
+ }
+
switch (err) {
case 0:
/* success, move state machine forward */
And tested by writing 1 to /sys/module/idpf/parameters/VIRTCHNL_FAILED
and /sys/module/idpf/parameters/SIMULATE_TX_TIMEOUT, and running
idpf_get_rxnfc() right after the HW reset.
Without the patch: encountered NULL pointer and kernel crash.
With the patch: no crashes.
Fixes: 2e281e1155fc ("idpf: detach and close netdevs while handling a reset")
Signed-off-by: Li Li <boolli@google.com>
---
drivers/net/ethernet/intel/idpf/idpf_ethtool.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
index bb99d9e7c65d..8368a7e6a754 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
@@ -43,6 +43,9 @@ static int idpf_get_rxnfc(struct net_device *netdev, struct ethtool_rxnfc *cmd,
unsigned int cnt = 0;
int err = 0;
+ if (!netdev || !netif_device_present(netdev))
+ return -ENODEV;
+
idpf_vport_ctrl_lock(netdev);
vport = idpf_netdev_to_vport(netdev);
vport_config = np->adapter->vport_config[np->vport_idx];
@@ -349,6 +352,9 @@ static int idpf_set_rxnfc(struct net_device *netdev, struct ethtool_rxnfc *cmd)
{
int ret = -EOPNOTSUPP;
+ if (!netdev || !netif_device_present(netdev))
+ return -ENODEV;
+
idpf_vport_ctrl_lock(netdev);
switch (cmd->cmd) {
case ETHTOOL_SRXCLSRLINS:
--
2.54.0.rc1.513.gad8abe7a5a-goog
^ permalink raw reply related
* Re: [PATCH] Document TCP_DEFER_ACCEPT rounding
From: Alejandro Colomar @ 2026-04-19 19:45 UTC (permalink / raw)
To: Josh Triplett; +Cc: linux-man, netdev
In-Reply-To: <43b64cba-a7c5-41ed-8e45-c0508f482687@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 193 bytes --]
Hi Josh,
On 2026-04-16T14:57:19-0700, Josh Triplett wrote:
> Patch attached.
Thanks! I've applied the patch.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 4/9] iio: magnetometer: yas530: switch to using FIELD_GET_SIGNED()
From: Linus Walleij @ 2026-04-19 20:11 UTC (permalink / raw)
To: Yury Norov
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Ping-Ke Shih,
Richard Cochran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Alexandre Belloni, Yury Norov,
Rasmus Villemoes, Hans de Goede, Sakari Ailus, Salah Triki,
Achim Gratz, Ben Collins, linux-kernel, linux-iio, linux-wireless,
netdev, linux-rtc
In-Reply-To: <20260417173621.368914-5-ynorov@nvidia.com>
On Fri, Apr 17, 2026 at 7:36 PM Yury Norov <ynorov@nvidia.com> wrote:
> Switch from sign_extend32(FIELD_GET()) to the dedicated
> FIELD_GET_SIGNED() and don't calculate the fields length explicitly.
>
> Signed-off-by: Yury Norov <ynorov@nvidia.com>
Very nice,
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] net: dsa: realtek: rtl8365mb: fix mode mask calculation
From: Mieczyslaw Nalewaj @ 2026-04-19 19:37 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <400a6387-a444-4576-af6d-26be5410bce3.ref@yahoo.com>
The RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK macro was shifting
the 4-bit mask (0xF) by only (_extint % 2) bits instead of
(_extint % 2) * 4. This caused the mask to overlap with the adjacent
nibble when configuring odd-numbered external interfaces, selecting
the wrong bits entirely.
Align the shift calculation with the existing ...MODE_OFFSET macro.
Fixes: 4af2950c50c8 ("net: dsa: realtek-smi: add rtl8365mb subdriver for RTL8365MB-VC")
Signed-off-by: Abdulkader Alrezej <alrazj.abdulkader@gmail.com>
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
---
drivers/net/dsa/realtek/rtl8365mb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/realtek/rtl8365mb.c b/drivers/net/dsa/realtek/rtl8365mb.c
index ad7044b295ec..b85c99216648 100644
--- a/drivers/net/dsa/realtek/rtl8365mb.c
+++ b/drivers/net/dsa/realtek/rtl8365mb.c
@@ -216,7 +216,7 @@
(_extint) == 2 ? RTL8365MB_DIGITAL_INTERFACE_SELECT_REG1 : \
0x0)
#define RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_MASK(_extint) \
- (0xF << (((_extint) % 2)))
+ (0xF << (((_extint) % 2) * 4))
#define RTL8365MB_DIGITAL_INTERFACE_SELECT_MODE_OFFSET(_extint) \
(((_extint) % 2) * 4)
--
2.53.0
^ permalink raw reply related
* [PATCH] connector/Kconfig: Enable CONFIG_CONNECTOR by default
From: Qais Yousef @ 2026-04-19 21:42 UTC (permalink / raw)
To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: netdev, linux-kernel, Vincent Guittot, John Stultz,
Steven Rostedt, Qais Yousef
To make new tools that depend on it like schedqos [1] more reliable, it
is important to ensure users can find it by default on all system.
[1] https://lore.kernel.org/lkml/20260415000910.2h5misvwc45bdumu@airbuntu/
Signed-off-by: Qais Yousef <qyousef@layalina.io>
---
drivers/connector/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/connector/Kconfig b/drivers/connector/Kconfig
index 0c2d2aa82d8c..bad247d47146 100644
--- a/drivers/connector/Kconfig
+++ b/drivers/connector/Kconfig
@@ -3,6 +3,7 @@
menuconfig CONNECTOR
tristate "Connector - unified userspace <-> kernelspace linker"
depends on NET
+ default y
help
This is unified userspace <-> kernelspace connector working on top
of the netlink socket protocol.
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Andrey Konovalov @ 2026-04-19 21:48 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CAADnVQKv5y+gq=TnOAEXSqgBRpmHNjwqCfxpLaw5XkcbQ+23bg@mail.gmail.com>
On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> I think we're talking past each other.
> We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
> We're not going to modify arm64 JIT at all.
>
> This is purely KASAN_GENRIC and only on x86-64.
> JIT will emit exactly what compilers emit for generic
> which is __asan_load/store. This is as stable ABI as it can get
> and we don't want to deviate from it.
OK, I supposed that's fair. You did throw me off point with your
performance comment. But if you decide to add SW_TAGS support at some
point, I think this discussion needs to be revisited.
But please add a comment saying that those functions are only exposed
for BPF JIT and they are not supposed to be used by other parts of the
kernel. And in case you do end up adding a new config option, guard
the public declarations by a corresponding ifdef.
> The goal here is to find bugs in the verifier.
> If something got past it, that shouldn't have,
> kasan generic on x86-64 is enough.
FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code.
^ permalink raw reply
* [PATCH] xfrm: ah: account for ESN high bits in async callbacks
From: Michael Bommarito @ 2026-04-19 22:35 UTC (permalink / raw)
To: Steffen Klassert, Herbert Xu, netdev
Cc: David S . Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Fan Du, linux-kernel, stable
AH allocates its temporary auth/ICV layout differently when ESN is enabled:
the async ahash setup appends a 4-byte seqhi slot before the ICV or
auth_data area, but the async completion callbacks still reconstruct the
temporary layout as if seqhi were absent.
With an async AH implementation selected, that makes AH copy or compare
the wrong bytes on both the IPv4 and IPv6 paths. In UML repro on IPv4 AH
with ESN and forced async hmac(sha1), ping fails with 100% packet loss,
and the callback logs show the pre-fix drift:
ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24
ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36
Reconstruct the callback-side layout the same way the setup path built it
by skipping the ESN seqhi slot before locating the saved auth_data or ICV.
Per RFC 4302, the ESN high-order 32 bits participate in the AH ICV
computation, so the async callbacks must account for the seqhi slot.
Post-fix, the same IPv4 AH+ESN+forced-async-hmac(sha1) UML repro shows
the corrected offset (ah4 output_done: esn=1 err=0 icv_off=24
expected_off=24) and ping succeeds; net/ipv4/ah4.o and net/ipv6/ah6.o
build clean at W=1. IPv6 AH+ESN was not exercised at runtime, and the
change has not been tested against a real async hardware AH engine.
Fixes: d4d573d0334d ("{IPv4,xfrm} Add ESN support for AH egress part")
Fixes: d8b2a8600b0e ("{IPv4,xfrm} Add ESN support for AH ingress part")
Fixes: 26dd70c3fad3 ("{IPv6,xfrm} Add ESN support for AH egress part")
Fixes: 8d6da6f32557 ("{IPv6,xfrm} Add ESN support for AH ingress part")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5-4
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
net/ipv4/ah4.c | 14 ++++++++++++--
net/ipv6/ah6.c | 14 ++++++++++++--
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 5fb812443a08..4366cbac3f06 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -124,9 +124,14 @@ static void ah_output_done(void *data, int err)
struct iphdr *top_iph = ip_hdr(skb);
struct ip_auth_hdr *ah = ip_auth_hdr(skb);
int ihl = ip_hdrlen(skb);
+ int seqhi_len = 0;
+ __be32 *seqhi;
+ if (x->props.flags & XFRM_STATE_ESN)
+ seqhi_len = sizeof(*seqhi);
iph = AH_SKB_CB(skb)->tmp;
- icv = ah_tmp_icv(iph, ihl);
+ seqhi = (__be32 *)((char *)iph + ihl);
+ icv = ah_tmp_icv(seqhi, seqhi_len);
memcpy(ah->auth_data, icv, ahp->icv_trunc_len);
top_iph->tos = iph->tos;
@@ -270,12 +275,17 @@ static void ah_input_done(void *data, int err)
struct ip_auth_hdr *ah = ip_auth_hdr(skb);
int ihl = ip_hdrlen(skb);
int ah_hlen = (ah->hdrlen + 2) << 2;
+ int seqhi_len = 0;
+ __be32 *seqhi;
if (err)
goto out;
+ if (x->props.flags & XFRM_STATE_ESN)
+ seqhi_len = sizeof(*seqhi);
work_iph = AH_SKB_CB(skb)->tmp;
- auth_data = ah_tmp_auth(work_iph, ihl);
+ seqhi = (__be32 *)((char *)work_iph + ihl);
+ auth_data = ah_tmp_auth(seqhi, seqhi_len);
icv = ah_tmp_icv(auth_data, ahp->icv_trunc_len);
err = crypto_memneq(icv, auth_data, ahp->icv_trunc_len) ? -EBADMSG : 0;
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index cb26beea4398..de1e68199a01 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -317,14 +317,19 @@ static void ah6_output_done(void *data, int err)
struct ipv6hdr *top_iph = ipv6_hdr(skb);
struct ip_auth_hdr *ah = ip_auth_hdr(skb);
struct tmp_ext *iph_ext;
+ int seqhi_len = 0;
+ __be32 *seqhi;
extlen = skb_network_header_len(skb) - sizeof(struct ipv6hdr);
if (extlen)
extlen += sizeof(*iph_ext);
+ if (x->props.flags & XFRM_STATE_ESN)
+ seqhi_len = sizeof(*seqhi);
iph_base = AH_SKB_CB(skb)->tmp;
iph_ext = ah_tmp_ext(iph_base);
- icv = ah_tmp_icv(iph_ext, extlen);
+ seqhi = (__be32 *)((char *)iph_ext + extlen);
+ icv = ah_tmp_icv(seqhi, seqhi_len);
memcpy(ah->auth_data, icv, ahp->icv_trunc_len);
memcpy(top_iph, iph_base, IPV6HDR_BASELEN);
@@ -471,13 +476,18 @@ static void ah6_input_done(void *data, int err)
struct ip_auth_hdr *ah = ip_auth_hdr(skb);
int hdr_len = skb_network_header_len(skb);
int ah_hlen = ipv6_authlen(ah);
+ int seqhi_len = 0;
+ __be32 *seqhi;
if (err)
goto out;
+ if (x->props.flags & XFRM_STATE_ESN)
+ seqhi_len = sizeof(*seqhi);
work_iph = AH_SKB_CB(skb)->tmp;
auth_data = ah_tmp_auth(work_iph, hdr_len);
- icv = ah_tmp_icv(auth_data, ahp->icv_trunc_len);
+ seqhi = (__be32 *)(auth_data + ahp->icv_trunc_len);
+ icv = ah_tmp_icv(seqhi, seqhi_len);
err = crypto_memneq(icv, auth_data, ahp->icv_trunc_len) ? -EBADMSG : 0;
if (err)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexei Starovoitov @ 2026-04-19 22:51 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZe-b0Qqbo5gGv3HN20twquQETDfYYkE1r9tPr9zUFbW9Q@mail.gmail.com>
On Sun, Apr 19, 2026 at 2:49 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > I think we're talking past each other.
> > We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
> > We're not going to modify arm64 JIT at all.
> >
> > This is purely KASAN_GENRIC and only on x86-64.
> > JIT will emit exactly what compilers emit for generic
> > which is __asan_load/store. This is as stable ABI as it can get
> > and we don't want to deviate from it.
>
> OK, I supposed that's fair. You did throw me off point with your
> performance comment. But if you decide to add SW_TAGS support at some
> point, I think this discussion needs to be revisited.
>
> But please add a comment saying that those functions are only exposed
> for BPF JIT and they are not supposed to be used by other parts of the
> kernel. And in case you do end up adding a new config option, guard
> the public declarations by a corresponding ifdef.
I feel concerns of misuse are overblown.
Being in include/linux/kasan.h doesn't make them free-for-all
all of a sudden, but if you prefer we can just copy paste:
+void __asan_load1(void *p);
+void __asan_store1(void *p);
into bpf_jit_comp.c
> > The goal here is to find bugs in the verifier.
> > If something got past it, that shouldn't have,
> > kasan generic on x86-64 is enough.
>
> FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code.
Ohh. Good point. Looks like modern arm64 cpus in public clouds
don't have that enabled, so one would need pixel phone to
catch verifier bugs via hw_tags.
So we still need this x86-specific jit kasan.
I guess eventually it can be removed when hw_tags support is widespread.
^ permalink raw reply
* Re: [PATCH net v2] ibmveth: Disable GSO for packets with small MSS
From: mingming cao @ 2026-04-20 0:12 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, davem, edumazet, pabeni, horms, bjking1, haren, ricklind,
maddy, mpe, linuxppc-dev, stable, shaik.abdulla1, naveedaus
In-Reply-To: <20260418175451.122193-1-kuba@kernel.org>
On 4/18/26 10:54 AM, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
Thanks for the review and the questions!
> ---
> ibmveth: Disable GSO for packets with small MSS
>
> This commit adds an ndo_features_check callback to the ibmveth driver to
> disable segmentation offload when the MSS is less than 224 bytes. This
> prevents physical adapters in SEA configurations from freezing when given
> small MSS packets.
>
>> diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c
>> --- a/drivers/net/ethernet/ibm/ibmveth.c
>> +++ b/drivers/net/ethernet/ibm/ibmveth.c
> [ ... ]
>
>> @@ -1756,6 +1756,25 @@ static int ibmveth_set_mac_addr(struct net_device *dev, void *p)
>> return 0;
>> }
>>
>> +static netdev_features_t ibmveth_features_check(struct sk_buff *skb,
>> + struct net_device *dev,
>> + netdev_features_t features)
>> +{
>> + /* Some physical adapters do not support segmentation offload with
>> + * MSS < 224. Disable GSO for such packets to avoid adapter freeze.
>> + */
>> + if (skb_is_gso(skb)) {
> The commit message mentions this matches the ibmvnic hardware errata from
> commit f10b09ef687f. That commit disabled GSO for both gso_size < 224 and
> gso_segs == 1.
>
> By omitting the check for skb_shinfo(skb)->gso_segs == 1, could a
> single-segment GSO packet still cause the adapter to freeze?
Good question. Unlike ibmvnic, ibmveth does not need to check for
single-segment GSO packets (gso_segs == 1).
In ibmvnic, the firmware processes all GSO packets, including
single-segment ones, through the same LSO code path. This means even
gso_segs == 1 packets can trigger the hardware errata.
In ibmveth, the PowerVM hypervisor intelligently bypasses the LSO path
for single-segment packets. When gso_segs == 1, the hypervisor treats
the packet as a regular (non-GSO) packet and transmits it directly
without invoking the problematic hardware segmentation logic. Therefore,
single-segment GSO packets never reach the code path that causes the freeze.
This architectural difference is why ibmvnic needs the gso_segs check
but ibmveth does not.
>
>> + if (skb_shinfo(skb)->gso_size < IBMVETH_MIN_LSO_MSS) {
>> + netdev_warn_once(dev,
>> + "MSS %u too small for LSO, disabling GSO\n",
>> + skb_shinfo(skb)->gso_size);
>> + features &= ~NETIF_F_GSO_MASK;
>> + }
>> + }
>> +
>> + return features;
> When implementing a custom ndo_features_check callback, netif_skb_features()
> will bypass the standard dflt_features_check() function. Does this mean
> vlan_features_check() is no longer called for this driver?
>
> If vlan_features_check() is skipped, multi-tagged (QinQ) VLAN packets
> might retain GSO and protocol-specific checksum offloads that the hardware
> parser cannot handle.
>
> Should this return vlan_features_check(skb, features) instead?
You’re correct about the interaction with the default feature filtering.
With a custom ndo_features_check(), the standard dflt_features_check()
path is bypassed, so vlan_features_check() must be called explicitly to
preserve existing VLAN/QinQ and checksum handling.
Thank you for catching this! I'll send v3 shortly with:
1. The vlan_features_check() call added
2. Updated commit message explaining why gso_segs check is not needed
for ibmveth
Best regards,
Mingming
>> +}
^ permalink raw reply
* Re: [PATCH net] sctp: fix sockets_allocated imbalance after sk_clone()
From: Kuniyuki Iwashima @ 2026-04-20 0:38 UTC (permalink / raw)
To: Xin Long
Cc: network dev, linux-sctp, davem, kuba, Eric Dumazet, Paolo Abeni,
Simon Horman, Marcelo Ricardo Leitner
In-Reply-To: <af8d66f928dec3e9fcbee8d4a85b7d5a6b86f515.1776460180.git.lucien.xin@gmail.com>
On Fri, Apr 17, 2026 at 2:09 PM Xin Long <lucien.xin@gmail.com> wrote:
>
> sk_clone() increments sockets_allocated and sets the socket refcount to 2.
> SCTP performs additional accounting in sctp_clone_sock(), so the clone-time
> increment must be undone to avoid double counting.
>
> Note we cannot simply remove the SCTP-side increment, because the SCTP
> destroy path in sctp_destroy_sock() only decrements sockets_allocated when
> sp->ep is set, which may not be true for all failure paths in
> sctp_clone_sock().
>
> Fixes: 16942cf4d3e3 ("sctp: Use sk_clone() in sctp_accept().")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Thanks for the fix.
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
I fixed a similar one in 622e8838a298. We may want to
perform inc/dec regardless of sp->ep and simplify the code
once net-next opens.
^ permalink raw reply
* Re: [PATCH net v5] openvswitch: cap upcall PID array size and pre-size vport replies
From: Ilya Maximets @ 2026-04-20 1:25 UTC (permalink / raw)
To: Weiming Shi, Aaron Conole, Eelco Chaudron, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: i.maximets, Simon Horman, netdev, dev, Xiang Mei
In-Reply-To: <20260416024653.153456-2-bestswngs@gmail.com>
On 4/16/26 4:46 AM, Weiming Shi wrote:
> The vport netlink reply helpers allocate a fixed-size skb with
> nlmsg_new(NLMSG_DEFAULT_SIZE, ...) but serialize the full upcall PID
> array via ovs_vport_get_upcall_portids(). Since
> ovs_vport_set_upcall_portids() accepts any non-zero multiple of
> sizeof(u32) with no upper bound, a CAP_NET_ADMIN user can install a PID
> array large enough to overflow the reply buffer, causing nla_put() to
> fail with -EMSGSIZE and hitting BUG_ON(err < 0). On systems with
> unprivileged user namespaces enabled (e.g., Ubuntu default), this is
> reachable via unshare -Urn since OVS vport mutation operations use
> GENL_UNS_ADMIN_PERM.
>
> kernel BUG at net/openvswitch/datapath.c:2414!
> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI
> CPU: 1 UID: 0 PID: 65 Comm: poc Not tainted 7.0.0-rc7-00195-geb216e422044 #1
> RIP: 0010:ovs_vport_cmd_set+0x34c/0x400
> Call Trace:
> <TASK>
> genl_family_rcv_msg_doit (net/netlink/genetlink.c:1116)
> genl_rcv_msg (net/netlink/genetlink.c:1194)
> netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> genl_rcv (net/netlink/genetlink.c:1219)
> netlink_unicast (net/netlink/af_netlink.c:1344)
> netlink_sendmsg (net/netlink/af_netlink.c:1894)
> __sys_sendto (net/socket.c:2206)
> __x64_sys_sendto (net/socket.c:2209)
> do_syscall_64 (arch/x86/entry/syscall_64.c:63)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> </TASK>
> Kernel panic - not syncing: Fatal exception
>
> Reject attempts to set more PIDs than nr_cpu_ids in
> ovs_vport_set_upcall_portids(), and pre-compute the worst-case reply
> size in ovs_vport_cmd_msg_size() based on that bound, similar to the
> existing ovs_dp_cmd_msg_size(). nr_cpu_ids matches the cap already
> used by the per-CPU dispatch configuration on the datapath side
> (ovs_dp_cmd_fill_info() serialises at most nr_cpu_ids PIDs), so the
> two sides stay consistent.
>
> Fixes: 5cd667b0a456 ("openvswitch: Allow each vport to have an array of 'port_id's.")
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
> ---
sashiko AI review is concerned about a few things:
1. Potentially higher memory usage for these messages on systems with
high core count. This is not really a problem as we have similarly
sized datapath info messages and even larger flow messages.
2. Technically a uAPI change since we're limiting the number of PIDs
that can be supplied. But, as I said before, this number should be
limited by some value regardless, it's not good to have it unbounded,
and also it is generally not a good idea to configure more handlers
than cores, as it will worsen the "thundering herd" issue the
per-vport dispatch method has. Existing userspace by default sizes
the number of threads to be lower than the number of cores.
In practice, per-vport dispatch is only used as a fallback in all modern
versions of Open vSwitch (since 2021). So, we should also, probably,
explore the ways to deprecate it and eventually remove, which would likely
require at least removing the warning for when the dp->upcall_portids
array is smaller than the cpu_id, so the users are not always required to
supply the full array, e.g. for tests, but that's a separate topic.
For this particular patch:
Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
^ permalink raw reply
* Re: [net-next v2 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
From: Minda Chen @ 2026-04-20 1:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
devicetree@vger.kernel.org
In-Reply-To: <27151bd8-6a3b-411f-94fd-7b1b932b9aa9@lunn.ch>
>
> On Fri, Apr 17, 2026 at 10:45:19AM +0800, Minda Chen wrote:
> > Remove JH8100 dt-bindings because do not support it now.
>
> > StarFive have stopped JH8100 developing and will release it outside.
>
> Is there a missing "not" in that sentence?
>
> Andrew
>
> ---
> pw-bot: cr
I will change it next version
^ 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