* [PATCH net v2 1/2] tcp: call sk_data_ready() after listener migration
From: Zhenzhong Wu @ 2026-04-18 18:13 UTC (permalink / raw)
To: netdev
Cc: edumazet, ncardwell, kuniyu, davem, dsahern, kuba, pabeni, horms,
shuah, tamird, linux-kernel, linux-kselftest, Zhenzhong Wu,
stable
In-Reply-To: <20260418181333.1713389-1-jt26wzz@gmail.com>
When inet_csk_listen_stop() migrates an established child socket from
a closing listener to another socket in the same SO_REUSEPORT group,
the target listener gets a new accept-queue entry via
inet_csk_reqsk_queue_add(), but that path never notifies the target
listener's waiters. A nonblocking accept() still works because it
checks the queue directly, but poll()/epoll_wait() waiters and
blocking accept() callers can also remain asleep indefinitely.
Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration
in inet_csk_listen_stop().
However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired
in reuseport_migrate_sock() is effectively transferred to
nreq->rsk_listener. Another CPU can then dequeue nreq via accept()
or listener shutdown, hit reqsk_put(), and drop that listener ref.
Since listeners are SOCK_RCU_FREE, wrap the post-queue_add()
dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also
covers the existing sock_net(nsk) access in that path.
The reqsk_timer_handler() path does not need the same changes for two
reasons: half-open requests become readable only after the final ACK,
where tcp_child_process() already wakes the listener; and once nreq is
visible via inet_ehash_insert(), the success path no longer touches
nsk directly.
Fixes: 54b92e841937 ("tcp: Migrate TCP_ESTABLISHED/TCP_SYN_RECV sockets in accept queues.")
Cc: stable@vger.kernel.org
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Zhenzhong Wu <jt26wzz@gmail.com>
---
net/ipv4/inet_connection_sock.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 4ac3ae1bc..928654c34 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -1479,16 +1479,19 @@ void inet_csk_listen_stop(struct sock *sk)
if (nreq) {
refcount_set(&nreq->rsk_refcnt, 1);
+ rcu_read_lock();
if (inet_csk_reqsk_queue_add(nsk, nreq, child)) {
__NET_INC_STATS(sock_net(nsk),
LINUX_MIB_TCPMIGRATEREQSUCCESS);
reqsk_migrate_reset(req);
+ READ_ONCE(nsk->sk_data_ready)(nsk);
} else {
__NET_INC_STATS(sock_net(nsk),
LINUX_MIB_TCPMIGRATEREQFAILURE);
reqsk_migrate_reset(nreq);
__reqsk_free(nreq);
}
+ rcu_read_unlock();
/* inet_csk_reqsk_queue_add() has already
* called inet_child_forget() on failure case.
--
2.43.0
^ permalink raw reply related
* [PATCH net v2 2/2] selftests/bpf: check epoll readiness after reuseport migration
From: Zhenzhong Wu @ 2026-04-18 18:13 UTC (permalink / raw)
To: netdev
Cc: edumazet, ncardwell, kuniyu, davem, dsahern, kuba, pabeni, horms,
shuah, tamird, linux-kernel, linux-kselftest, Zhenzhong Wu
In-Reply-To: <20260418181333.1713389-1-jt26wzz@gmail.com>
After migrate_dance() moves established children to the target
listener, add it to an epoll set and verify that epoll_wait(..., 0)
reports it ready before accept().
This adds epoll coverage for the TCP_ESTABLISHED reuseport migration
case in migrate_reuseport.
Keep the check limited to TCP_ESTABLISHED cases. TCP_SYN_RECV and
TCP_NEW_SYN_RECV still depend on asynchronous handshake completion,
so a zero-timeout epoll_wait() would race there.
Signed-off-by: Zhenzhong Wu <jt26wzz@gmail.com>
---
.../bpf/prog_tests/migrate_reuseport.c | 32 ++++++++++++++++++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
index 653b0a20f..580a53424 100644
--- a/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
+++ b/tools/testing/selftests/bpf/prog_tests/migrate_reuseport.c
@@ -18,13 +18,16 @@
* 9. call shutdown() for the second server
* and migrate the requests in the accept queue
* to the last server socket.
- * 10. call accept() for the last server socket.
+ * 10. for TCP_ESTABLISHED cases, call epoll_wait(..., 0)
+ * for the last server socket.
+ * 11. call accept() for the last server socket.
*
* Author: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
*/
#include <bpf/bpf.h>
#include <bpf/libbpf.h>
+#include <sys/epoll.h>
#include "test_progs.h"
#include "test_migrate_reuseport.skel.h"
@@ -522,6 +525,33 @@ static void run_test(struct migrate_reuseport_test_case *test_case,
goto close_clients;
}
+ /* Only TCP_ESTABLISHED has already-migrated accept-queue entries
+ * here. Later states still depend on follow-up handshake work.
+ */
+ if (test_case->state == BPF_TCP_ESTABLISHED) {
+ struct epoll_event ev = {
+ .events = EPOLLIN,
+ };
+ int epfd;
+ int nfds;
+
+ epfd = epoll_create1(EPOLL_CLOEXEC);
+ if (!ASSERT_NEQ(epfd, -1, "epoll_create1"))
+ goto close_clients;
+
+ ev.data.fd = test_case->servers[MIGRATED_TO];
+ if (!ASSERT_OK(epoll_ctl(epfd, EPOLL_CTL_ADD,
+ test_case->servers[MIGRATED_TO], &ev),
+ "epoll_ctl"))
+ goto close_epfd;
+
+ nfds = epoll_wait(epfd, &ev, 1, 0);
+ ASSERT_EQ(nfds, 1, "epoll_wait");
+
+close_epfd:
+ close(epfd);
+ }
+
count_requests(test_case, skel);
close_clients:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net 00/14] tcp: take care of tcp_get_timestamping_opt_stats() races
From: patchwork-bot+netdevbpf @ 2026-04-18 18:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, ncardwell, kuniyu, netdev,
eric.dumazet
In-Reply-To: <20260416200319.3608680-1-edumazet@google.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 20:03:05 +0000 you wrote:
> tcp_get_timestamping_opt_stats() does not own the socket lock,
> this is intentional.
>
> It calls tcp_get_info_chrono_stats() while other threads could
> change chrono fields in tcp_chrono_set(). It also reads many
> tcp socket fields that can be modified by other cpus/threads.
>
> [...]
Here is the summary with links:
- [net,01/14] tcp: annotate data-races in tcp_get_info_chrono_stats()
https://git.kernel.org/netdev/net/c/267bf3cf9a6f
- [net,02/14] tcp: add data-race annotations around tp->data_segs_out and tp->total_retrans
https://git.kernel.org/netdev/net/c/21e92a38cfd8
- [net,03/14] tcp: add data-races annotations around tp->reordering, tp->snd_cwnd
https://git.kernel.org/netdev/net/c/829ba1f329cb
- [net,04/14] tcp: annotate data-races around tp->snd_ssthresh
https://git.kernel.org/netdev/net/c/fd571afb05eb
- [net,05/14] tcp: annotate data-races around tp->delivered and tp->delivered_ce
https://git.kernel.org/netdev/net/c/faa886ad3ce5
- [net,06/14] tcp: add data-race annotations for TCP_NLA_SNDQ_SIZE
https://git.kernel.org/netdev/net/c/124199444de4
- [net,07/14] tcp: annotate data-races around tp->bytes_sent
https://git.kernel.org/netdev/net/c/ee43e957ce2e
- [net,08/14] tcp: annotate data-races around tp->bytes_retrans
https://git.kernel.org/netdev/net/c/5efc7b9f7cbd
- [net,09/14] tcp: annotate data-races around tp->dsack_dups
https://git.kernel.org/netdev/net/c/a984705ca88b
- [net,10/14] tcp: annotate data-races around tp->reord_seen
https://git.kernel.org/netdev/net/c/62585690e6b2
- [net,11/14] tcp: annotate data-races around tp->srtt_us
https://git.kernel.org/netdev/net/c/290b693ce7c9
- [net,12/14] tcp: annotate data-races around tp->timeout_rehash
https://git.kernel.org/netdev/net/c/71c675358b71
- [net,13/14] tcp: annotate data-races around (tp->write_seq - tp->snd_nxt)
https://git.kernel.org/netdev/net/c/3a63b3d16056
- [net,14/14] tcp: annotate data-races around tp->plb_rehash
https://git.kernel.org/netdev/net/c/9e89b9d03a2d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 0/6] pull request: fixes for ovpn 2026-04-17
From: Jakub Kicinski @ 2026-04-18 18:54 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev, ralf, shuah, horms, Sabrina Dubroca, Paolo Abeni,
Andrew Lunn, David S. Miller, Eric Dumazet
In-Reply-To: <20260417090305.2775723-1-antonio@openvpn.net>
On Fri, 17 Apr 2026 11:02:59 +0200 Antonio Quartulli wrote:
> This is a respin of the PR I originally sent against net-next + an extra
> fix (patch 6).
>
> Please note that this patch:
> https://lore.kernel.org/all/20260225010833.11301-1-liuhangbin@gmail.com/
> broke the selftests entirely due to the switch from sh to bash.
>
> There are new commits in the kselftest tree which take care of this:
> https://lore.kernel.org/all/20260416-selftest-fix-readlink-e-v1-0-94e4cabbdec4@kernel.org/
> but they are not in net yet, therefore you won't be able to test/run
> our kselftests for now.
It does work for us, FWIW, maybe because we run tests with make
run_tests. There were some entirely unnecessary changes to ktap
output which broke our systems but we patched around them :/
> TCP tests are still failing every now and then.
> It seems that sometimes a single ping over a TCP tunnel is lost,
> thus making the selftest fail.
They seem to fail for us around 50% of the time on debug kernel
builds. What's your repro rate?
> We believe this is a bug in ovpn which we are currently hunting down.
> So it's nothing wrong about the tests (they are actually doing their
> job!).
FWIW one of today's runs hit this:
https://netdev-ctrl.bots.linux.dev/logs/vmksft/net-extra-dbg/results/608740/3-test-symmetric-id-tcp-sh/stderr
decoded:
https://netdev-ctrl.bots.linux.dev/logs/vmksft/net-extra-dbg/results/608740/vm-crash-thr0-0
In any case - test_mark.sh looks good now, so I'll take it out of
the ignored list. Thanks! 2 more to go? :)
^ permalink raw reply
* Re: [PATCH net v2 11/12] idpf: fix xdp crash in soft reset error path
From: Jakub Kicinski @ 2026-04-18 19:00 UTC (permalink / raw)
To: jacob.e.keller
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni, netdev,
emil.s.tantilov, stable, aleksandr.loktionov, patryk.holda
In-Reply-To: <20260416-iwl-net-submission-2026-04-14-v2-11-686c33c9828d@intel.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Jakub: I'll drop this patch and apply the rest.
---
idpf: fix xdp crash in soft reset error path
This commit fixes a NULL pointer dereference in idpf_vport_open() when
soft reset fails by restoring vport->xdp_prog to the old value. It also
updates the restart check to use IDPF_VPORT_UP instead of netif_running().
Cc: stable@vger.kernel.org
> diff --git a/drivers/net/ethernet/intel/idpf/xdp.c b/drivers/net/ethernet/intel/idpf/xdp.c
> --- a/drivers/net/ethernet/intel/idpf/xdp.c
> +++ b/drivers/net/ethernet/intel/idpf/xdp.c
> @@ -488,6 +488,7 @@ static int idpf_xdp_setup_prog(struct idpf_vport *vport,
> "Could not reopen the vport after XDP setup");
>
> cfg->user_config.xdp_prog = old;
> + vport->xdp_prog = old;
Does this also need to roll back vport->num_xdp_txq?
Because idpf_initiate_soft_reset() overwrites the vport struct with the new
queue configuration before failing, vport->num_xdp_txq might remain > 0
while vport->xdp_prog is restored to NULL.
When the interface is brought up, idpf_xdpsqs_get() evaluates
idpf_xdp_enabled(vport) as false and returns early without allocating the
NAPI timers (xdpsq->timer).
Could another interface redirect XDP frames via ndo_xdp_xmit, bypassing the
check because vport->num_xdp_txq > 0, and cause a NULL pointer dereference
in libeth_xdpsq_queue_timer() during idpf_xdp_tx_finalize()?
> old = prog;
> }
Is this old = prog assignment leading to a double-put of the BPF program?
If idpf_initiate_soft_reset() fails, this error path drops a reference to
the newly provided prog when it calls bpf_prog_put(old) right after this
block.
Since the function returns an error code to the core network stack, won't
dev_xdp_install() in net/core/dev.c also explicitly call bpf_prog_put(prog)
assuming ownership of the error cleanup?
Could this underflow the reference count and cause a use-after-free?
[ ... ]
> diff --git a/drivers/net/ethernet/intel/idpf/xsk.c b/drivers/net/ethernet/intel/idpf/xsk.c
> --- a/drivers/net/ethernet/intel/idpf/xsk.c
> +++ b/drivers/net/ethernet/intel/idpf/xsk.c
> @@ -568,7 +569,8 @@ int idpf_xsk_pool_setup(struct idpf_vport *vport, struct netdev_bpf *bpf)
> return -EINVAL;
> }
>
> - restart = idpf_xdp_enabled(vport) && netif_running(vport->netdev);
> + restart = idpf_xdp_enabled(vport) &&
> + test_bit(IDPF_VPORT_UP, np->state);
> if (!restart)
> goto pool;
Does this function leave the queue pair permanently disabled if the pool
setup fails?
If restart is true, the queue pair is disabled via:
idpf_qp_switch(vport, qid, false);
If the subsequent call to libeth_xsk_setup_pool() fails, the function
returns early:
ret = libeth_xsk_setup_pool(vport->netdev, qid, pool);
if (ret) {
...
return ret;
}
Does this early return bypass the idpf_qp_switch(vport, qid, true) call
expected later, causing a permanent partial loss of connectivity until the
interface is manually restarted?
^ permalink raw reply
* Re: [PATCH net 1/6] selftests: ovpn: add nftables config dependencies for test-mark
From: patchwork-bot+netdevbpf @ 2026-04-18 19:00 UTC (permalink / raw)
To: Antonio Quartulli
Cc: netdev, ralf, shuah, horms, sd, kuba, pabeni, andrew+netdev,
davem, edumazet
In-Reply-To: <20260417090305.2775723-2-antonio@openvpn.net>
Hello:
This series was applied to netdev/net.git (main)
by Antonio Quartulli <antonio@openvpn.net>:
On Fri, 17 Apr 2026 11:03:00 +0200 you wrote:
> From: Ralf Lici <ralf@mandelbit.com>
>
> test-mark.sh installs nftables rules in an inet/filter output chain and
> verifies packet drops via nft counters. In vmksft this can fail when the
> nftables core is not enabled by the ovpn selftest config.
>
> Add the missing kernel options required by this test:
> - CONFIG_NETFILTER
> - CONFIG_NF_TABLES
> - CONFIG_NF_TABLES_INET
>
> [...]
Here is the summary with links:
- [net,1/6] selftests: ovpn: add nftables config dependencies for test-mark
https://git.kernel.org/netdev/net/c/e5fd34ab8dff
- [net,2/6] selftests: ovpn: fail notification check on mismatch
https://git.kernel.org/netdev/net/c/c409da0fe15e
- [net,3/6] selftests: ovpn: flatten slurped notification JSON before filtering
https://git.kernel.org/netdev/net/c/222e7f8d1ca3
- [net,4/6] selftests: ovpn: add prefix to helpers and shared variables
https://git.kernel.org/netdev/net/c/7c29665a3a3c
- [net,5/6] selftests: ovpn: align command flow with TAP
https://git.kernel.org/netdev/net/c/1be93bb979ab
- [net,6/6] selftests: ovpn: serialize YNL listener startup
https://git.kernel.org/netdev/net/c/6c9b1dc218fe
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 1/2] net/mlx5e: psp: Fix invalid access on PSP dev registration fail
From: Jakub Kicinski @ 2026-04-18 19:08 UTC (permalink / raw)
To: tariqt
Cc: Jakub Kicinski, edumazet, pabeni, andrew+netdev, davem, borisp,
saeedm, leon, mbloch, daniel.zahka, willemdebruijn.kernel, cratiu,
raeds, rrameshbabu, dtatulea, kees, netdev, linux-rdma,
linux-kernel, gal
In-Reply-To: <20260417050201.192070-2-tariqt@nvidia.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net/mlx5e: psp: Fix invalid access on PSP dev registration fail
This commit updates PSP device registration to use a local variable,
only saving the PSP device pointer if psp_dev_create() succeeds. This
prevents an error pointer from being stored in priv->psp->psp.
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/psp.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/psp.c
[ ... ]
> @@ -1070,29 +1070,37 @@ static struct psp_dev_ops mlx5_psp_ops = {
[ ... ]
> void mlx5e_psp_register(struct mlx5e_priv *priv)
> {
> + struct mlx5e_psp *psp = priv->psp;
> + struct psp_dev *psd;
> +
[ ... ]
> - priv->psp->psp = psp_dev_create(priv->netdev, &mlx5_psp_ops,
> - &priv->psp->caps, NULL);
> - if (IS_ERR(priv->psp->psp))
> + psd = psp_dev_create(priv->netdev, &mlx5_psp_ops, &psp->caps, NULL);
> + if (IS_ERR(psd)) {
> mlx5_core_err(priv->mdev, "PSP failed to register due to %pe\n",
> - priv->psp->psp);
> + psd);
> + return;
> + }
> + psp->psp = psd;
> }
When psp_dev_create() fails, this function now returns without setting
psp->psp, leaving it as NULL. However, priv->psp remains allocated and
non-NULL.
Does this leave the RX datapath vulnerable to a NULL pointer dereference?
If priv->psp is non-NULL, the NIC RX initialization path can still call
mlx5_accel_psp_fs_init_rx_tables(), which creates hardware flow steering
rules to intercept UDP traffic.
If a UDP packet triggers these rules, the hardware flags the CQE with
MLX5E_PSP_MARKER_BIT. The RX fast-path sees the marker and invokes
mlx5e_psp_offload_handle_rx_skb(), which dereferences the pointer
unconditionally:
u16 dev_id = priv->psp->psp->id;
Since priv->psp->psp is NULL, this will cause a kernel panic. Should
priv->psp be cleaned up, or the error propagated, to prevent flow rules
from being installed when registration fails?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net v2 00/12] Intel Wired LAN Driver Updates 2026-04-14 (ice, i40e, iavf, idpf, e1000e)
From: patchwork-bot+netdevbpf @ 2026-04-18 19:10 UTC (permalink / raw)
To: Jacob Keller
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, netdev,
grzegorz.nitka, aleksandr.loktionov, horms, sx.rinitha,
zoltan.fodor, sunithax.d.mekala, lgs201920130244, stable,
mschmidt, paul.greenwalt, przemyslaw.kitszel, kmta1236, kohei,
poros, pmenzel, rafal.romanowski, emil.s.tantilov, patryk.holda,
tactii, avigailx.dahan
In-Reply-To: <20260416-iwl-net-submission-2026-04-14-v2-0-686c33c9828d@intel.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 17:53:24 -0700 you wrote:
> Grzegorz updates the logic for adjusting the PTP hardware clock on E830,
> fixing a bug that prevented adjustments below S32_MAX/MIN nanoseconds.
>
> Grzegorz and Zoli update the PCS latency settings for E825 devices at 10GbE
> and 25GbE, improving the accuracy of timestamps based on data from
> production hardware.
>
> [...]
Here is the summary with links:
- [net,v2,01/12] ice: fix 'adjust' timer programming for E830 devices
https://git.kernel.org/netdev/net/c/885c5e57924d
- [net,v2,02/12] ice: update PCS latency settings for E825 10G/25Gb modes
https://git.kernel.org/netdev/net/c/05567e405273
- [net,v2,03/12] ice: fix double free in ice_sf_eth_activate() error path
https://git.kernel.org/netdev/net/c/9aab1c3d7299
- [net,v2,04/12] ice: fix double-free of tx_buf skb
https://git.kernel.org/netdev/net/c/1a303baa715e
- [net,v2,05/12] ice: fix PHY config on media change with link-down-on-close
https://git.kernel.org/netdev/net/c/55e74f9ea7fe
- [net,v2,06/12] ice: fix ICE_AQ_LINK_SPEED_M for 200G
https://git.kernel.org/netdev/net/c/4a3a940059e9
- [net,v2,07/12] ice: fix race condition in TX timestamp ring cleanup
https://git.kernel.org/netdev/net/c/7c72ec18c2a4
- [net,v2,08/12] ice: fix potential NULL pointer deref in error path of ice_set_ringparam()
https://git.kernel.org/netdev/net/c/fa28351f970f
- [net,v2,09/12] i40e: don't advertise IFF_SUPP_NOFCS
https://git.kernel.org/netdev/net/c/a24162f18825
- [net,v2,10/12] iavf: fix wrong VLAN mask for legacy Rx descriptors L2TAG2
https://git.kernel.org/netdev/net/c/496d9f91062f
- [net,v2,11/12] idpf: fix xdp crash in soft reset error path
(no matching commit)
- [net,v2,12/12] e1000e: Unroll PTP in probe error handling
https://git.kernel.org/netdev/net/c/aa3f7fe40935
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [net,PATCH v4 1/2] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: patchwork-bot+netdevbpf @ 2026-04-18 19:20 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, bigeasy, stable, davem, andrew+netdev, edumazet, kuba, nb,
pabeni, ronald.wahl, yiconghui, linux-kernel
In-Reply-To: <20260415231020.455298-1-marex@nabladev.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 01:09:44 +0200 you wrote:
> If the driver executes ks8851_irq() AND a TX packet has been sent, then
> the driver enables TX queue via netif_wake_queue() which schedules TX
> softirq to queue packets for this device.
>
> If CONFIG_PREEMPT_RT=y is set AND a packet has also been received by
> the MAC, then ks8851_rx_pkts() calls netdev_alloc_skb_ip_align() to
> allocate SKBs for the received packets. If netdev_alloc_skb_ip_align()
> is called with BH enabled, then local_bh_enable() at the end of
> netdev_alloc_skb_ip_align() will trigger the pending softirq processing,
> which may ultimately call the .xmit callback ks8851_start_xmit_par().
> The ks8851_start_xmit_par() will try to lock struct ks8851_net_par
> .lock spinlock, which is already locked by ks8851_irq() from which
> ks8851_start_xmit_par() was called. This leads to a deadlock, which
> is reported by the kernel, including a trace listed below.
>
> [...]
Here is the summary with links:
- [net,v4,1/2] net: ks8851: Reinstate disabling of BHs around IRQ handler
https://git.kernel.org/netdev/net/c/5c9fcac3c872
- [net,v4,2/2] net: ks8851: Avoid excess softirq scheduling
https://git.kernel.org/netdev/net/c/22230e68b2cf
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net,v3 1/1] net: stmmac: Update default_an_inband before passing value to phylink_config
From: patchwork-bot+netdevbpf @ 2026-04-18 19:20 UTC (permalink / raw)
To: KhaiWenTan
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, netdev,
linux-stm32, linux-arm-kernel, linux-kernel, yoong.siang.song,
hong.aun.looi, khai.wen.tan
In-Reply-To: <20260416102609.7953-1-khai.wen.tan@intel.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 18:26:09 +0800 you wrote:
> From: KhaiWenTan <khai.wen.tan@linux.intel.com>
>
> get_interfaces() will update both the plat->phy_interfaces and
> mdio_bus_data->default_an_inband based on reading a SERDES register. As
> get_interfaces() will be called after default_an_inband had already been
> read, dwmac-intel regressed as a result with incorrect default_an_inband
> value in phylink_config.
>
> [...]
Here is the summary with links:
- [net,v3,1/1] net: stmmac: Update default_an_inband before passing value to phylink_config
https://git.kernel.org/netdev/net/c/8cff9dbe89d8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] ipv6: fix possible UAF in icmpv6_rcv()
From: patchwork-bot+netdevbpf @ 2026-04-18 19:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, dsahern, idosch, netdev, eric.dumazet
In-Reply-To: <20260416103505.2380753-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 16 Apr 2026 10:35:05 +0000 you wrote:
> Caching saddr and daddr before pskb_pull() is problematic
> since skb->head can change.
>
> Remove these temporary variables:
>
> - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr
> when net_dbg_ratelimited() is called in the slow path.
>
> [...]
Here is the summary with links:
- [net] ipv6: fix possible UAF in icmpv6_rcv()
https://git.kernel.org/netdev/net/c/f996edd7615e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v1 net] af_unix: Drop all SCM attributes for SOCKMAP.
From: patchwork-bot+netdevbpf @ 2026-04-18 19:20 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, edumazet, kuba, pabeni, horms, cong.wang, jiang.wang,
kuni1840, netdev, xingyuj
In-Reply-To: <20260415184830.3988432-1-kuniyu@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 15 Apr 2026 18:48:29 +0000 you wrote:
> SOCKMAP can hide inflight fd from AF_UNIX GC.
>
> When a socket in SOCKMAP receives skb with inflight fd,
> sk_psock_verdict_data_ready() looks up the mapped socket and
> enqueue skb to its psock->ingress_skb.
>
> Since neither the old nor the new GC can inspect the psock
> queue, the hidden skb leaks the inflight sockets. Note that
> this cannot be detected via kmemleak because inflight sockets
> are linked to a global list.
>
> [...]
Here is the summary with links:
- [v1,net] af_unix: Drop all SCM attributes for SOCKMAP.
https://git.kernel.org/netdev/net/c/965dc93481d1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX reference clock control for E825
From: Jakub Kicinski @ 2026-04-18 19:26 UTC (permalink / raw)
To: Kubalewski, Arkadiusz
Cc: Vecera, Ivan, vadim.fedorenko@linux.dev, edumazet@google.com,
netdev@vger.kernel.org, richardcochran@gmail.com,
donald.hunter@gmail.com, linux-kernel@vger.kernel.org,
davem@davemloft.net, Prathosh.Satish@microchip.com,
andrew+netdev@lunn.ch, intel-wired-lan@lists.osuosl.org,
horms@kernel.org, Kitszel, Przemyslaw, Nguyen, Anthony L,
pabeni@redhat.com, jiri@resnulli.us
In-Reply-To: <IA0PR11MB7378CF62D86454916AE8F9D79B202@IA0PR11MB7378.namprd11.prod.outlook.com>
On Fri, 17 Apr 2026 12:22:05 +0000 Kubalewski, Arkadiusz wrote:
> >> I was thinking that this is more like a purpose specific DPLL device, if
> >> someone would want something similar we would have to review it, right?
> >
> >We would if it was a Ethernet MAC PLL, but if someone wanted to expose
> >whether some random PLL in their ASIC locks - are we adding a new type
> >for each one of those?
>
> Yes, that was the implicit intention within those patches, if other purpose
> specific PLL would have to be present for whatever HW design and user
> control over it would be required, then that would be the easiest to
> maintain in the long term? Multiple types and each have own function/purpose.
>
> It would be good as long as there is one PLL for a function per board, once
> there could be multiple ones for single function, we would have to add some
> enumeration (labels, etc.)
Defer on adding identifiers. User knows which driver and bus device
spawned the pll and more importantly what the pin topology is.
Naming in the kernel is rarely a good idea.
> >> It depends, TX clock has one of external pins connected to external
> >> DPLL,
> >> but second is a board-level pin with ability to provide some external
> >> clock signal, the user would have to determine that purpose just based
> >> on the topology of one of the pins, which seems a bit problematic?
> >> I.e. if at some point there would be HW with only external non-DPLL
> >> connected pins?
> >
> >Not sure I follow, TBH. To me the function of the "MAC PLL" is fairly
> >obvious from the fact that it has a pin exposed via rtnetlink. So it's
> >obviously a DPLL which can drive the Tx clock?
>
> I am lost a bit now too. You mean clock recovery pin? And EEC type dpll?
> In this solution the 'MAC'/EEC is external and it doesn't drive TX clocks
> directly.
MAC == "tspll" == TXC in this series. On Grzegorz's diagram the new PLL
was in the MAC, which makes sense since it's a pll in the same ASIC as
the MAC.
I'm saying that the function of that pll is obvious since its pin will
plug into the netdev / rtnetlink.
> >It's the function / relation / linking to the EEC DPLL that may not
> >be obvious. But user can see how the pins connect they can get some
> >LLM to draw a diagram of a live system.. et voila :)
>
> Yes, correct it would work for this particular HW, but adding a variant
> without a external EEC-connected pin in the picture would be problematic
> to understand 'generic' dpll purpose, pointing to the labels later.
The function of the "MAC/tspll" is still obvious. The clarity of the
external PLL is not helped by naming the "MAC/tspll".
> Just to make it clear. I believe that generic type dpll could be used in
> any HW and for any purpose, so after all each such usage could possibly
> introduce entropy and confusion on the user side.
>
> But if you are fine with that, then sure, we can live with generic
> purpose dpll.
Considering all the imperfect options - generic / unnamed type would be
my preference.
^ permalink raw reply
* Re: [PATCH net v6 2/2] pppoe: drop PFC frames
From: Jakub Kicinski @ 2026-04-18 19:11 UTC (permalink / raw)
To: qingfang.deng
Cc: Jakub Kicinski, linux-ppp, andrew+netdev, davem, edumazet, pabeni,
hataegu0826, horms, kees, kuniyu, bigeasy, gnault, ericwouds,
semen.protsenko, netdev, linux-kernel, paulus, jaco, carlsonj,
wojciech.drewek, marcin.szycik
In-Reply-To: <20260415022456.141758-2-qingfang.deng@linux.dev>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
pppoe: drop PFC frames
This commit drops Protocol Field Compression (PFC) frames for PPPoE to avoid
unaligned access exceptions caused by the network header being shifted. A
helper function is introduced to identify compressed protocol fields.
> diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> --- a/drivers/net/ppp/pppoe.c
> +++ b/drivers/net/ppp/pppoe.c
[ ... ]
> @@ -434,6 +434,12 @@ static int pppoe_rcv(struct sk_buff *skb, struct net_device *dev,
> if (skb->len < len)
> goto drop;
>
> + /* skb->data points to the PPP protocol header after skb_pull_rcsum.
> + * Drop PFC frames.
> + */
> + if (ppp_skb_is_compressed_proto(skb))
Does this code safely access the PPP protocol byte?
After pulling the PPPoE header, skb->data points to the inner payload.
However, the new ppp_skb_is_compressed_proto() helper unconditionally
dereferences skb->data[0].
If a crafted PPPoE packet is received with an inner length of 0 and no
Ethernet padding, the linear buffer might end exactly after the PPPoE header.
In that scenario, this would read past the allocated linear buffer.
Even if the inner length is greater than 0, could the payload reside entirely
in non-linear paged fragments, causing an out-of-bounds read?
Would it be safer to verify the packet has at least 1 byte and use
pskb_may_pull() to ensure the protocol byte is in the linear region before
inspecting it, perhaps after the pskb_trim_rcsum() call?
> + goto drop;
> +
> if (pskb_trim_rcsum(skb, len))
> goto drop;
[ ... ]
> diff --git a/include/linux/ppp_defs.h b/include/linux/ppp_defs.h
> --- a/include/linux/ppp_defs.h
> +++ b/include/linux/ppp_defs.h
[ ... ]
> +static inline bool ppp_skb_is_compressed_proto(const struct sk_buff *skb)
> +{
> + return unlikely(skb->data[0] & 0x01);
> +}
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks
From: patchwork-bot+netdevbpf @ 2026-04-18 19:30 UTC (permalink / raw)
To: Michael Bommarito
Cc: linux-sctp, marcelo.leitner, lucien.xin, davem, edumazet, kuba,
pabeni, horms, netdev, linux-kernel, stable
In-Reply-To: <20260416031903.1447072-1-michael.bommarito@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 15 Apr 2026 23:19:03 -0400 you wrote:
> sctp_getsockopt_peer_auth_chunks() checks that the caller's optval
> buffer is large enough for the peer AUTH chunk list with
>
> if (len < num_chunks)
> return -EINVAL;
>
> but then writes num_chunks bytes to p->gauth_chunks, which lives
> at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8
> inside optval. The check is missing the sizeof(struct
> sctp_authchunks) = 8-byte header. When the caller supplies
> len == num_chunks (for any num_chunks > 0) the test passes but
> copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes
> past the declared buffer.
>
> [...]
Here is the summary with links:
- [net] sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks
https://git.kernel.org/netdev/net/c/0cf004ffb61c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH nf] netfilter: xt_TCPMSS: check skb_dst before path-MTU clamping
From: Florian Westphal @ 2026-04-18 19:58 UTC (permalink / raw)
To: Weiming Shi
Cc: Pablo Neira Ayuso, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Phil Sutter, Simon Horman, netfilter-devel, coreteam,
netdev, Xiang Mei
In-Reply-To: <20260418163057.2611503-2-bestswngs@gmail.com>
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.
But then all required compat info (xtables hints) is gone
and no longer available.
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.
*puke*
^ permalink raw reply
* [PATCH net v2] selftests: netfilter: conntrack_sctp_collision.sh: Introduce SCTP INIT collision test
From: Yi Chen @ 2026-04-18 19:58 UTC (permalink / raw)
To: Yi Chen, Pablo Neira Ayuso, Florian Westphal, Phil Sutter,
Long Xin, David S . Miller, Jakub Kicinski, Eric Dumazet,
Paolo Abeni, Simon Horman, Shuah Khan
Cc: coreteam, netfilter-devel, linux-kselftest, linux-kernel, netdev
The existing test covered a scenario where a delayed INIT_ACK chunk
updates the vtag in conntrack after the association has already been
established.
A similar issue can occur with a delayed SCTP INIT chunk.
Add a new simultaneous-open test case where the client's INIT is
delayed, allowing conntrack to establish the association based on
the server-initiated handshake.
When the stale INIT arrives later, it may get recorded and cause a
following INIT_ACK from the peer to be accepted instead of dropped.
This INIT_ACK overwrites the vtag in conntrack, causing subsequent
SCTP DATA chunks to be considered as invalid and then dropped by
nft rules matching on ct state invalid.
This test verifies such stale INIT chunks do not cause problems.
Signed-off-by: Yi Chen <yiche.cy@gmail.com>
Acked-by: Xin Long <lucien.xin@gmail.com>
---
v1 -> v2:
- Simplify conf_delay() by passing arguments.
- Avoid calling exit() inside the function.
- Enable nft log by setting net.netfilter.nf_log_all_netns=1.
- Add a description for the "ct invalid drop" rule match.
---
.../net/netfilter/conntrack_sctp_collision.sh | 85 ++++++++++++++-----
1 file changed, 63 insertions(+), 22 deletions(-)
diff --git a/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh b/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh
index d860f7d9744b..31823050391e 100755
--- a/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh
+++ b/tools/testing/selftests/net/netfilter/conntrack_sctp_collision.sh
@@ -2,18 +2,32 @@
# SPDX-License-Identifier: GPL-2.0
#
# Testing For SCTP COLLISION SCENARIO as Below:
-#
+# 1. Stale INIT_ACK capture:
# 14:35:47.655279 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT] [init tag: 2017837359]
# 14:35:48.353250 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT] [init tag: 1187206187]
# 14:35:48.353275 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT ACK] [init tag: 2017837359]
# 14:35:48.353283 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [COOKIE ECHO]
# 14:35:48.353977 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [COOKIE ACK]
# 14:35:48.855335 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT ACK] [init tag: 164579970]
+# (Delayed)
+#
+# 2. Stale INIT capture:
+# 14:35:48.353250 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT] [init tag: 1187206187]
+# 14:35:48.353275 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT ACK] [init tag: 2017837359]
+# 14:35:48.353283 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [COOKIE ECHO]
+# 14:35:48.353977 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [COOKIE ACK]
+# 14:35:47.655279 IP CLIENT_IP.PORT > SERVER_IP.PORT: sctp (1) [INIT] [init tag: 2017837359]
+# (Delayed)
+# 14:35:48.855335 IP SERVER_IP.PORT > CLIENT_IP.PORT: sctp (1) [INIT ACK] [init tag: 164579970]
#
# TOPO: SERVER_NS (link0)<--->(link1) ROUTER_NS (link2)<--->(link3) CLIENT_NS
source lib.sh
+checktool "nft --version" "run test without nft"
+checktool "tc -h" "run test without tc"
+checktool "modprobe -q sctp" "load sctp module"
+
CLIENT_IP="198.51.200.1"
CLIENT_PORT=1234
@@ -24,7 +38,8 @@ CLIENT_GW="198.51.200.2"
SERVER_GW="198.51.100.2"
# setup the topo
-setup() {
+topo_setup() {
+ # setup_ns cleans up existing net namespaces first.
setup_ns CLIENT_NS SERVER_NS ROUTER_NS
ip -n "$SERVER_NS" link add link0 type veth peer name link1 netns "$ROUTER_NS"
ip -n "$CLIENT_NS" link add link3 type veth peer name link2 netns "$ROUTER_NS"
@@ -38,35 +53,53 @@ setup() {
ip -n "$ROUTER_NS" addr add $SERVER_GW/24 dev link1
ip -n "$ROUTER_NS" addr add $CLIENT_GW/24 dev link2
ip net exec "$ROUTER_NS" sysctl -wq net.ipv4.ip_forward=1
+ sysctl -wq net.netfilter.nf_log_all_netns=1
ip -n "$CLIENT_NS" link set link3 up
ip -n "$CLIENT_NS" addr add $CLIENT_IP/24 dev link3
ip -n "$CLIENT_NS" route add $SERVER_IP dev link3 via $CLIENT_GW
+}
- # simulate the delay on OVS upcall by setting up a delay for INIT_ACK with
- # tc on $SERVER_NS side
- tc -n "$SERVER_NS" qdisc add dev link0 root handle 1: htb r2q 64
- tc -n "$SERVER_NS" class add dev link0 parent 1: classid 1:1 htb rate 100mbit
- tc -n "$SERVER_NS" filter add dev link0 parent 1: protocol ip u32 match ip protocol 132 \
- 0xff match u8 2 0xff at 32 flowid 1:1
- if ! tc -n "$SERVER_NS" qdisc add dev link0 parent 1:1 handle 10: netem delay 1200ms; then
+conf_delay()
+{
+ # simulate the delay on OVS upcall by setting up a delay for INIT_ACK/INIT with
+ local ns=$1
+ local link=$2
+ local chunk_type=$3
+
+ # use a smaller number for assoc's max_retrans to reproduce the issue
+ ip net exec "$CLIENT_NS" sysctl -wq net.sctp.association_max_retrans=3
+
+ tc -n "$ns" qdisc add dev "$link" root handle 1: htb r2q 64
+ tc -n "$ns" class add dev "$link" parent 1: classid 1:1 htb rate 100mbit
+ tc -n "$ns" filter add dev "$link" parent 1: protocol ip \
+ u32 match ip protocol 132 0xff match u8 "$chunk_type" 0xff at 32 flowid 1:1
+ if ! tc -n "$ns" qdisc add dev "$link" parent 1:1 handle 10: netem delay 1200ms; then
echo "SKIP: Cannot add netem qdisc"
- exit $ksft_skip
+ return $ksft_skip
fi
# simulate the ctstate check on OVS nf_conntrack
- ip net exec "$ROUTER_NS" iptables -A FORWARD -m state --state INVALID,UNTRACKED -j DROP
- ip net exec "$ROUTER_NS" iptables -A INPUT -p sctp -j DROP
-
- # use a smaller number for assoc's max_retrans to reproduce the issue
- modprobe -q sctp
- ip net exec "$CLIENT_NS" sysctl -wq net.sctp.association_max_retrans=3
+ ip net exec "$ROUTER_NS" nft -f - <<-EOF
+ table ip t {
+ chain forward {
+ type filter hook forward priority filter; policy accept;
+ meta l4proto icmp counter accept
+ ct state new counter accept
+ ct state established,related counter accept
+ ct state invalid log flags all counter drop comment \
+ "Expect to drop stale INIT/INIT_ACK chunks"
+ counter
+ }
+ }
+ EOF
+ return 0
}
cleanup() {
- ip net exec "$CLIENT_NS" pkill sctp_collision >/dev/null 2>&1
- ip net exec "$SERVER_NS" pkill sctp_collision >/dev/null 2>&1
+ # cleanup_all_ns terminates running processes in the namespaces.
cleanup_all_ns
+ sysctl -wq net.netfilter.nf_log_all_netns=0
}
do_test() {
@@ -81,7 +114,15 @@ do_test() {
# run the test case
trap cleanup EXIT
-setup && \
-echo "Test for SCTP Collision in nf_conntrack:" && \
-do_test && echo "PASS!"
-exit $?
+
+echo "Test for SCTP INIT_ACK Collision in nf_conntrack:"
+(topo_setup && conf_delay $SERVER_NS link0 2) || exit $?
+if ! do_test; then
+ exit $ksft_fail
+fi
+
+echo "Test for SCTP INIT Collision in nf_conntrack:"
+(topo_setup && conf_delay $CLIENT_NS link3 1) || exit $?
+if ! do_test; then
+ exit $ksft_fail
+fi
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net] net/packet: fix TOCTOU race on mmap'd vnet_hdr in tpacket_snd()
From: Willem de Bruijn @ 2026-04-18 20:17 UTC (permalink / raw)
To: Bingquan Chen, Willem de Bruijn, Greg KH
Cc: Stephen Hemminger, security, David S . Miller, Jakub Kicinski,
Eric Dumazet, netdev, Bingquan Chen
In-Reply-To: <20260418112006.78823-1-patzilla007@gmail.com>
Bingquan Chen wrote:
> In tpacket_snd(), when PACKET_VNET_HDR is enabled, vnet_hdr points
> directly into the mmap'd TX ring buffer shared with userspace. The
> kernel validates the header via __packet_snd_vnet_parse() but then
> re-reads all fields later in virtio_net_hdr_to_skb(). A concurrent
> userspace thread can modify the vnet_hdr fields between validation
> and use, bypassing all safety checks.
>
> The non-TPACKET path (packet_snd()) already correctly copies vnet_hdr
> to a stack-local variable. All other vnet_hdr consumers in the kernel
> (tun.c, tap.c, virtio_net.c) also use stack copies. The TPACKET TX
> path is the only caller of virtio_net_hdr_to_skb() that reads directly
> from user-controlled shared memory.
>
> Fix this by copying vnet_hdr from the mmap'd ring buffer to a
> stack-local variable before validation and use, consistent with the
> approach used in packet_snd() and all other callers.
>
> Fixes: 1d036d25e560 ("packet: tpacket_snd gso and checksum offload")
> Signed-off-by: Bingquan Chen <patzilla007@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH net v2] ipv6: Apply max_dst_opts_cnt to ip6_tnl_parse_tlv_enc_lim
From: Daniel Borkmann @ 2026-04-18 22:19 UTC (permalink / raw)
To: Justin Iurman, kuba
Cc: edumazet, dsahern, tom, willemdebruijn.kernel, idosch, pabeni,
netdev
In-Reply-To: <7c715640-5c20-4226-9c31-d2c5eef551db@gmail.com>
On 4/18/26 2:40 PM, Justin Iurman wrote:
> On 4/18/26 14:15, Daniel Borkmann wrote:
>> Commit 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and
>> Destination options") added net.ipv6.max_{hbh,dst}_opts_{cnt,len}
>> and applied them in ip6_parse_tlv(), the generic TLV walker
>> invoked from ipv6_destopt_rcv() and ipv6_parse_hopopts().
>>
>> ip6_tnl_parse_tlv_enc_lim() does not go through ip6_parse_tlv();
>> it has its own hand-rolled TLV scanner inside its NEXTHDR_DEST
>> branch which looks for IPV6_TLV_TNL_ENCAP_LIMIT. That inner
>> loop is bounded only by optlen, which can be up to 2048 bytes.
>> Stuffing the Destination Options header with 2046 Pad1 (type=0)
>> entries advances the scanner a single byte at a time, yielding
>> ~2000 TLV iterations per extension header.
>>
>> Reuse max_dst_opts_cnt to bound the TLV iterations, matching
>> the semantics from 47d3d7ac656a.
>>
>> Fixes: 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and Destination options")
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>> ---
>> v1->v2:
>> - Remove unlikely (Justin)
>> - Use abs() given max_dst_opts_cnt's negative meaning (Justin)
>>
>> net/ipv6/ip6_tunnel.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
>> index 907c6a2af331..0f50b7fcb24e 100644
>> --- a/net/ipv6/ip6_tunnel.c
>> +++ b/net/ipv6/ip6_tunnel.c
>> @@ -430,11 +430,16 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff *skb, __u8 *raw)
>> break;
>> }
>> if (nexthdr == NEXTHDR_DEST) {
>> + int tlv_max = abs(READ_ONCE(init_net.ipv6.sysctl.max_dst_opts_cnt));
>> + int tlv_cnt = 0;
>> u16 i = 2;
>> while (1) {
>> struct ipv6_tlv_tnl_enc_lim *tel;
>> + if (tlv_cnt++ >= tlv_max)
>> + break;
>> +
>> /* No more room for encapsulation limit */
>> if (i + sizeof(*tel) > optlen)
>> break;
>
> Thanks for v2, Daniel.
>
> I'm still wondering: should we align the above parsing behavior with the one in ip6_parse_tlv() to keep things consistent? That is: don't increment tlv_cnt for Pad1/PadN, make sure we don't exceed 8 bytes per padding (consecutive Pad1's, or a PadN), and we could also check that a PadN payload is only made of zeroes. Open question...
Hm, so it would be sth like the below on top of this one, I'd wish we wouldn't
have to open code another ip6_parse_tlv().
Have you seen such cases with the encap limit in the wild (vs encap limit as
first tlv) where a stack places leading Pad1/PadN before encap limit which the
v2 patch wouldn't catch?
net/ipv6/ip6_tunnel.c | 42 +++++++++++++++++++++++++++++++-----------
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 0f50b7fcb24e..1fa42a1cd97c 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -432,28 +432,48 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff *skb, __u8 *raw)
if (nexthdr == NEXTHDR_DEST) {
int tlv_max = abs(READ_ONCE(init_net.ipv6.sysctl.max_dst_opts_cnt));
int tlv_cnt = 0;
+ int padlen = 0;
u16 i = 2;
- while (1) {
- struct ipv6_tlv_tnl_enc_lim *tel;
+ while (i < optlen) {
+ struct ipv6_tlv_tnl_enc_lim *tel =
+ (struct ipv6_tlv_tnl_enc_lim *)(skb->data + off + i);
+ int tel_len;
- if (tlv_cnt++ >= tlv_max)
+ if (tel->type == IPV6_TLV_PAD1) {
+ if (++padlen > 7)
+ break;
+ i++;
+ continue;
+ }
+
+ if (i + 2 > optlen)
+ break;
+ tel_len = tel->length + 2;
+ if (i + tel_len > optlen)
break;
- /* No more room for encapsulation limit */
- if (i + sizeof(*tel) > optlen)
+ if (tel->type == IPV6_TLV_PADN) {
+ padlen += tel_len;
+ if (padlen > 7)
+ break;
+ if (memchr_inv((u8 *)tel + 2, 0,
+ tel->length))
+ break;
+ i += tel_len;
+ continue;
+ }
+ padlen = 0;
+
+ if (tlv_cnt++ >= tlv_max)
break;
- tel = (struct ipv6_tlv_tnl_enc_lim *)(skb->data + off + i);
/* return index of option if found and valid */
if (tel->type == IPV6_TLV_TNL_ENCAP_LIMIT &&
tel->length == 1)
return i + off - nhoff;
- /* else jump to next option */
- if (tel->type)
- i += tel->length + 2;
- else
- i++;
+
+ i += tel_len;
}
}
nexthdr = hdr->nexthdr;
--
2.43.0
> Otherwise, LGTM:
> Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
Thanks,
Daniel
^ permalink raw reply related
* Re: [PATCH net v2] ipv6: Apply max_dst_opts_cnt to ip6_tnl_parse_tlv_enc_lim
From: Justin Iurman @ 2026-04-18 22:37 UTC (permalink / raw)
To: Daniel Borkmann, kuba
Cc: edumazet, dsahern, tom, willemdebruijn.kernel, idosch, pabeni,
netdev
In-Reply-To: <d8d60970-6f73-4b9d-8808-76f4f8023100@iogearbox.net>
On 4/19/26 00:19, Daniel Borkmann wrote:
> On 4/18/26 2:40 PM, Justin Iurman wrote:
>> On 4/18/26 14:15, Daniel Borkmann wrote:
>>> Commit 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and
>>> Destination options") added net.ipv6.max_{hbh,dst}_opts_{cnt,len}
>>> and applied them in ip6_parse_tlv(), the generic TLV walker
>>> invoked from ipv6_destopt_rcv() and ipv6_parse_hopopts().
>>>
>>> ip6_tnl_parse_tlv_enc_lim() does not go through ip6_parse_tlv();
>>> it has its own hand-rolled TLV scanner inside its NEXTHDR_DEST
>>> branch which looks for IPV6_TLV_TNL_ENCAP_LIMIT. That inner
>>> loop is bounded only by optlen, which can be up to 2048 bytes.
>>> Stuffing the Destination Options header with 2046 Pad1 (type=0)
>>> entries advances the scanner a single byte at a time, yielding
>>> ~2000 TLV iterations per extension header.
>>>
>>> Reuse max_dst_opts_cnt to bound the TLV iterations, matching
>>> the semantics from 47d3d7ac656a.
>>>
>>> Fixes: 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and
>>> Destination options")
>>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>>> ---
>>> v1->v2:
>>> - Remove unlikely (Justin)
>>> - Use abs() given max_dst_opts_cnt's negative meaning (Justin)
>>>
>>> net/ipv6/ip6_tunnel.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
>>> index 907c6a2af331..0f50b7fcb24e 100644
>>> --- a/net/ipv6/ip6_tunnel.c
>>> +++ b/net/ipv6/ip6_tunnel.c
>>> @@ -430,11 +430,16 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff
>>> *skb, __u8 *raw)
>>> break;
>>> }
>>> if (nexthdr == NEXTHDR_DEST) {
>>> + int tlv_max =
>>> abs(READ_ONCE(init_net.ipv6.sysctl.max_dst_opts_cnt));
>>> + int tlv_cnt = 0;
>>> u16 i = 2;
>>> while (1) {
>>> struct ipv6_tlv_tnl_enc_lim *tel;
>>> + if (tlv_cnt++ >= tlv_max)
>>> + break;
>>> +
>>> /* No more room for encapsulation limit */
>>> if (i + sizeof(*tel) > optlen)
>>> break;
>>
>> Thanks for v2, Daniel.
>>
>> I'm still wondering: should we align the above parsing behavior with
>> the one in ip6_parse_tlv() to keep things consistent? That is: don't
>> increment tlv_cnt for Pad1/PadN, make sure we don't exceed 8 bytes per
>> padding (consecutive Pad1's, or a PadN), and we could also check that
>> a PadN payload is only made of zeroes. Open question...
>
> Hm, so it would be sth like the below on top of this one, I'd wish we
> wouldn't
> have to open code another ip6_parse_tlv().
>
> Have you seen such cases with the encap limit in the wild (vs encap
> limit as
> first tlv) where a stack places leading Pad1/PadN before encap limit
> which the
> v2 patch wouldn't catch?
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.
> net/ipv6/ip6_tunnel.c | 42 +++++++++++++++++++++++++++++++-----------
> 1 file changed, 31 insertions(+), 11 deletions(-)
>
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index 0f50b7fcb24e..1fa42a1cd97c 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -432,28 +432,48 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff
> *skb, __u8 *raw)
> if (nexthdr == NEXTHDR_DEST) {
> int tlv_max =
> abs(READ_ONCE(init_net.ipv6.sysctl.max_dst_opts_cnt));
> int tlv_cnt = 0;
> + int padlen = 0;
> u16 i = 2;
>
> - while (1) {
> - struct ipv6_tlv_tnl_enc_lim *tel;
> + while (i < optlen) {
> + struct ipv6_tlv_tnl_enc_lim *tel =
> + (struct ipv6_tlv_tnl_enc_lim *)(skb->data + off + i);
> + int tel_len;
>
> - if (tlv_cnt++ >= tlv_max)
> + if (tel->type == IPV6_TLV_PAD1) {
> + if (++padlen > 7)
> + break;
> + i++;
> + continue;
> + }
> +
> + if (i + 2 > optlen)
> + break;
> + tel_len = tel->length + 2;
> + if (i + tel_len > optlen)
> break;
>
> - /* No more room for encapsulation limit */
> - if (i + sizeof(*tel) > optlen)
> + if (tel->type == IPV6_TLV_PADN) {
> + padlen += tel_len;
> + if (padlen > 7)
> + break;
> + if (memchr_inv((u8 *)tel + 2, 0,
> + tel->length))
> + break;
> + i += tel_len;
> + continue;
> + }
> + padlen = 0;
> +
> + if (tlv_cnt++ >= tlv_max)
> break;
>
> - tel = (struct ipv6_tlv_tnl_enc_lim *)(skb->data + off +
> i);
> /* return index of option if found and valid */
> if (tel->type == IPV6_TLV_TNL_ENCAP_LIMIT &&
> tel->length == 1)
> return i + off - nhoff;
> - /* else jump to next option */
> - if (tel->type)
> - i += tel->length + 2;
> - else
> - i++;
> +
> + i += tel_len;
> }
> }
> nexthdr = hdr->nexthdr;
^ permalink raw reply
* Re: [PATCH v2 00/19] tracepoint: Avoid double static_branch evaluation at guarded call sites
From: Steven Rostedt @ 2026-04-18 23:04 UTC (permalink / raw)
To: Vineeth Pillai (Google)
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: <20260323160052.17528-1-vineeth@bitbyteword.org>
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.
Thanks,
-- Steve
^ permalink raw reply
* Re: [RFC PATCH 1/2] kernel/notifier: replace single-linked list with double-linked list for reverse traversal
From: Song Chen @ 2026-04-19 0:07 UTC (permalink / raw)
To: Petr Mladek
Cc: rafael, lenb, mturquette, sboyd, viresh.kumar, agk, snitzer,
mpatocka, bmarzins, song, yukuai, linan122, jason.wessel, danielt,
dianders, horms, davem, edumazet, kuba, pabeni, paulmck, frederic,
mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin, jpoimboe,
jikos, mbenes, joe.lawrence, rostedt, mhiramat, mark.rutland,
mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <aeC7ByGA5MHBcGQR@pathway.suse.cz>
Hi,
On 4/16/26 18:33, Petr Mladek wrote:
> On Wed 2026-04-15 15:01:37, chensong_2000@189.cn wrote:
>> From: Song Chen <chensong_2000@189.cn>
>>
>> The current notifier chain implementation uses a single-linked list
>> (struct notifier_block *next), which only supports forward traversal
>> in priority order. This makes it difficult to handle cleanup/teardown
>> scenarios that require notifiers to be called in reverse priority order.
>>
>> A concrete example is the ordering dependency between ftrace and
>> livepatch during module load/unload. see the detail here [1].
>>
>> This patch replaces the single-linked list in struct notifier_block
>> with a struct list_head, converting the notifier chain into a
>> doubly-linked list sorted in descending priority order. Based on
>> this, a new function notifier_call_chain_reverse() is introduced,
>> which traverses the chain in reverse (ascending priority order).
>> The corresponding blocking_notifier_call_chain_reverse() is also
>> added as the locking wrapper for blocking notifier chains.
>>
>> The internal notifier_call_chain_robust() is updated to use
>> notifier_call_chain_reverse() for rollback: on error, it records
>> the failing notifier (last_nb) and the count of successfully called
>> notifiers (nr), then rolls back exactly those nr-1 notifiers in
>> reverse order starting from last_nb's predecessor, without needing
>> to know the total length of the chain.
>>
>> With this change, subsystems with symmetric setup/teardown ordering
>> requirements can register a single notifier_block with one priority
>> value, and rely on blocking_notifier_call_chain() for forward
>> traversal and blocking_notifier_call_chain_reverse() for reverse
>> traversal, without needing hard-coded call sequences or separate
>> notifier registrations for each direction.
>>
>> [1]:https://lore.kernel.org/all
>> /alpine.LNX.2.00.1602172216491.22700@cbobk.fhfr.pm/
>>
>> --- a/include/linux/notifier.h
>> +++ b/include/linux/notifier.h
>> @@ -53,41 +53,41 @@ typedef int (*notifier_fn_t)(struct notifier_block *nb,
> [...]
>> struct notifier_block {
>> notifier_fn_t notifier_call;
>> - struct notifier_block __rcu *next;
>> + struct list_head __rcu entry;
>> int priority;
>> };
> [...]
>> #define ATOMIC_INIT_NOTIFIER_HEAD(name) do { \
>> spin_lock_init(&(name)->lock); \
>> - (name)->head = NULL; \
>> + INIT_LIST_HEAD(&(name)->head); \
>
> I would expect the RCU variant here, aka INIT_LIST_HEAD_RCU().
I'm not familiar with list rcu, but i will look into it and give it a try.
>
>> --- a/kernel/notifier.c
>> +++ b/kernel/notifier.c
>> @@ -14,39 +14,47 @@
>> * are layered on top of these, with appropriate locking added.
>> */
>>
>> -static int notifier_chain_register(struct notifier_block **nl,
>> +static int notifier_chain_register(struct list_head *nl,
>> struct notifier_block *n,
>> bool unique_priority)
>> {
>> - while ((*nl) != NULL) {
>> - if (unlikely((*nl) == n)) {
>> + struct notifier_block *cur;
>> +
>> + list_for_each_entry(cur, nl, entry) {
>> + if (unlikely(cur == n)) {
>> WARN(1, "notifier callback %ps already registered",
>> n->notifier_call);
>> return -EEXIST;
>> }
>> - if (n->priority > (*nl)->priority)
>> - break;
>> - if (n->priority == (*nl)->priority && unique_priority)
>> +
>> + if (n->priority == cur->priority && unique_priority)
>> return -EBUSY;
>> - nl = &((*nl)->next);
>> +
>> + if (n->priority > cur->priority) {
>> + list_add_tail(&n->entry, &cur->entry);
>> + goto out;
>> + }
>> }
>> - n->next = *nl;
>> - rcu_assign_pointer(*nl, n);
>> +
>> + list_add_tail(&n->entry, nl);
>
> I would expect list_add_tail_rcu() here.
>
>> @@ -59,25 +67,25 @@ static int notifier_chain_unregister(struct notifier_block **nl,
>> * value of this parameter is -1.
>> * @nr_calls: Records the number of notifications sent. Don't care
>> * value of this field is NULL.
>> + * @last_nb: Records the last called notifier block for rolling back
>> * Return: notifier_call_chain returns the value returned by the
>> * last notifier function called.
>> */
>> -static int notifier_call_chain(struct notifier_block **nl,
>> +static int notifier_call_chain(struct list_head *nl,
>> unsigned long val, void *v,
>> - int nr_to_call, int *nr_calls)
>> + int nr_to_call, int *nr_calls,
>> + struct notifier_block **last_nb)
>> {
>> int ret = NOTIFY_DONE;
>> - struct notifier_block *nb, *next_nb;
>> -
>> - nb = rcu_dereference_raw(*nl);
>> + struct notifier_block *nb;
>>
>> - while (nb && nr_to_call) {
>> - next_nb = rcu_dereference_raw(nb->next);
>> + if (!nr_to_call)
>> + return ret;
>>
>> + list_for_each_entry(nb, nl, entry) {
>
> I would expect the RCU variant here, aka list_for_each_rcu()
>
> These are just two random examples which I found by a quick look.
>
> I guess that the notifier API is very old and it does not use all
> the RCU API features which allow to track safety when
> CONFIG_PROVE_RCU and CONFIG_PROVE_RCU_LIST are enabled.
>
> It actually might be worth to audit the code and make it right.
>
>> #ifdef CONFIG_DEBUG_NOTIFIERS
>> if (unlikely(!func_ptr_is_kernel_text(nb->notifier_call))) {
>> WARN(1, "Invalid notifier called!");
>> - nb = next_nb;
>> continue;
>> }
>> #endif
>
> That said, I am not sure if the ftrace/livepatching handlers are
> the right motivation for this. Especially when I see the
> complexity of the 2nd patch [*]
>
> After thinking more about it. I am not even sure that the ftrace and
> livepatching callbacks are good candidates for generic notifiers.
> They are too special. It is not only about ordering them against
> each other. But it is also about ordering them against other
> notifiers. The ftrace/livepatching callbacks must be the first/last
> during module load/release.
>
> [*] The 2nd patch is not archived by lore for some reason.
> I have found only a review but it gives a good picture, see
> https://lore.kernel.org/all/1191caf5-6a61-4622-a15e-854d3701f4fc@suse.com/
>
> Best Regards,
> Petr
>
Thanks.
BR
Song
^ permalink raw reply
* Re: [RFC PATCH 1/2] kernel/notifier: replace single-linked list with double-linked list for reverse traversal
From: Song Chen @ 2026-04-19 0:21 UTC (permalink / raw)
To: David Laight
Cc: rafael, lenb, mturquette, sboyd, viresh.kumar, agk, snitzer,
mpatocka, bmarzins, song, yukuai, linan122, jason.wessel, danielt,
dianders, horms, davem, edumazet, kuba, pabeni, paulmck, frederic,
mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin, jpoimboe,
jikos, mbenes, pmladek, joe.lawrence, rostedt, mhiramat,
mark.rutland, mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <20260416133004.07bd2886@pumpkin>
Hi,
On 4/16/26 20:30, David Laight wrote:
> On Wed, 15 Apr 2026 15:01:37 +0800
> chensong_2000@189.cn wrote:
>
>> From: Song Chen <chensong_2000@189.cn>
>>
>> The current notifier chain implementation uses a single-linked list
>> (struct notifier_block *next), which only supports forward traversal
>> in priority order. This makes it difficult to handle cleanup/teardown
>> scenarios that require notifiers to be called in reverse priority order.
>
> If it is only cleanup/teardown then the list can be order-reversed
> as part of that process at the same time as the list is deleted.
>
> David
>
>
>
Sorry, i don't follow, the notifiers in the list are deleted when
calling notifier_chain_unregister, other than that, they are traversed
forward and backward.
Song
^ permalink raw reply
* Re: [PATCH v2 0/3] mISDN: fix socket/device lifetime and naming races
From: Shuvam Pandey @ 2026-04-19 0:24 UTC (permalink / raw)
To: netdev
In-Reply-To: <cover.1776446840.git.shuvampandey1@gmail.com>
While re-reviewing v2, I found correctness issues in the current approach,
including lifetime and synchronization problems.
Please ignore v2 for now. I’m reworking the series and will send a
corrected v3.
Thanks,
Shuvam
^ permalink raw reply
* Re: [PATCH net 1/1] net: l3mdev: Ignore non-L3 uppers in l3mdev_fib_table_rcu
From: Haoze Xie @ 2026-04-19 3:45 UTC (permalink / raw)
To: Ido Schimmel, Ao Zhou
Cc: netdev, David Ahern, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Yifan Wu, Juefei Pu,
Yuan Tan, Xin Liu
In-Reply-To: <20260406103350.GA654671@shredder>
On 4/6/2026 6:33 PM, Ido Schimmel wrote:
> On Sat, Apr 04, 2026 at 07:52:03PM +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.
>
> Do you have a reproducer? I don't see how that can happen.
>
> do_set_master() ensures that the device doesn't have a master when
> ndo_add_slave() is called. Meaning, if netif_is_l3_slave() is true and
> netdev_master_upper_dev_get_rcu() resolved a master device, it's
> guaranteed to be a VRF.
>
I agree that this is correct in the synchronous `do_set_master()`
control flow.
My concern is narrower: an RCU reader can still resolve a stale upper
after the unlink, so `netif_is_l3_slave(dev)` alone is not enough to
prove that the resolved upper is still an L3 master at the point where
`master->l3mdev_ops` is dereferenced.
>>
>> Fixes: fee6d4c777a1 ("net: Add netif_is_l3_slave")
>> 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>
>> Signed-off-by: Haoze Xie <royenheart@gmail.com>
>> Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
>> ---
>> 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)
>> tb_id = master->l3mdev_ops->l3mdev_fib_table(master);
>> }
>> --
>> 2.53.0
>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox