* 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 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
* [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
* [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 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
* 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
* 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: 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 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: 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] ipv6: Apply max_dst_opts_cnt to ip6_tnl_parse_tlv_enc_lim
From: Ido Schimmel @ 2026-04-19 14:31 UTC (permalink / raw)
To: Justin Iurman, daniel
Cc: kuba, edumazet, dsahern, tom, willemdebruijn.kernel, pabeni,
netdev
In-Reply-To: <8fdf517b-6217-4df6-8adf-0c79ce8d3be8@gmail.com>
On Sun, Apr 19, 2026 at 12:37:35AM +0200, Justin Iurman wrote:
> Nope. But if it happens, users would be confused as max_dst_opts_cnt would
> not have the same meaning in two different code paths. OTOH, I agree that
> such situation would look suspicious. I guess it's fine to keep your patch
> as is and to not over-complicate things unnecessarily.
I agree that it's weird to reuse max_dst_opts_cnt here:
1. The meaning is different from the Rx path.
2. We only enforce max_dst_opts_cnt, but not max_dst_opts_len.
3. The default is derived from the initial netns, unlike in the Rx path.
Given the above and that:
1. We believe that 8 options until the tunnel encapsulation limit option
is liberal enough.
2. We don't want to over-complicate things.
Can we go with an hard coded 8 and see if anyone complains? In the
unlikely case that someone complains we can at least gain some insight
into how this option is actually used with tunnels.
^ permalink raw reply
* Re: [PATCH net] slip: fix slab-out-of-bounds write in slhc_uncompress()
From: Simon Horman @ 2026-04-19 14:27 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: <20260415213359.335657-2-bestswngs@gmail.com>
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>
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] slip: fix slab-out-of-bounds write in slhc_uncompress()
From: Simon Horman @ 2026-04-19 14:27 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: <20260415213359.335657-2-bestswngs@gmail.com>
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.
^ permalink raw reply
* Re: [PATCH net 1/1] ipv4: icmp: validate reply type before using icmp_pointers
From: Eric Dumazet @ 2026-04-19 14:21 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, davem, dsahern, kuba, pabeni, horms, andreas.a.roeseler,
yuantan098, yifanwucs, tomapufckgml, bird, caoruide123
In-Reply-To: <efb2c33f544ece7727704608fc577525b415ae26.1776563662.git.caoruide123@gmail.com>
On Sun, Apr 19, 2026 at 3:24 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
>
> From: Ruide Cao <caoruide123@gmail.com>
>
> Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type.
> That value is outside the range covered by icmp_pointers[], which only
> describes the traditional ICMP types up to NR_ICMP_TYPES.
>
> Avoid consulting icmp_pointers[] for reply types outside that range and
> keep the existing behavior for normal ICMP replies unchanged.
>
> Fixes: d329ea5bd884 ("icmp: add response to RFC 8335 PROBE messages")
> Cc: stable@kernel.org
> Reported-by: Yuan Tan <yuantan098@gmail.com>
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Reported-by: Xin Liu <bird@lzu.edu.cn>
> Signed-off-by: Ruide Cao <caoruide123@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> ---
> net/ipv4/icmp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
> index 4e2a6c70dcd8..d8036663f035 100644
> --- a/net/ipv4/icmp.c
> +++ b/net/ipv4/icmp.c
> @@ -373,7 +373,8 @@ static int icmp_glue_bits(void *from, char *to, int offset, int len, int odd,
> to, len);
>
> skb->csum = csum_block_add(skb->csum, csum, odd);
> - if (icmp_pointers[icmp_param->data.icmph.type].error)
> + if (icmp_param->data.icmph.type <= NR_ICMP_TYPES &&
> + icmp_pointers[icmp_param->data.icmph.type].error)
> nf_ct_attach(skb, icmp_param->skb);
> return 0;
Pedantic mode: Perhaps also use array_index_nospec()
^ permalink raw reply
* Re: [PATCH 6/9] iio: mcp9600: switch to using FIELD_GET_SIGNED()
From: Jonathan Cameron @ 2026-04-19 13:21 UTC (permalink / raw)
To: Yury Norov
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, 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, Linus Walleij, Sakari Ailus, Salah Triki,
Achim Gratz, Ben Collins, linux-kernel, linux-iio, linux-wireless,
netdev, linux-rtc
In-Reply-To: <20260417173621.368914-7-ynorov@nvidia.com>
On Fri, 17 Apr 2026 13:36:17 -0400
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>
Acked-by: Jonathan Cameron <jic23@kernel.org>
^ permalink raw reply
* Re: [PATCH 5/9] iio: pressure: bmp280: switch to using FIELD_GET_SIGNED()
From: Jonathan Cameron @ 2026-04-19 13:21 UTC (permalink / raw)
To: Yury Norov
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, 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, Linus Walleij, Sakari Ailus, Salah Triki,
Achim Gratz, Ben Collins, linux-kernel, linux-iio, linux-wireless,
netdev, linux-rtc
In-Reply-To: <20260417173621.368914-6-ynorov@nvidia.com>
On Fri, 17 Apr 2026 13:36:16 -0400
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>
Acked-by: Jonathan Cameron <jic23@kernel.org>
^ permalink raw reply
* Re: [PATCH 4/9] iio: magnetometer: yas530: switch to using FIELD_GET_SIGNED()
From: Jonathan Cameron @ 2026-04-19 13:20 UTC (permalink / raw)
To: Yury Norov
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, 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, Linus Walleij, 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, 17 Apr 2026 13:36:15 -0400
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>
Acked-by: Jonathan Cameron <jic23@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/9] iio: intel_dc_ti_adc: switch to using FIELD_GET_SIGNED()
From: Jonathan Cameron @ 2026-04-19 13:18 UTC (permalink / raw)
To: Yury Norov
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andy Lutomirski, Peter Zijlstra, 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, Linus Walleij, Sakari Ailus, Salah Triki,
Achim Gratz, Ben Collins, linux-kernel, linux-iio, linux-wireless,
netdev, linux-rtc
In-Reply-To: <20260417173621.368914-4-ynorov@nvidia.com>
On Fri, 17 Apr 2026 13:36:14 -0400
Yury Norov <ynorov@nvidia.com> wrote:
> Switch from sign_extend32(FIELD_GET()) to the dedicated
> FIELD_GET_SIGNED() and don't provide the fields length explicitly.
>
> Signed-off-by: Yury Norov <ynorov@nvidia.com>
Assuming any remaining discussion on the implementation of the macro
shakes out, this looks like a good little cleanup to me.
Not sure how you want to merge this but if it's going through another tree.
Acked-by: Jonathan Cameron <jic23@kernel.org>
> ---
> drivers/iio/adc/intel_dc_ti_adc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/adc/intel_dc_ti_adc.c b/drivers/iio/adc/intel_dc_ti_adc.c
> index 0fe34f1c338e..b5afad713e2d 100644
> --- a/drivers/iio/adc/intel_dc_ti_adc.c
> +++ b/drivers/iio/adc/intel_dc_ti_adc.c
> @@ -290,8 +290,8 @@ static int dc_ti_adc_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - info->vbat_zse = sign_extend32(FIELD_GET(DC_TI_VBAT_ZSE, val), 3);
> - info->vbat_ge = sign_extend32(FIELD_GET(DC_TI_VBAT_GE, val), 3);
> + info->vbat_zse = FIELD_GET_SIGNED(DC_TI_VBAT_ZSE, val);
> + info->vbat_ge = FIELD_GET_SIGNED(DC_TI_VBAT_GE, val);
>
> dev_dbg(dev, "vbat-zse %d vbat-ge %d\n", info->vbat_zse, info->vbat_ge);
>
^ permalink raw reply
* Re: [PATCH v2 00/19] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Vineeth Remanan Pillai @ 2026-04-19 13:14 UTC (permalink / raw)
To: Steven Rostedt
Cc: Peter Zijlstra, Dmitry Ilvokhin, Masami Hiramatsu,
Mathieu Desnoyers, Ingo Molnar, Jens Axboe, io-uring,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Marcelo Ricardo Leitner,
Xin Long, Jon Maloy, Aaron Conole, Eelco Chaudron, Ilya Maximets,
netdev, bpf, linux-sctp, tipc-discussion, dev, Jiri Pirko,
Oded Gabbay, Koby Elbaz, dri-devel, Rafael J. Wysocki,
Viresh Kumar, Gautham R. Shenoy, Huang Rui, Mario Limonciello,
Len Brown, Srinivas Pandruvada, linux-pm, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, Christian König, Sumit Semwal,
linaro-mm-sig, Eddie James, Andrew Jeffery, Joel Stanley,
linux-fsi, David Airlie, Simona Vetter, Alex Deucher,
Danilo Krummrich, Matthew Brost, Philipp Stanner, Harry Wentland,
Leo Li, amd-gfx, Jiri Kosina, Benjamin Tissoires, linux-input,
Wolfram Sang, linux-i2c, Mark Brown, Michael Hennerich,
Nuno Sá, linux-spi, James E.J. Bottomley, Martin K. Petersen,
linux-scsi, Chris Mason, David Sterba, linux-btrfs,
Thomas Gleixner, Andrew Morton, SeongJae Park, linux-mm,
Borislav Petkov, Dave Hansen, x86, linux-trace-kernel,
linux-kernel
In-Reply-To: <20260418190456.631df6f3@fedora>
On Sat, Apr 18, 2026 at 7:05 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 23 Mar 2026 12:00:19 -0400
> "Vineeth Pillai (Google)" <vineeth@bitbyteword.org> wrote:
>
> > if (trace_foo_enabled() && cond)
> > trace_call__foo(args); /* calls __do_trace_foo() directly */
>
> Hi Vineeth,
>
> Could you rebase this series on top of 7.1-rc1 when it comes out?
> Several of these patches were accepted already. Obviously drop those.
> They were the patches that added the feature, and any where the
> maintainer acked the patch.
>
> Now that the feature has been accepted, if you post the patch series
> again after 7.1-rc1 with all the patches that haven't been accepted
> yet, then the maintainers can simply take them directly. As the feature
> is now accepted, there's no dependency on it, and they don't need to go
> through the tracing tree.
>
Sure, will do. Thanks for merging this feature.
Thanks,
Vineeth
^ permalink raw reply
* Re: [PATCH net v2] net: iptunnel: fix stale transport header after GRE/TEB decap
From: Jiayuan Chen @ 2026-04-19 13:01 UTC (permalink / raw)
To: Eric Dumazet, Jiayuan Chen
Cc: netdev, syzbot+83181a31faf9455499c5, David S. Miller, David Ahern,
Jakub Kicinski, Paolo Abeni, Simon Horman, Pravin B Shelar,
Tom Herbert, linux-kernel
In-Reply-To: <CANn89iKJFCw9gPdQN4hYZ94j-0Ua84N+DyYjPjwBTRLveK-j7g@mail.gmail.com>
[...]
>> +662,18 @@ static inline int iptunnel_pull_offloads(struct sk_buff *skb)
>> return 0;
>> }
>>
>> +static inline void iptunnel_rebuild_transport_header(struct sk_buff *skb)
>> +{
>> + if (!skb_is_gso(skb))
>> + return;
>> +
>> + skb->transport_header = (typeof(skb->transport_header))~0U;
>> + skb_probe_transport_header(skb);
>> +
>> + if (!skb_transport_header_was_set(skb))
>> + skb_gso_reset(skb);
> I do not think this makes sense.
> What is a valid case for this packet being processed further?
> The buggy packet must be dropped, instead of being mangled like this.
Hi Eric,
The reproducer builds a gre frame whose inner Ethernet header is
all-zero. Tracing the skb through RX:
1. At GRE decap exit, skb_transport_offset(skb) < 0 is the rule, not the
exception.
It is negative for every packet leaving the tunnel, including perfectly
well-formed inner IPv4 traffic
because the tunnel leaves skb->transport_header at the outer L4 offset while
pskb_pull() has already advanced skb->data past it.
skb_transport_header_was_set() stays true, so downstream
code that trusts that flag now trusts a stale, negative offset.
2. GRO repairs it — but only for protocols it knows.
In dev_gro_receive(), skb->protocol is dispatched through the offload
table. For ETH_P_IP,
inet_gro_receive() calls skb_set_transport_header(skb,
skb_gro_offset(skb)), and the offset
becomes valid again. But for malformed skb, dev_gro_receive just bypass it.
3. Both kinds then reach __netif_receive_skb_core().
So the skb that qdisc/tc/BPF segmenters later see has an
invariant violation — _was_set == true but offset < 0 — that the core
layer has no intention of catching for us.
My reading of this is that the tunnel decap path is producing an skb
that doesn't
honor the contract __netif_receive_skb_core() expects from its
producers, and that
it doesn't really make sense to ask GRE to parse or validate the inner
L4 in order
to fix this.
I'm thinking at the end of GRE decap, before handing the skb to
gro_cells_receive(),
call skb_reset_transport_header(skb).
Thanks,
Jiayuan
^ permalink raw reply
* [PATCH net v2] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Daniel Golle @ 2026-04-19 10:43 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Russell King,
Christian Marangi, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
Cc: Frank Wunderlich, Christian Marangi (Ansuel), John Crispin
The .get_stats64 callback runs in atomic context, but on
MDIO-connected switches every register read acquires the MDIO bus
mutex, which can sleep:
[ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
[ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
[ 12.663377] preempt_count: 0, expected: 0
[ 12.667410] RCU nest depth: 1, expected: 0
[ 12.671511] INFO: lockdep is turned off.
[ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
[ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
[ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
[ 12.675459] Call trace:
[ 12.675462] show_stack+0x14/0x1c (C)
[ 12.675477] dump_stack_lvl+0x68/0x8c
[ 12.675487] dump_stack+0x14/0x1c
[ 12.675495] __might_resched+0x14c/0x220
[ 12.675504] __might_sleep+0x44/0x80
[ 12.675511] __mutex_lock+0x50/0xb10
[ 12.675523] mutex_lock_nested+0x20/0x30
[ 12.675532] mt7530_get_stats64+0x40/0x2ac
[ 12.675542] dsa_user_get_stats64+0x2c/0x40
[ 12.675553] dev_get_stats+0x44/0x1e0
[ 12.675564] dev_seq_printf_stats+0x24/0xe0
[ 12.675575] dev_seq_show+0x14/0x3c
[ 12.675583] seq_read_iter+0x37c/0x480
[ 12.675595] seq_read+0xd0/0xec
[ 12.675605] proc_reg_read+0x94/0xe4
[ 12.675615] vfs_read+0x98/0x29c
[ 12.675625] ksys_read+0x54/0xdc
[ 12.675633] __arm64_sys_read+0x18/0x20
[ 12.675642] invoke_syscall.constprop.0+0x54/0xec
[ 12.675653] do_el0_svc+0x3c/0xb4
[ 12.675662] el0_svc+0x38/0x200
[ 12.675670] el0t_64_sync_handler+0x98/0xdc
[ 12.675679] el0t_64_sync+0x158/0x15c
For MDIO-connected switches, poll MIB counters asynchronously using a
delayed workqueue every second and let .get_stats64 return the cached
values under a spinlock. A mod_delayed_work() call on each read
triggers an immediate refresh so counters stay responsive when queried
more frequently.
MMIO-connected switches (MT7988, EN7581, AN7583) are not affected
because their regmap does not sleep, so they continue to read MIB
counters directly in .get_stats64.
Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
v2:
* use spin_lock_bh()/spin_unlock_bh() to prevent potential deadlock
* rate-limit mod_delayed_work() refresh to at most once per 100ms
* move cancel_delayed_work_sync() after dsa_unregister_switch()
* add mt753x_teardown() callback to cancel the stats work
* fix commit message
drivers/net/dsa/mt7530.c | 66 ++++++++++++++++++++++++++++++++++++++--
drivers/net/dsa/mt7530.h | 8 +++++
2 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index b9423389c2ef0..8c1186ba2279b 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -25,6 +25,9 @@
#include "mt7530.h"
+#define MT7530_STATS_POLL_INTERVAL (1 * HZ)
+#define MT7530_STATS_RATE_LIMIT (HZ / 10)
+
static struct mt753x_pcs *pcs_to_mt753x_pcs(struct phylink_pcs *pcs)
{
return container_of(pcs, struct mt753x_pcs, pcs);
@@ -906,10 +909,9 @@ static void mt7530_get_rmon_stats(struct dsa_switch *ds, int port,
*ranges = mt7530_rmon_ranges;
}
-static void mt7530_get_stats64(struct dsa_switch *ds, int port,
- struct rtnl_link_stats64 *storage)
+static void mt7530_read_port_stats64(struct mt7530_priv *priv, int port,
+ struct rtnl_link_stats64 *storage)
{
- struct mt7530_priv *priv = ds->priv;
uint64_t data;
/* MIB counter doesn't provide a FramesTransmittedOK but instead
@@ -951,6 +953,45 @@ static void mt7530_get_stats64(struct dsa_switch *ds, int port,
&storage->rx_crc_errors);
}
+static void mt7530_stats_poll(struct work_struct *work)
+{
+ struct mt7530_priv *priv = container_of(work, struct mt7530_priv,
+ stats_work.work);
+ struct rtnl_link_stats64 stats = {};
+ struct dsa_port *dp;
+ int port;
+
+ dsa_switch_for_each_user_port(dp, priv->ds) {
+ port = dp->index;
+
+ mt7530_read_port_stats64(priv, port, &stats);
+
+ spin_lock_bh(&priv->stats_lock);
+ priv->ports[port].stats = stats;
+ spin_unlock_bh(&priv->stats_lock);
+ }
+
+ priv->stats_last = jiffies;
+ schedule_delayed_work(&priv->stats_work,
+ MT7530_STATS_POLL_INTERVAL);
+}
+
+static void mt7530_get_stats64(struct dsa_switch *ds, int port,
+ struct rtnl_link_stats64 *storage)
+{
+ struct mt7530_priv *priv = ds->priv;
+
+ if (priv->bus) {
+ spin_lock_bh(&priv->stats_lock);
+ *storage = priv->ports[port].stats;
+ spin_unlock_bh(&priv->stats_lock);
+ if (time_after(jiffies, priv->stats_last + MT7530_STATS_RATE_LIMIT))
+ mod_delayed_work(system_wq, &priv->stats_work, 0);
+ } else {
+ mt7530_read_port_stats64(priv, port, storage);
+ }
+}
+
static void mt7530_get_eth_ctrl_stats(struct dsa_switch *ds, int port,
struct ethtool_eth_ctrl_stats *ctrl_stats)
{
@@ -3137,9 +3178,24 @@ mt753x_setup(struct dsa_switch *ds)
if (ret && priv->irq_domain)
mt7530_free_mdio_irq(priv);
+ if (!ret && priv->bus) {
+ spin_lock_init(&priv->stats_lock);
+ INIT_DELAYED_WORK(&priv->stats_work, mt7530_stats_poll);
+ schedule_delayed_work(&priv->stats_work,
+ MT7530_STATS_POLL_INTERVAL);
+ }
+
return ret;
}
+static void mt753x_teardown(struct dsa_switch *ds)
+{
+ struct mt7530_priv *priv = ds->priv;
+
+ if (priv->bus)
+ cancel_delayed_work_sync(&priv->stats_work);
+}
+
static int mt753x_set_mac_eee(struct dsa_switch *ds, int port,
struct ethtool_keee *e)
{
@@ -3257,6 +3313,7 @@ static int mt7988_setup(struct dsa_switch *ds)
static const struct dsa_switch_ops mt7530_switch_ops = {
.get_tag_protocol = mtk_get_tag_protocol,
.setup = mt753x_setup,
+ .teardown = mt753x_teardown,
.preferred_default_local_cpu_port = mt753x_preferred_default_local_cpu_port,
.get_strings = mt7530_get_strings,
.get_ethtool_stats = mt7530_get_ethtool_stats,
@@ -3409,6 +3466,9 @@ mt7530_remove_common(struct mt7530_priv *priv)
dsa_unregister_switch(priv->ds);
+ if (priv->bus)
+ cancel_delayed_work_sync(&priv->stats_work);
+
mutex_destroy(&priv->reg_mutex);
}
EXPORT_SYMBOL_GPL(mt7530_remove_common);
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 3e0090bed298d..dd33b0df3419e 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -796,6 +796,7 @@ struct mt7530_fdb {
* @pvid: The VLAN specified is to be considered a PVID at ingress. Any
* untagged frames will be assigned to the related VLAN.
* @sgmii_pcs: Pointer to PCS instance for SerDes ports
+ * @stats: Cached port statistics for MDIO-connected switches
*/
struct mt7530_port {
bool enable;
@@ -803,6 +804,7 @@ struct mt7530_port {
u32 pm;
u16 pvid;
struct phylink_pcs *sgmii_pcs;
+ struct rtnl_link_stats64 stats;
};
/* Port 5 mode definitions of the MT7530 switch */
@@ -875,6 +877,9 @@ struct mt753x_info {
* @create_sgmii: Pointer to function creating SGMII PCS instance(s)
* @active_cpu_ports: Holding the active CPU ports
* @mdiodev: The pointer to the MDIO device structure
+ * @stats_lock: Protects cached per-port stats from concurrent access
+ * @stats_work: Delayed work for polling MIB counters on MDIO switches
+ * @stats_last: Jiffies timestamp of last MIB counter poll
*/
struct mt7530_priv {
struct device *dev;
@@ -900,6 +905,9 @@ struct mt7530_priv {
int (*create_sgmii)(struct mt7530_priv *priv);
u8 active_cpu_ports;
struct mdio_device *mdiodev;
+ spinlock_t stats_lock; /* protects cached stats counters */
+ struct delayed_work stats_work;
+ unsigned long stats_last;
};
struct mt7530_hw_vlan_entry {
--
2.53.0
^ permalink raw reply related
* [PATCH] net: dsa: realtek: rtl8365mb: fix mode mask calculation
From: Mieczyslaw Nalewaj @ 2026-04-19 9:59 UTC (permalink / raw)
To: netdev
In-Reply-To: <c1519cfa-5a66-48b6-a578-e0ac03a57484.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.
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)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH nf] netfilter: xt_TCPMSS: check skb_dst before path-MTU clamping
From: Pablo Neira Ayuso @ 2026-04-19 10:25 UTC (permalink / raw)
To: Florian Westphal
Cc: Weiming Shi, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Phil Sutter, Simon Horman, netfilter-devel, coreteam,
netdev, Xiang Mei
In-Reply-To: <aePiSwmP6YEQ4mNE@strlen.de>
On Sat, Apr 18, 2026 at 09:58:03PM +0200, Florian Westphal wrote:
> Weiming Shi <bestswngs@gmail.com> wrote:
> > When TCPMSS with CLAMP_PMTU is used via nft_compat in a non-base
> > chain, par->hook_mask is set to 0, bypassing the checkentry hook
> > validation. The target can then run at PRE_ROUTING where skb_dst is
> > NULL, causing a null-ptr-deref in tcpmss_mangle_packet():
> >
> > KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> > RIP: 0010:tcpmss_mangle_packet (include/net/dst.h:219 net/netfilter/xt_TCPMSS.c:105)
> > tcpmss_tg4 (net/netfilter/xt_TCPMSS.c:202)
> > nft_target_eval_xt (net/netfilter/nft_compat.c:87)
> > nft_do_chain (net/netfilter/nf_tables_core.c:287)
> > nf_hook_slow (net/netfilter/core.c:623)
> >
> > Check skb_dst() for NULL before calling dst_mtu().
>
> FWIW I will apply this patch even though its wrong.
And no please, do not apply this.
This needs to be fixes from the chain graph detection.
^ permalink raw reply
* Re: [PATCH nf] netfilter: xt_TCPMSS: check skb_dst before path-MTU clamping
From: Pablo Neira Ayuso @ 2026-04-19 10:24 UTC (permalink / raw)
To: Florian Westphal
Cc: Weiming Shi, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Phil Sutter, Simon Horman, netfilter-devel, coreteam,
netdev, Xiang Mei
In-Reply-To: <aePiSwmP6YEQ4mNE@strlen.de>
On Sat, Apr 18, 2026 at 09:58:03PM +0200, Florian Westphal wrote:
> Weiming Shi <bestswngs@gmail.com> wrote:
> > When TCPMSS with CLAMP_PMTU is used via nft_compat in a non-base
> > chain, par->hook_mask is set to 0, bypassing the checkentry hook
> > validation. The target can then run at PRE_ROUTING where skb_dst is
> > NULL, causing a null-ptr-deref in tcpmss_mangle_packet():
> >
> > KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
> > RIP: 0010:tcpmss_mangle_packet (include/net/dst.h:219 net/netfilter/xt_TCPMSS.c:105)
> > tcpmss_tg4 (net/netfilter/xt_TCPMSS.c:202)
> > nft_target_eval_xt (net/netfilter/nft_compat.c:87)
> > nft_do_chain (net/netfilter/nf_tables_core.c:287)
> > nf_hook_slow (net/netfilter/core.c:623)
> >
> > Check skb_dst() for NULL before calling dst_mtu().
>
> FWIW I will apply this patch even though its wrong.
>
> nft_compat.c is just too broken, I don't see how it can be
> fixed in any reasonable amount of time.
>
> validation is done too early, at expression instantiation
> time.
>
> This doesn't work because we have incomplete graph, it has
> to be done at final table validation time.
I remember this used to work, maybe it broke with recent updates on
the chain graph detection?
Once the non-basechain is added it should consider the basechain where
this can be reached.
> But then all required compat info (xtables hints) is gone
> and no longer available.
What?
> AFAICS the only way to resolve this is to cache the info in
> the nft_expr priv area (WHERE IS ABSOLUTELY DOESN'T BELONG!)
> because thats the only storage thewre is.
No.
^ permalink raw reply
* [PATCH net 1/1] ipv4: icmp: validate reply type before using icmp_pointers
From: Ren Wei @ 2026-04-19 10:19 UTC (permalink / raw)
To: netdev
Cc: davem, dsahern, edumazet, kuba, pabeni, horms, andreas.a.roeseler,
yuantan098, yifanwucs, tomapufckgml, bird, caoruide123, n05ec
In-Reply-To: <cover.1776563662.git.caoruide123@gmail.com>
From: Ruide Cao <caoruide123@gmail.com>
Extended echo replies use ICMP_EXT_ECHOREPLY as the outbound reply type.
That value is outside the range covered by icmp_pointers[], which only
describes the traditional ICMP types up to NR_ICMP_TYPES.
Avoid consulting icmp_pointers[] for reply types outside that range and
keep the existing behavior for normal ICMP replies unchanged.
Fixes: d329ea5bd884 ("icmp: add response to RFC 8335 PROBE messages")
Cc: stable@kernel.org
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Ruide Cao <caoruide123@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
net/ipv4/icmp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 4e2a6c70dcd8..d8036663f035 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -373,7 +373,8 @@ static int icmp_glue_bits(void *from, char *to, int offset, int len, int odd,
to, len);
skb->csum = csum_block_add(skb->csum, csum, odd);
- if (icmp_pointers[icmp_param->data.icmph.type].error)
+ if (icmp_param->data.icmph.type <= NR_ICMP_TYPES &&
+ icmp_pointers[icmp_param->data.icmph.type].error)
nf_ct_attach(skb, icmp_param->skb);
return 0;
}
--
2.34.1
^ permalink raw reply related
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