* Re: [PATCH net] tipc: free bearer discoverer via RCU to fix tipc_disc_rcv UAF
From: Tung Quang Nguyen @ 2026-06-16 11:34 UTC (permalink / raw)
To: Sam P
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org, stable@vger.kernel.org, Jon Maloy,
bestswngs@gmail.com
In-Reply-To: <fa2e0cfb-9d60-4295-8a46-f69ce1229094@bynar.io>
Subject: Re: [PATCH net] tipc: free bearer discoverer via RCU to fix tipc_disc_rcv UAF
> Oops, I missed that patch! I'm not sure what the etiquette
> is in this case, but I'm happy to defer to the original
> submitter (CCd) if they're working on a new patch and/or
> add any appropriate trailers to my v2.
> I've prepared a v2 to submit after the ~24h period,
> addressing your changes and taking into account Eric's
> feedback from the earlier submission as well
> (adding an rcu_barrier() in tipc_exit()).
Eric's concern is correct but it needs to be addressed in a separate patch because it is a pre-existing issue. It requires another reproduction (load/unload TIPC kernel module) and other considerations (calling call_rcu() from timer etc.).
For now, I think you just need to address my comment.
^ permalink raw reply
* [PATCH net-next v3] virtio-net: xsk: support tx wake up
From: Menglong Dong @ 2026-06-16 11:59 UTC (permalink / raw)
To: xuanzhuo, eperezma
Cc: mst, jasowang, andrew+netdev, davem, edumazet, kuba, pabeni,
netdev, virtualization, linux-kernel
For now, XDP_RING_NEED_WAKEUP is not supported properly by the virtio-net
in the tx path for example: we set xsk_set_tx_need_wakeup() in
virtnet_xsk_xmit(), but we didn't call xsk_clear_tx_need_wakeup()
anywhere, which means the user will call send() for every packet.
We call xsk_set_tx_need_wakeup() after virtnet_xsk_xmit_batch() if sq->vq
is empty, as we can't be wakeup by the skb_xmit_done() in this case.
Otherwise, we will clear the wakeup flag.
Race condition is considered for tx path.
Fixes: 89f86675cb03 ("virtio_net: xsk: tx: support xmit xsk buffer")
Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn>
---
v3:
- remove the confusing comment
v2:
- add the Fixes tag
---
drivers/net/virtio_net.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index f4adcfee7a80..6e099edef6e9 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1440,8 +1440,9 @@ static bool virtnet_xsk_xmit(struct send_queue *sq, struct xsk_buff_pool *pool,
struct virtnet_info *vi = sq->vq->vdev->priv;
struct virtnet_sq_free_stats stats = {};
struct net_device *dev = vi->dev;
+ int sent, vring_size;
+ bool need_wakeup;
u64 kicks = 0;
- int sent;
/* Avoid to wakeup napi meanless, so call __free_old_xmit instead of
* free_old_xmit().
@@ -1451,8 +1452,25 @@ static bool virtnet_xsk_xmit(struct send_queue *sq, struct xsk_buff_pool *pool,
if (stats.xsk)
xsk_tx_completed(sq->xsk_pool, stats.xsk);
+ vring_size = virtqueue_get_vring_size(sq->vq);
+ need_wakeup = xsk_uses_need_wakeup(pool);
+
+ if (need_wakeup && vring_size == sq->vq->num_free)
+ xsk_set_tx_need_wakeup(pool);
+
sent = virtnet_xsk_xmit_batch(sq, pool, budget, &kicks);
+ if (need_wakeup) {
+ if (vring_size == sq->vq->num_free)
+ /* we can't wake up by ourself, and it should be done
+ * by the user.
+ */
+ xsk_set_tx_need_wakeup(pool);
+ else
+ /* we can wake up from skb_xmit_done() */
+ xsk_clear_tx_need_wakeup(pool);
+ }
+
if (!is_xdp_raw_buffer_queue(vi, sq - vi->sq))
check_sq_full_and_disable(vi, vi->dev, sq);
@@ -1470,9 +1488,6 @@ static bool virtnet_xsk_xmit(struct send_queue *sq, struct xsk_buff_pool *pool,
u64_stats_add(&sq->stats.xdp_tx, sent);
u64_stats_update_end(&sq->stats.syncp);
- if (xsk_uses_need_wakeup(pool))
- xsk_set_tx_need_wakeup(pool);
-
return sent;
}
--
2.54.0
^ permalink raw reply related
* [PATCH v2] [net] net: airoha: fix foe_check_time allocation size
From: Wayen Yan @ 2026-06-16 11:52 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
foe_check_time is declared as u16 pointer but was allocated with
only ppe_num_entries bytes instead of ppe_num_entries * sizeof(u16).
When airoha_ppe_foe_verify_entry() is called with hash >= ppe_num_entries/2,
it writes beyond the allocated buffer, causing heap buffer overflow and
potential kernel crash.
Fixes: 6d5b601d52a2 ("net: airoha: ppe: Dynamically allocate foe_check_time array in airoha_ppe struct")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_ppe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index 5c9dff6bcc..8fb8ecf909 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -1578,7 +1578,8 @@ int airoha_ppe_init(struct airoha_eth *eth)
return -ENOMEM;
}
- ppe->foe_check_time = devm_kzalloc(eth->dev, ppe_num_entries,
+ ppe->foe_check_time = devm_kzalloc(eth->dev,
+ ppe_num_entries * sizeof(*ppe->foe_check_time),
GFP_KERNEL);
if (!ppe->foe_check_time)
return -ENOMEM;
--
2.51.0
^ permalink raw reply related
* [PATCH v2] [net] net: airoha: Fix QoS counter configuration for Tx-fwd channels
From: Wayen Yan @ 2026-06-16 10:50 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_qdma_init_qos_stats(), the Tx-fwd counter was incorrectly
using register index (i << 1) instead of ((i << 1) + 1). This caused
the Tx-fwd configuration to overwrite the Tx-cpu configuration for
each QoS channel, resulting in incorrect QoS statistics.
Fix by using the correct register index ((i << 1) + 1) for Tx-fwd
counter configuration.
Fixes: 20bf7d07c956 ("net: airoha: Add sched ETS offload support")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 31cdb11cd7..329988a840 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1256,7 +1256,7 @@ static void airoha_qdma_init_qos_stats(struct airoha_qdma *qdma)
FIELD_PREP(CNTR_CHAN_MASK, i));
/* Tx-fwd transferred count */
airoha_qdma_wr(qdma, REG_CNTR_VAL((i << 1) + 1), 0);
- airoha_qdma_wr(qdma, REG_CNTR_CFG(i << 1),
+ airoha_qdma_wr(qdma, REG_CNTR_CFG((i << 1) + 1),
CNTR_EN_MASK | CNTR_ALL_QUEUE_EN_MASK |
CNTR_ALL_DSCP_RING_EN_MASK |
FIELD_PREP(CNTR_SRC_MASK, 1) |
--
2.51.0
^ permalink raw reply related
* [PATCH v2] [net] net: airoha: Stop TX queues on error path in airoha_dev_open
From: Wayen Yan @ 2026-06-16 10:50 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_dev_open(), if airoha_set_vip_for_gdm_port() fails after
netif_tx_start_all_queues() has been called, the TX queues remain
started while the device configuration is incomplete. This leaves
the device in an inconsistent state where packets could be
transmitted before the VIP/IFC port configuration is complete.
Add netif_tx_stop_all_queues() call on the error path to properly
roll back the TX queue state.
Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 31cdb11cd7..cf9c366907 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1715,8 +1715,10 @@ static int airoha_dev_open(struct net_device *dev)
netif_tx_start_all_queues(dev);
err = airoha_set_vip_for_gdm_port(port, true);
- if (err)
+ if (err) {
+ netif_tx_stop_all_queues(dev);
return err;
+ }
if (netdev_uses_dsa(dev))
airoha_fe_set(qdma->eth, REG_GDM_INGRESS_CFG(port->id),
--
2.51.0
^ permalink raw reply related
* [PATCH v2] [net] net: airoha: Clean up RX queues in airoha_dev_stop
From: Wayen Yan @ 2026-06-16 10:50 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
When the last port is stopped, airoha_dev_stop() clears TX queues
but neglects to clean up RX queues. This can lead to:
- RX ring buffer descriptors remaining valid after device close
- Potential DMA synchronization issues on device reopen
- Risk of use-after-free if pages are freed while DMA is still active
Add cleanup loop for RX queues to mirror the TX queue cleanup,
ensuring symmetric resource management.
Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 31cdb11cd7..9ca5bbf64d 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1771,6 +1771,13 @@ static int airoha_dev_stop(struct net_device *dev)
airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
}
+
+ for (i = 0; i < ARRAY_SIZE(qdma->q_rx); i++) {
+ if (!qdma->q_rx[i].ndesc)
+ continue;
+
+ airoha_qdma_cleanup_rx_queue(&qdma->q_rx[i]);
+ }
}
return 0;
--
2.51.0
^ permalink raw reply related
* RE: Ethtool : PRBS feature
From: Das, Shubham @ 2026-06-16 12:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev@vger.kernel.org, mkubecek@suse.cz, D H, Siddaraju,
Chintalapalle, Balaji
In-Reply-To: <f4a3e4ad-91e2-4844-a29b-81f70151228e@lunn.ch>
Hi Andrew,
Thanks for the feedback.
Yes, for multi-lane ports we can accept the lane number as an argument like:
ethtool --phy-test eth1 lane 0 tx-prbs prbs7
ethtool --phy-test eth2 lane 0 rx-prbs prbs7
We referred to "Lee Trager's" "Open-Source Tooling for PHY Management and Testing" session:
https://netdevconf.info/0x19/sessions/talk/open-source-tooling-for-phy-management-and-testing.html?.
We have been trying to reach "Lee Trager" to seek more input, latest update on the approach and understand if there is a parallel effort in active so we can collaborate.
If you can, please help me connect with "Lee Trager" and others who expressed interest in Ethernet PRBS. We are happy to align and start implementation.
About standardizing across other bus like PCIe and USB, I had a quick discussion with our internal designers, but I didn't observe any such SW-level config knobs interest.
Looks like Ethernet has clear interest and we are joining that Ethernet PRBS community too.
Ethernet PRBS configuration and diagnostics support is well established and already widely used in existing Ethernet SERDES deployments.
We think Ethernet is the most natural starting point within netdev, as it aligns with current driver practice and existing validation workflows.
Thanks,
Shubham D
> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: 11 June 2026 21:14
> To: Das, Shubham <shubham.das@intel.com>
> Cc: netdev@vger.kernel.org; mkubecek@suse.cz; D H, Siddaraju
> <siddaraju.dh@intel.com>; Chintalapalle, Balaji <balaji.chintalapalle@intel.com>
> Subject: Re: Ethtool : PRBS feature
>
> > 2. Whether similar work has been proposed previously.
>
> There was a presentation at netdev conf last year about this topic,
> and how you use it to configure SERDES eyes. And then a long
> discussion on the netdev mailing afterwards. You should read the
> discussion, and incorporate the ideas. There was a couple of points
> raised:
>
> SERDES are also used for PCIe, USB, SATA, and they have similar
> capabilities to a SERDES used for networking. Do we want a networking
> specific solution, or something more generic?
>
> You need to include lane information, since there can be 1, 2 or 4
> lanes involved, and you need to specify which lane you want to test.
>
> Andrew
^ permalink raw reply
* RE: [PATCH v2 net-next 1/1] tcp: Replace min_tso_segs() with tso_segs() CC callback for TCP Prague
From: Chia-Yu Chang (Nokia) @ 2026-06-16 12:23 UTC (permalink / raw)
To: Jakub Kicinski, edumazet@google.com, ncardwell@google.com
Cc: jolsa@kernel.org, yonghong.song@linux.dev, song@kernel.org,
linux-kselftest@vger.kernel.org, memxor@gmail.com,
shuah@kernel.org, martin.lau@linux.dev, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, eddyz87@gmail.com,
horms@kernel.org, dsahern@kernel.org, bpf@vger.kernel.org,
netdev@vger.kernel.org, pabeni@redhat.com, jhs@mojatatu.com,
stephen@networkplumber.org, davem@davemloft.net,
andrew+netdev@lunn.ch, donald.hunter@gmail.com, kuniyu@google.com,
ij@kernel.org, Koen De Schepper (Nokia), g.white@cablelabs.com,
ingemar.s.johansson@ericsson.com, mirja.kuehlewind@ericsson.com,
cheshire@apple.com, rs.ietf@gmx.at, Jason_Livingood@comcast.com,
vidhi_goel@apple.com
In-Reply-To: <20260615191704.31be22da@kernel.org>
git send-email --to='jolsa@kernel.org' --to='yonghong.song@linux.dev' --to='song@kernel.org' --to='linux-kselftest@vger.kernel.org' --to='memxor@gmail.com' --to='shuah@kernel.org' --to='martin.lau@linux.dev' --to='ast@kernel.org' --to='daniel@iogearbox.net' --to='andrii@kernel.org' --to='eddyz87@gmail.com' --to='horms@kernel.org' --to='dsahern@kernel.org' --to='bpf@vger.kernel.org' --to='netdev@vger.kernel.org' --to='pabeni@redhat.com' --to='jhs@mojatatu.com' --to='kuba@kernel.org' --to='stephen@networkplumber.org' --to='davem@davemloft.net' --to='edumazet@google.com' --to='andrew+netdev@lunn.ch' --to='donald.hunter@gmail.com' --to='kuniyu@google.com' --to='ij@kernel.org' --to='ncardwell@google.com' --to='koen.de_schepper@nokia-bell-labs.com' --to='g.white@cablelabs.com' --to='ingemar.s.johansson@ericsson.com' --to='mirja.kuehlewind@ericsson.com' --to='cheshire@apple.com' --to='rs.ietf@gmx.at' --to='Jason_Livingood@comcast.com' --to='vidhi_goel@apple.com' ~/L4S_patches_20260613/linux_net_next_prague_series0/*.patch --from='chia-yu.chang@nokia-bell-labs.com' --smtp-server='mailrelay.int.nokia.com' --smtp-server-port=25
> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Tuesday, June 16, 2026 4:17 AM
> To: edumazet@google.com; ncardwell@google.com
> Cc: Chia-Yu Chang (Nokia) <chia-yu.chang@nokia-bell-labs.com>; jolsa@kernel.org; yonghong.song@linux.dev; song@kernel.org; linux-kselftest@vger.kernel.org; memxor@gmail.com; shuah@kernel.org; martin.lau@linux.dev; ast@kernel.org; daniel@iogearbox.net; andrii@kernel.org; eddyz87@gmail.com; horms@kernel.org; dsahern@kernel.org; bpf@vger.kernel.org; netdev@vger.kernel.org; pabeni@redhat.com; jhs@mojatatu.com; stephen@networkplumber.org; davem@davemloft.net; andrew+netdev@lunn.ch; donald.hunter@gmail.com; kuniyu@google.com; ij@kernel.org; Koen De Schepper (Nokia) <koen.de_schepper@nokia-bell-labs.com>; g.white@cablelabs.com; ingemar.s.johansson@ericsson.com; mirja.kuehlewind@ericsson.com; cheshire@apple.com; rs.ietf@gmx.at; Jason_Livingood@comcast.com; vidhi_goel@apple.com
> Subject: Re: [PATCH v2 net-next 1/1] tcp: Replace min_tso_segs() with tso_segs() CC callback for TCP Prague
>
>
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>
>
>
> On Mon, 15 Jun 2026 18:51:02 -0700 Jakub Kicinski wrote:
> > On Sun, 14 Jun 2026 09:17:56 +0200 chia-yu.chang@nokia-bell-labs.com
> > wrote:
> > > This patch replaces existing min_tso_segs() with tso_segs() CC
> > > callbak for CC algorithm to provides explicit tso segment number of
> > > each data burst and overrides tcp_tso_autosize().
> > >
> > > No functional change.
> >
> > Eric, Neal, looks good?
> >
> > The min rtt thing in tcp_tso_autosize() helps a bit but if the sender
> > gets congested for a longer stretch min_rtts on new connections are
> > high and we're back to sending small TSO, keeping the sender overloaded.
> > Which is to say - I _hope_ this also solves some of Meta's problems :)
>
> Ugh, I didn't see the Sashiko report, it's only CCed to the author and bpf@, not to netdev :/
>
> The zero-check sounds legit. Let's revisit this after the merge window.
Thanks for the comment, I will take action after the merge window.
And, please correct me if I am wrong, the next eligible submission is expected from 30-June, right?
Thanks!
Chia-Yu
^ permalink raw reply
* [PATCH net v2] tipc: fix use-after-free of the discoverer in tipc_disc_rcv()
From: Weiming Shi @ 2026-06-16 12:22 UTC (permalink / raw)
To: netdev, tipc-discussion, linux-kernel
Cc: jmaloy, ying.xue, tung.quang.nguyen, edumazet, kuba, pabeni,
horms, davem, xmei5, Weiming Shi
bearer_disable() frees b->disc with tipc_disc_delete()'s plain kfree(),
but tipc_disc_rcv() still dereferences b->disc in RX softirq under
rcu_read_lock() (tipc_udp_recv -> tipc_rcv -> tipc_disc_rcv).
L2 bearers are safe thanks to the synchronize_net() in
tipc_disable_l2_media(), but the UDP bearer defers that call to the
cleanup_bearer() workqueue, so the discoverer is freed with no grace
period:
BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149)
Read of size 8 at addr ffff88802348b728 by task poc_tipc/184
<IRQ>
tipc_disc_rcv (net/tipc/discover.c:149)
tipc_rcv (net/tipc/node.c:2126)
tipc_udp_recv (net/tipc/udp_media.c:391)
udp_rcv (net/ipv4/udp.c:2643)
ip_local_deliver_finish (net/ipv4/ip_input.c:241)
</IRQ>
Freed by task 181:
kfree (mm/slub.c:6565)
bearer_disable (net/tipc/bearer.c:418)
tipc_nl_bearer_disable (net/tipc/bearer.c:1001)
The bearer is freed with kfree_rcu(); free the discoverer the same way.
Add an rcu_head to struct tipc_discoverer and free it and its skb from an
RCU callback.
Because the RCU callback (tipc_disc_free_rcu) lives in module text, a
call_rcu() that is still pending when the tipc module is unloaded would
invoke a freed function. Add an rcu_barrier() to tipc_exit() after the
bearer subsystem has been torn down, so all pending discoverer callbacks
have run before the module text goes away.
Reachable from an unprivileged user namespace: the TIPCv2 genl family is
netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs CONFIG_TIPC
and CONFIG_TIPC_MEDIA_UDP.
Fixes: 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash values")
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
v2:
- split the over-80-column container_of() line (Tung Quang Nguyen)
- add rcu_barrier() to tipc_exit() so a pending call_rcu() cannot fire
into freed module text after rmmod (Eric Dumazet)
net/tipc/core.c | 3 +++
net/tipc/discover.c | 14 ++++++++++++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/net/tipc/core.c b/net/tipc/core.c
index 434e70eabe08..747328e58d30 100644
--- a/net/tipc/core.c
+++ b/net/tipc/core.c
@@ -218,6 +218,9 @@ static void __exit tipc_exit(void)
unregister_pernet_device(&tipc_net_ops);
tipc_unregister_sysctl();
+ /* Wait for tipc_disc_free_rcu() callbacks queued from module text. */
+ rcu_barrier();
+
pr_info("Deactivated\n");
}
diff --git a/net/tipc/discover.c b/net/tipc/discover.c
index 3e54d2df5683..696b7a8ed54d 100644
--- a/net/tipc/discover.c
+++ b/net/tipc/discover.c
@@ -58,6 +58,7 @@
* @skb: request message to be (repeatedly) sent
* @timer: timer governing period between requests
* @timer_intv: current interval between requests (in ms)
+ * @rcu: RCU head for deferred freeing
*/
struct tipc_discoverer {
u32 bearer_id;
@@ -69,6 +70,7 @@ struct tipc_discoverer {
struct sk_buff *skb;
struct timer_list timer;
unsigned long timer_intv;
+ struct rcu_head rcu;
};
/**
@@ -382,6 +384,15 @@ int tipc_disc_create(struct net *net, struct tipc_bearer *b,
return 0;
}
+static void tipc_disc_free_rcu(struct rcu_head *rp)
+{
+ struct tipc_discoverer *d =
+ container_of(rp, struct tipc_discoverer, rcu);
+
+ kfree_skb(d->skb);
+ kfree(d);
+}
+
/**
* tipc_disc_delete - destroy object sending periodic link setup requests
* @d: ptr to link dest structure
@@ -389,8 +400,7 @@ int tipc_disc_create(struct net *net, struct tipc_bearer *b,
void tipc_disc_delete(struct tipc_discoverer *d)
{
timer_shutdown_sync(&d->timer);
- kfree_skb(d->skb);
- kfree(d);
+ call_rcu(&d->rcu, tipc_disc_free_rcu);
}
/**
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] tipc: fix use-after-free of discoverer in tipc_disc_rcv()
From: Weiming Shi @ 2026-06-16 12:28 UTC (permalink / raw)
To: Tung Quang Nguyen, Weiming Shi
Cc: Simon Horman, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Xiang Mei, Jon Maloy,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
In-Reply-To: <GV1P189MB1988A1CFCAA9214B6F009315C6182@GV1P189MB1988.EURP189.PROD.OUTLOOK.COM>
On Fri Jun 12, 2026 at 4:53 PM CST, Tung Quang Nguyen wrote:
>>Subject: [PATCH net] tipc: fix use-after-free of discoverer in tipc_disc_rcv()
>>
>>bearer_disable() frees b->disc with tipc_disc_delete()'s plain kfree(), but
>>tipc_disc_rcv() still dereferences b->disc in RX softirq under
>>rcu_read_lock() (tipc_udp_recv -> tipc_rcv -> tipc_disc_rcv).
>>
>>L2 bearers are safe thanks to the synchronize_net() in tipc_disable_l2_media(),
>>but the UDP bearer defers that call to the
>>cleanup_bearer() workqueue, so the discoverer is freed with no grace
>>period:
>>
>> BUG: KASAN: slab-use-after-free in tipc_disc_rcv (net/tipc/discover.c:149)
>>Read of size 8 at addr ffff88802348b728 by task poc_tipc/184 <IRQ>
>> tipc_disc_rcv (net/tipc/discover.c:149)
>> tipc_rcv (net/tipc/node.c:2126)
>> tipc_udp_recv (net/tipc/udp_media.c:391)
>> udp_rcv (net/ipv4/udp.c:2643)
>> ip_local_deliver_finish (net/ipv4/ip_input.c:241) </IRQ> Freed by task 181:
>> kfree (mm/slub.c:6565)
>> bearer_disable (net/tipc/bearer.c:418)
>> tipc_nl_bearer_disable (net/tipc/bearer.c:1001)
>>
>>The bearer is freed with kfree_rcu(); free the discoverer the same way.
>>Add an rcu_head to struct tipc_discoverer and free it and its skb from an RCU
>>callback.
>>
>>Reachable from an unprivileged user namespace: the TIPCv2 genl family is
>>netnsok and its bearer commands have no GENL_ADMIN_PERM. Needs
>>CONFIG_TIPC and CONFIG_TIPC_MEDIA_UDP.
>>
>>Fixes: 25b0b9c4e835 ("tipc: handle collisions of 32-bit node address hash
>>values")
>>Reported-by: Xiang Mei <xmei5@asu.edu>
>>Assisted-by: Claude:claude-opus-4-8
>>Signed-off-by: Weiming Shi <bestswngs@gmail.com>
>>---
>> net/tipc/discover.c | 13 +++++++++++--
>> 1 file changed, 11 insertions(+), 2 deletions(-)
>>
>>diff --git a/net/tipc/discover.c b/net/tipc/discover.c index
>>3e54d2df5683a..34dbe5ad10e09 100644
>>--- a/net/tipc/discover.c
>>+++ b/net/tipc/discover.c
>>@@ -58,6 +58,7 @@
>> * @skb: request message to be (repeatedly) sent
>> * @timer: timer governing period between requests
>> * @timer_intv: current interval between requests (in ms)
>>+ * @rcu: RCU head for deferred freeing
>> */
>> struct tipc_discoverer {
>> u32 bearer_id;
>>@@ -69,6 +70,7 @@ struct tipc_discoverer {
>> struct sk_buff *skb;
>> struct timer_list timer;
>> unsigned long timer_intv;
>>+ struct rcu_head rcu;
>> };
>>
>> /**
>>@@ -382,6 +384,14 @@ int tipc_disc_create(struct net *net, struct tipc_bearer
>>*b,
>> return 0;
>> }
>>
>>+static void tipc_disc_free_rcu(struct rcu_head *rp) {
>>+ struct tipc_discoverer *d = container_of(rp, struct tipc_discoverer,
>>+rcu);
>
> This line is long (over 80 columns). Please break it into 2 lines (refer to linux/Documentation/process/coding-style.rst).
>
>>+
>>+ kfree_skb(d->skb);
>>+ kfree(d);
>>+}
>>+
>> /**
>> * tipc_disc_delete - destroy object sending periodic link setup requests
>> * @d: ptr to link dest structure
>>@@ -389,8 +399,7 @@ int tipc_disc_create(struct net *net, struct tipc_bearer
>>*b, void tipc_disc_delete(struct tipc_discoverer *d) {
>> timer_shutdown_sync(&d->timer);
>>- kfree_skb(d->skb);
>>- kfree(d);
>>+ call_rcu(&d->rcu, tipc_disc_free_rcu);
>> }
>>
>> /**
>>--
>>2.43.0
>>
Hi,
I’m sorry for taking so long to respond. The v2 version has already been sent.
^ permalink raw reply
* [PATCH v4] flow_dissector: check device type before reading ETH_ADDRS
From: Yun Zhou @ 2026-06-16 12:30 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, horms
Cc: netdev, linux-kernel, yun.zhou, qingfang.deng
__skb_flow_dissect() unconditionally reads 12 bytes from eth_hdr(skb)
when FLOW_DISSECTOR_KEY_ETH_ADDRS is requested. This assumes the skb
has a valid Ethernet header at mac_header, which is not always the case.
The problem can be triggered by:
1. Creating a TUN device in L3 mode (IFF_TUN, hard_header_len=0)
2. Attaching a multiq qdisc with a flower filter matching on eth_src
3. Sending a packet through AF_PACKET
Since TUN in L3 mode has no link-layer header, mac_header points to
the L3 data area. The flow dissector reads 12 bytes of uninitialized
skb memory, which then propagates through fl_set_masked_key() and is
used as a rhashtable lookup key in __fl_lookup(), as reported by KMSAN.
Rejecting the filter in the control path (at tc filter add time) is
not feasible because TC filter blocks can be shared between arbitrary
devices -- a filter installed on an Ethernet device may later classify
packets on a headerless device through a shared block. The device
association is not fixed at filter creation time.
Fix this by gating the memcpy on dev->type == ARPHRD_ETHER, which
ensures only true Ethernet-framed packets have their addresses read.
This is more precise than the previous hard_header_len >= 12 check,
which would incorrectly pass for non-Ethernet link types like IPoIB
(ARPHRD_INFINIBAND, hard_header_len=24) and FDDI (hard_header_len=21)
whose L2 headers are not in Ethernet format. Additionally check
skb_mac_header_was_set() to guard against the pathological case where
mac_header is the unset sentinel (~0U), which would cause eth_hdr() to
return a wild pointer.
For the act_mirred redirect case (Ethernet packet redirected to a
non-Ethernet device sharing a TC block), zeroing the key is the correct
behavior: the packet is now being classified on the target device, where
Ethernet address matching is not semantically meaningful.
Note: on non-Ethernet devices, the zeroed key will match a filter
configured with all-zero MAC addresses. This is an improvement over the
previous behavior where uninitialized memory could randomly match any
filter.
Reported-by: syzbot+fa2f5b1fb06147be5e16@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fa2f5b1fb06147be5e16
Fixes: 67a900cc0436 ("flow_dissector: introduce support for Ethernet addresses")
Signed-off-by: Yun Zhou <yun.zhou@windriver.com>
---
v4:
- Use dev->type == ARPHRD_ETHER instead of hard_header_len >= 12 to
avoid false positives on non-Ethernet link types (IPoIB, FDDI)
- Add skb_mac_header_was_set() guard against unset mac_header sentinel
- Document act_mirred and all-zero key edge cases in commit message
v3:
- Replace skb_tail_pointer() - skb_mac_header() length check with
skb->dev->hard_header_len check.
v2:
- Adjust commit message and comment.
net/core/flow_dissector.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 2a98f5fa74eb..8aa4f9b4df81 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -1173,13 +1173,21 @@ bool __skb_flow_dissect(const struct net *net,
if (dissector_uses_key(flow_dissector,
FLOW_DISSECTOR_KEY_ETH_ADDRS)) {
- struct ethhdr *eth = eth_hdr(skb);
struct flow_dissector_key_eth_addrs *key_eth_addrs;
key_eth_addrs = skb_flow_dissector_target(flow_dissector,
FLOW_DISSECTOR_KEY_ETH_ADDRS,
target_container);
- memcpy(key_eth_addrs, eth, sizeof(*key_eth_addrs));
+ /* TC filter blocks can be shared across devices with
+ * different link types, so we cannot validate this
+ * when the filter is installed -- check at dissect time.
+ */
+ if (skb && skb->dev &&
+ skb->dev->type == ARPHRD_ETHER &&
+ skb_mac_header_was_set(skb))
+ memcpy(key_eth_addrs, eth_hdr(skb), sizeof(*key_eth_addrs));
+ else
+ memset(key_eth_addrs, 0, sizeof(*key_eth_addrs));
}
if (dissector_uses_key(flow_dissector,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] [net] net: airoha: fix foe_check_time allocation size
From: Lorenzo Bianconi @ 2026-06-16 12:34 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178161119471.2163752.14373384830691569758@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
> foe_check_time is declared as u16 pointer but was allocated with
> only ppe_num_entries bytes instead of ppe_num_entries * sizeof(u16).
>
> When airoha_ppe_foe_verify_entry() is called with hash >= ppe_num_entries/2,
> it writes beyond the allocated buffer, causing heap buffer overflow and
> potential kernel crash.
>
> Fixes: 6d5b601d52a2 ("net: airoha: ppe: Dynamically allocate foe_check_time array in airoha_ppe struct")
> Signed-off-by: Wayen Yan <win847@gmail.com>
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_ppe.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
> index 5c9dff6bcc..8fb8ecf909 100644
> --- a/drivers/net/ethernet/airoha/airoha_ppe.c
> +++ b/drivers/net/ethernet/airoha/airoha_ppe.c
> @@ -1578,7 +1578,8 @@ int airoha_ppe_init(struct airoha_eth *eth)
> return -ENOMEM;
> }
>
> - ppe->foe_check_time = devm_kzalloc(eth->dev, ppe_num_entries,
> + ppe->foe_check_time = devm_kzalloc(eth->dev,
> + ppe_num_entries * sizeof(*ppe->foe_check_time),
> GFP_KERNEL);
> if (!ppe->foe_check_time)
> return -ENOMEM;
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] [net] net: airoha: Fix QoS counter configuration for Tx-fwd channels
From: Lorenzo Bianconi @ 2026-06-16 12:35 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178161132384.2164449.18407700117859190327@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
> In airoha_qdma_init_qos_stats(), the Tx-fwd counter was incorrectly
> using register index (i << 1) instead of ((i << 1) + 1). This caused
> the Tx-fwd configuration to overwrite the Tx-cpu configuration for
> each QoS channel, resulting in incorrect QoS statistics.
>
> Fix by using the correct register index ((i << 1) + 1) for Tx-fwd
> counter configuration.
>
> Fixes: 20bf7d07c956 ("net: airoha: Add sched ETS offload support")
> Signed-off-by: Wayen Yan <win847@gmail.com>
Is this a patch you already sent? IIRC I have acked it.
Regards,
Lorenzo
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..329988a840 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1256,7 +1256,7 @@ static void airoha_qdma_init_qos_stats(struct airoha_qdma *qdma)
> FIELD_PREP(CNTR_CHAN_MASK, i));
> /* Tx-fwd transferred count */
> airoha_qdma_wr(qdma, REG_CNTR_VAL((i << 1) + 1), 0);
> - airoha_qdma_wr(qdma, REG_CNTR_CFG(i << 1),
> + airoha_qdma_wr(qdma, REG_CNTR_CFG((i << 1) + 1),
> CNTR_EN_MASK | CNTR_ALL_QUEUE_EN_MASK |
> CNTR_ALL_DSCP_RING_EN_MASK |
> FIELD_PREP(CNTR_SRC_MASK, 1) |
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v2 1/2] iov_iter: export iov_iter_restore
From: Stefano Garzarella @ 2026-06-16 12:35 UTC (permalink / raw)
To: Octavian Purdila
Cc: netdev, Alexander Viro, Andrew Morton, Arseniy Krasnov,
David S. Miller, Eric Dumazet, Eugenio Pérez, Jakub Kicinski,
Jason Wang, kvm, linux-block, linux-fsdevel, linux-kernel,
Michael S. Tsirkin, Paolo Abeni, Simon Horman, Stefan Hajnoczi,
virtualization, Xuan Zhuo
In-Reply-To: <20260613000953.467473-2-tavip@google.com>
On Sat, Jun 13, 2026 at 12:09:52AM +0000, Octavian Purdila wrote:
>Export iov_iter_restore so that it can be used by modules.
>
>This is needed by the virtio vsock transport (which can be built as a
>module) to restore the msg_iter state when transmission fails.
>
>Signed-off-by: Octavian Purdila <tavip@google.com>
>---
> lib/iov_iter.c | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Stefano Garzarella <sgarzare@redhat.com>
>
>diff --git a/lib/iov_iter.c b/lib/iov_iter.c
>index 243662af1af73..067e745f9ef53 100644
>--- a/lib/iov_iter.c
>+++ b/lib/iov_iter.c
>@@ -1491,6 +1491,7 @@ void iov_iter_restore(struct iov_iter *i, struct iov_iter_state *state)
> i->__iov -= state->nr_segs - i->nr_segs;
> i->nr_segs = state->nr_segs;
> }
>+EXPORT_SYMBOL(iov_iter_restore);
>
> /*
> * Extract a list of contiguous pages from an ITER_FOLIOQ iterator. This does
>--
>2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH v2] [net] net: airoha: Stop TX queues on error path in airoha_dev_open
From: Lorenzo Bianconi @ 2026-06-16 12:37 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178161146875.2165143.7400860261990016053@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]
> In airoha_dev_open(), if airoha_set_vip_for_gdm_port() fails after
> netif_tx_start_all_queues() has been called, the TX queues remain
> started while the device configuration is incomplete. This leaves
> the device in an inconsistent state where packets could be
> transmitted before the VIP/IFC port configuration is complete.
>
> Add netif_tx_stop_all_queues() call on the error path to properly
> roll back the TX queue state.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Wayen Yan <win847@gmail.com>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..cf9c366907 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1715,8 +1715,10 @@ static int airoha_dev_open(struct net_device *dev)
>
> netif_tx_start_all_queues(dev);
> err = airoha_set_vip_for_gdm_port(port, true);
> - if (err)
> + if (err) {
> + netif_tx_stop_all_queues(dev);
I do not think this is necessary since if ndo_open() callback fails, the
net_device is not marked as running.
Regards,
Lorenzo
> return err;
> + }
>
> if (netdev_uses_dsa(dev))
> airoha_fe_set(qdma->eth, REG_GDM_INGRESS_CFG(port->id),
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: ti: icssm-prueth: Support duplicate HW offload feature for HSR and PRP
From: Parvathi Pudi @ 2026-06-16 12:38 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Parvathi Pudi, andrew+netdev, davem, edumazet, pabeni,
danishanwar, rogerq, pmohan, afd, basharath, arnd, linux-kernel,
netdev, linux-arm-kernel, pratheesh, j-rameshbabu,
Vignesh Raghavendra, praneeth, srk, rogerq, m-malladi, krishna,
mohan
In-Reply-To: <20260615135600.655e4be4@kernel.org>
Hi,
> On Thu, 11 Jun 2026 18:03:28 +0530 Parvathi Pudi wrote:
>> From: Roger Quadros <rogerq@ti.com>
>>
>> In HSR and PRP modes each outgoing frame must be sent on both PRU slave
>> ports.
>>
>> Previously the driver was writing the frame into each port's transmit queue
>> independently after updating the tags resulting in performing two OCMC
>> buffer copy operations.
>>
>> Frame duplicate offloading is implemented with a common shared queue
>> between the two ports. The driver writes the frame once into OCMC RAM,
>> each port reads from the shared queue and replicates the transmission to
>> both PRU ports, synchronising between PRU ports are maintained within
>> firmware with appropriate handling.
>>
>> For HSR the driver inspects the encapsulated ethertype in the HSR tag.
>> PTP frames (ETH_P_1588) are sent on the directed port only to avoid double
>> duplication and all other HSR frames are duplicated to both ports.
>> VLAN-tagged HSR frames are handled by advancing past the 4-byte VLAN header
>> before reading the HSR tag.
>>
>> For PRP the driver checks the 6-byte RCT trailer for the ETH_P_PRP suffix
>> to identify redundancy-tagged frames. Frames without an RCT are sent on the
>> originating port only.
>
> Warning: drivers/net/ethernet/ti/icssm/icssm_prueth.h:113 struct member
> 'host_recv_flag' not described in 'prueth_packet_info'
>
We will address this in the next version.
> Please note that net-next will be closed for the next two weeks.
Also noted regarding the net-next closure. We will post the updated series
once the tree reopens.
Thanks and Regards,
Parvathi.
^ permalink raw reply
* Re: [PATCH v2] atm: fix use-after-free in sigd_put_skb()
From: Weiming Shi @ 2026-06-16 12:39 UTC (permalink / raw)
To: Jakub Kicinski, Weiming Shi
Cc: Chas Williams, David S . Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, linux-atm-general, netdev, linux-kernel, Xiang Mei
In-Reply-To: <20260612161051.2d4df09b@kernel.org>
On Sat Jun 13, 2026 at 7:10 AM CST, Jakub Kicinski wrote:
> On Wed, 10 Jun 2026 00:21:08 +0800 Weiming Shi wrote:
>> sigd_put_skb() delivers a signalling message to the daemon socket named
>> by the global @sigd pointer, ending in a call to sk_data_ready(). It
>> reads @sigd with no synchronisation, so it can race with a close of the
>> daemon socket: sigd_close() clears @sigd and the socket is then torn
>> down and freed.
>
> Hm, we intend to only retain the portions of the ATM stack which are
> still used in PPPoATM and ADSL. I don't believe the signaling stuff
> is used there. I will post a patch to delete this code.
Thanks, that makes sense to me.
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] udmabuf: emit one sg entry per pinned folio
From: Jason Gunthorpe @ 2026-06-16 12:40 UTC (permalink / raw)
To: Kasireddy, Vivek
Cc: Bobby Eshleman, Donald Hunter, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Andrew Lunn,
Gerd Hoffmann, Sumit Semwal, Christian König, Shuah Khan,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
linaro-mm-sig@lists.linaro.org, linux-kselftest@vger.kernel.org,
sdf@fomichev.me, razor@blackwall.org, daniel@iogearbox.net,
almasrymina@google.com, matttbe@kernel.org, skhawaja@google.com,
dw@davidwei.uk, Bobby Eshleman
In-Reply-To: <IA0PR11MB71852246277F773AC41DAAA3F8E52@IA0PR11MB7185.namprd11.prod.outlook.com>
On Tue, Jun 16, 2026 at 06:04:03AM +0000, Kasireddy, Vivek wrote:
> > This is helpful for importers like net/core/devmem that expect dmabuf sg
> IMO, udmabuf needs to detect whether importers can handle segments that
> are > PAGE_SIZE and set the entries appropriately. Please look into how the
> GPU drivers and other dmabuf exporters/importers handle this situation, so
> that we can adopt best practices to address this issue.
Importers have to handle arbitary scatterlists, devmem is just broken
if it can't handle the output of sg_alloc_table_from_pages().
Jason
^ permalink raw reply
* Re: [PATCH net-next 0/3] Introduce HSR/PRP HW offload support for PRU-ICSSM Ethernet driver
From: Parvathi Pudi @ 2026-06-16 12:40 UTC (permalink / raw)
To: Simon Horman
Cc: Parvathi Pudi, andrew+netdev, davem, edumazet, kuba, pabeni,
danishanwar, rogerq, pmohan, afd, basharath, arnd, linux-kernel,
netdev, linux-arm-kernel, pratheesh, j-rameshbabu,
Vignesh Raghavendra, praneeth, srk, rogerq, m-malladi, krishna,
mohan
In-Reply-To: <20260612200102.GN671640@horms.kernel.org>
Hi,
> On Thu, Jun 11, 2026 at 06:03:25PM +0530, Parvathi Pudi wrote:
>> Hi,
>>
>> This series introduces HSR and PRP protocol HW offload support for
>> ICSSM-Prueth driver. HW offload support for HSR/PRP is implemented using
>> dedicated HSR/PRP firmware running on 2 PRU cores(PRU-ICSS) as a "DAN"
>> available in AM57xx, AM437x and AM335x.
>
> Hi Parvathi,
>
> There is AI-generated review of this patch-set available on
> https://sashiko.dev
>
> I would appreciate it if you could look over that with a view
> to addressing any issues that directly affect this patch-set.
Sure. We will review the sashiko feedback for this patch series and
address any findings that are directly relevant in the next version.
Thanks and Regards,
Parvathi.
^ permalink raw reply
* [PATCH net v3] net: airoha: Fix skb->priority underflow in airoha_dev_select_queue()
From: Wayen Yan @ 2026-06-13 23:30 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In airoha_dev_select_queue(), the expression:
queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES;
implicitly converts to unsigned arithmetic: when skb->priority is 0
(the default for unclassified traffic), (0u - 1u) wraps to UINT_MAX,
and UINT_MAX % 8 = 7, routing default best-effort packets to the
highest-priority QoS queue. This causes QoS inversion where the
majority of traffic on a PON gateway starves actual high-priority
flows (VoIP, gaming, etc.).
Fix by guarding the subtraction: when priority is 0, map to queue 0
(lowest priority), otherwise apply the original (priority - 1) % 8
mapping.
Fixes: 2b288b81560b ("net: airoha: Introduce ndo_select_queue callback")
Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Joe Damato <joe@dama.to>
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 31cdb11cd7..d476ef83c3 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1933,7 +1933,7 @@ static u16 airoha_dev_select_queue(struct net_device *dev, struct sk_buff *skb,
*/
channel = netdev_uses_dsa(dev) ? skb_get_queue_mapping(skb) : port->id;
channel = channel % AIROHA_NUM_QOS_CHANNELS;
- queue = (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES; /* QoS queue */
+ queue = skb->priority ? (skb->priority - 1) % AIROHA_NUM_QOS_QUEUES : 0;
queue = channel * AIROHA_NUM_QOS_QUEUES + queue;
return queue < dev->num_tx_queues ? queue : 0;
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2] [net] net: airoha: Clean up RX queues in airoha_dev_stop
From: Lorenzo Bianconi @ 2026-06-16 12:45 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178161160256.2165161.14322392784449633554@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]
On Jun 16, Wayen Yan wrote:
> When the last port is stopped, airoha_dev_stop() clears TX queues
> but neglects to clean up RX queues. This can lead to:
> - RX ring buffer descriptors remaining valid after device close
> - Potential DMA synchronization issues on device reopen
> - Risk of use-after-free if pages are freed while DMA is still active
>
> Add cleanup loop for RX queues to mirror the TX queue cleanup,
> ensuring symmetric resource management.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Wayen Yan <win847@gmail.com>
when you send a new revision:
- please add a note of what you changed with respect to the previous one.
- please give some time to reviewers to take a look to the previous revision.
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 31cdb11cd7..9ca5bbf64d 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1771,6 +1771,13 @@ static int airoha_dev_stop(struct net_device *dev)
>
> airoha_qdma_cleanup_tx_queue(&qdma->q_tx[i]);
> }
> +
> + for (i = 0; i < ARRAY_SIZE(qdma->q_rx); i++) {
> + if (!qdma->q_rx[i].ndesc)
> + continue;
> +
> + airoha_qdma_cleanup_rx_queue(&qdma->q_rx[i]);
> + }
> }
I do not think this patch is needed since there is no point to remove all the
RX buffers from the hw RX queues stopping the device, this is necessary just
removing the module (I think we can avoid it for TX too, I have a patch for it
I need to post).
Moreover, doing so, when the device is opened again, RX queues will be empty.
Regards,
Lorenzo
>
> return 0;
> --
> 2.51.0
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/9] atm: remove AAL3/4 transport support
From: David Laight @ 2026-06-16 12:46 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, 3chas3,
mitch, linux-atm-general, dwmw2
In-Reply-To: <20260613201032.77274-2-kuba@kernel.org>
On Sat, 13 Jun 2026 13:10:24 -0700
Jakub Kicinski <kuba@kernel.org> wrote:
> AAL3/4 is an obsolete connection-oriented ATM adaptation layer that has
> seen no real use since the SMDS-era hardware it was designed for (90s?).
...
From what I remember they weren't really used even then.
Apart from 'uncompressed 64k telephony audio' pretty much everything actually
used AAL5 so that data could be compressed.
I do remember PCI ATM cards that could be used for TCP/ATM to the desktop.
The equipment you needed in the network rack to make it work was stunning.
Completely killed by 100M ethernet over twisted pair.
David
^ permalink raw reply
* Re: [PATCH net-next v7 2/2] net: ti: icssg-prueth: Add ethtool ops for Frame Preemption MAC Merge
From: Meghana Malladi @ 2026-06-16 12:54 UTC (permalink / raw)
To: Jakub Kicinski
Cc: elfring, haokexin, vadim.fedorenko, devnexen, horms,
jacob.e.keller, arnd, basharath, afd, parvathi, vladimir.oltean,
rogerq, danishanwar, pabeni, edumazet, davem, andrew+netdev,
linux-arm-kernel, netdev, linux-kernel, srk, vigneshr
In-Reply-To: <20260615163932.50bb3df0@kernel.org>
Hi Jakub,
On 6/16/26 05:09, Jakub Kicinski wrote:
> On Mon, 15 Jun 2026 16:10:41 -0700 Jakub Kicinski wrote:
>>> diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>> index 5ec0b38e0c67..8073deac35c3 100644
>>> --- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>> +++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>> @@ -189,6 +187,11 @@ static const struct icssg_pa_stats icssg_all_pa_stats[] = {
>>> ICSSG_PA_STATS(FW_INF_DROP_PRIOTAGGED),
>>> ICSSG_PA_STATS(FW_INF_DROP_NOTAG),
>>> ICSSG_PA_STATS(FW_INF_DROP_NOTMEMBER),
>>> + ICSSG_PA_STATS(FW_PREEMPT_BAD_FRAG),
>>> + ICSSG_PA_STATS(FW_PREEMPT_ASSEMBLY_ERR),
>>> + ICSSG_PA_STATS(FW_PREEMPT_FRAG_CNT_TX),
>>> + ICSSG_PA_STATS(FW_PREEMPT_ASSEMBLY_OK),
>>> + ICSSG_PA_STATS(FW_PREEMPT_FRAG_CNT_RX),
>>> ICSSG_PA_STATS(FW_RX_EOF_SHORT_FRMERR),
>>> ICSSG_PA_STATS(FW_RX_B0_DROP_EARLY_EOF),
>>> ICSSG_PA_STATS(FW_TX_JUMBO_FRM_CUTOFF),
>>
>> [Medium]
>> Are these five new entries duplicating values that already have a
>> standard uAPI?
>>
>> The same five firmware counters are exposed through the new
>> .get_mm_stats callback as the standardized MAC Merge stats
>> (MACMergeFrameAssOkCount, MACMergeFrameAssErrorCount, MACMergeFragCountRx,
>> MACMergeFragCountTx, MACMergeFrameSmdErrorCount in struct
>> ethtool_mm_stats), and adding them to icssg_all_pa_stats[] also
>> publishes them via emac_get_strings() / emac_get_ethtool_stats() as
>> ethtool -S strings.
>>
>> Documentation/networking/statistics.rst describes ethtool -S as the
>> private-driver-stats interface; counters that have a standard uAPI are
>> expected to flow only through that uAPI.
>>
>> Could the firmware-register lookup table used by emac_get_stat_by_name()
>> be separated from the ethtool -S string table, so the new preemption
>> counters feed get_mm_stats without also showing up under ethtool -S?
>
> This -- not sure about the other complaints but this one looks legit.
I agree that this is legit, but right now there is no other place holder
other than pa stats to put the mac merge firmware counters. I believe
the effort needs to go in re-structuring the hardware and firmware stats
implementation to address this issue.
^ permalink raw reply
* Re: [PATCH net v2 2/2] vsock/virtio: restore msg_iter on transmission failure
From: Stefano Garzarella @ 2026-06-16 12:59 UTC (permalink / raw)
To: Octavian Purdila, g
Cc: netdev, Alexander Viro, Andrew Morton, Arseniy Krasnov,
David S. Miller, Eric Dumazet, Eugenio Pérez, Jakub Kicinski,
Jason Wang, kvm, linux-block, linux-fsdevel, linux-kernel,
Michael S. Tsirkin, Paolo Abeni, Simon Horman, Stefan Hajnoczi,
virtualization, Xuan Zhuo, syzbot+28e5f3d207b14bae122a
In-Reply-To: <20260613000953.467473-3-tavip@google.com>
On Sat, Jun 13, 2026 at 12:09:53AM +0000, Octavian Purdila wrote:
>When transmission fails in virtio_transport_send_pkt_info, the msg_iter
>might have been partially advanced. If we don't restore it, the next
>attempt to send data will use an incorrect iterator state, leading to
>desync and warnings like "send_pkt() returns 0, but X expected".
>
>Specifically, this can happen in the following scenario, triggered by
>the syzkaller repro:
>
>1. A write-only VMA (PROT_WRITE only) is partially populated by a
> prior TUN write that failed with -EIO but still faulted in some
> pages).
>2. A vsock sendmmsg call with MSG_ZEROCOPY requests transmission of a
> buffer from this VMA.
>3. The first packet (64KB) is sent successfully because the pages are
> populated.
>4. The second packet allocation fails because GUP fast pins the first page
> but GUP slow fails on the next unpopulated page due to PROT_WRITE-only
> permissions.
>5. The iterator is advanced by the partially successful GUP (68KB total
> advanced: 64KB from first packet + 4KB from second), but the send loop
> breaks and only reports 64KB sent. This creates a 4KB desync.
>6. The next retry starts with a non-zero iov_offset, disabling zerocopy
> and falling back to copy mode.
>7. In copy mode, the transmission succeeds for the next packets but
> exhausts the iterator early because of the desync.
>8. The final retry sees an empty iterator but zerocopy is re-enabled
> (offset resets). It attempts to send the remaining bytes with zerocopy
> but pins 0 pages, creating an empty packet.
>9. The transport sends the empty packet, triggering the warning because
> the returned bytes (header only) do not match the expected payload size.
>10. The loop continues to spin, allocating ubuf_info each time, eventually
> exhausting sysctl_optmem_max and returning -ENOMEM to userspace.
>
>Restore msg_iter to its original state before the packet allocation
>and transmission attempt if they fail.
>
>Fixes: e0718bd82e27 ("vsock: enable setting SO_ZEROCOPY")
>Reported-by: syzbot+28e5f3d207b14bae122a@syzkaller.appspotmail.com
>Closes: https://syzkaller.appspot.com/bug?extid=28e5f3d207b14bae122a
>Assisted-by: gemini:gemini-3.1-pro
>Signed-off-by: Octavian Purdila <tavip@google.com>
>---
> net/vmw_vsock/virtio_transport_common.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
Thanks, looks much better to me now!
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
^ permalink raw reply
* [Bug] incompatibility between 'e1000e' and Aruba AOS-CX switches (too small inter-packet gap)
From: Philippe Andersson @ 2026-06-16 13:07 UTC (permalink / raw)
To: netdev; +Cc: Ludovic Calmant, Fabian Noël
[-- Attachment #1.1.1: Type: text/plain, Size: 2726 bytes --]
Hello,
Our product (a medical oncology system) uses TCP/IP for time-critical
communications between control systems (PCs running Linux) and
electronic units or PLCs.
We recently upgraded our standard networking equipment from the old
HPE/Aruba "ProCurve" line to the new Aruba AOS-CX one, and since then we
started experiencing communication issues caused by (or triggering)
larger than usual packet retransmits specifically on hosts that use the
'e1000e' driver (Intel I219-LM and Intel 82579LM boards). This issue
immediately affects the time-critical communication channels I mentioned
above, but are also seen e.g. in regular NFS communications (although in
this case the effect is not generally perceptible to the user).
Here are the tests we did to try and narrow down the problem:
- add a single AOS-CX switch to our older network topology, connect a
single Debian 12 workstation to it, simulate a clinical workflow:
problem present
- in the same test setup as above, configure the Debian workstation to
use its 2nd NIC instead, which uses the 'igb' driver: problem disappears
(idem when plugging in an extra PCI NIC that uses the 'tg3' driver)
- in a lab environment, try to reproduce the problem with a single
Debian 13 workstation, a single AOS-CX switch and a sole communication
partner: could not reproduce (hypothesis: because the "background noise"
on the network is too low)
- on a test site already equipped with AOS-CX switches, upgraded the
Debian workstation to Debian 13 (kernel 6.12.x), simulate a clinical
workflow: problem present
- on a test site already equipped with AOS-CX switches, force
workstation port to 100Mbps half-duplex: problem disappears
- set option "interpacket-gap high-average" on Aruba AOS-CX switch: no
effect
- activate flow-control on workstation and switch port: no effect
A support ticket has already been opened with Aruba, but it's unclear at
this stage that the problem is on their side. Based on their analysis:
"There was a BUG noted for the same issue for the devices
with Intel I219-LM Network Card. This issue is observed with
some NIC cards that are not tolerant to smaller inter packet gap,
these NICs will silently drop packets at certain inter packet gaps."
We can provide packet captures that illustrate the problem if it can
help (but ideally through direct email, not this list).
Is this issue already known/tracked on your side?
Thanks in advance.
Best regards,
Ph. A.
--
*Philippe Andersson*
Unix System Administrator
IBA Particle Therapy |
Tel: +32-10-475.983
Fax: +32-10-487.707
eMail: pan@iba-group.com
<http://www.iba-worldwide.com>
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3165 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ 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