* [PATCH bpf v4 3/4] selftests/bpf: Adapt sockmap update error handling
From: Michal Luczaj @ 2026-07-07 4:23 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Martin KaFai Lau,
Song Liu, Yonghong Song, Jiri Olsa, Emil Tsalapatis, Shuah Khan,
John Fastabend, Jakub Sitnicki, Jiayuan Chen, Eric Dumazet,
Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn, David S. Miller,
Jakub Kicinski, Simon Horman, Cong Wang
Cc: Michal Luczaj, bpf, linux-kselftest, linux-kernel, netdev
In-Reply-To: <20260707-sockmap-lookup-udp-leak-v4-0-f878346f27ab@rbox.co>
Update sockmap_listen to accommodate the recent change in sockmap that
rejects unbound UDP sockets.
TCP: Reject unbound and bound (unless established or listening).
UDP: Accept only bound sockets.
While at it, migrate to ASSERT_* and enforce reverse xmas tree.
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Signed-off-by: Michal Luczaj <mhal@rbox.co>
---
.../selftests/bpf/prog_tests/sockmap_listen.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c b/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c
index cc0c68bab907..1c96a3cf4b97 100644
--- a/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c
+++ b/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c
@@ -53,8 +53,8 @@ static void test_insert_opened(struct test_sockmap_listen *skel __always_unused,
int family, int sotype, int mapfd)
{
u32 key = 0;
- u64 value;
int err, s;
+ u64 value;
s = xsocket(family, sotype, 0);
if (s == -1)
@@ -63,11 +63,8 @@ static void test_insert_opened(struct test_sockmap_listen *skel __always_unused,
errno = 0;
value = s;
err = bpf_map_update_elem(mapfd, &key, &value, BPF_NOEXIST);
- if (sotype == SOCK_STREAM) {
- if (!err || errno != EOPNOTSUPP)
- FAIL_ERRNO("map_update: expected EOPNOTSUPP");
- } else if (err)
- FAIL_ERRNO("map_update: expected success");
+ ASSERT_ERR(err, "map_update");
+ ASSERT_EQ(errno, EOPNOTSUPP, "errno");
xclose(s);
}
@@ -77,8 +74,8 @@ static void test_insert_bound(struct test_sockmap_listen *skel __always_unused,
struct sockaddr_storage addr;
socklen_t len = 0;
u32 key = 0;
- u64 value;
int err, s;
+ u64 value;
init_addr_loopback(family, &addr, &len);
@@ -93,8 +90,12 @@ static void test_insert_bound(struct test_sockmap_listen *skel __always_unused,
errno = 0;
value = s;
err = bpf_map_update_elem(mapfd, &key, &value, BPF_NOEXIST);
- if (!err || errno != EOPNOTSUPP)
- FAIL_ERRNO("map_update: expected EOPNOTSUPP");
+ if (sotype == SOCK_STREAM) {
+ ASSERT_ERR(err, "map_update");
+ ASSERT_EQ(errno, EOPNOTSUPP, "errno");
+ } else {
+ ASSERT_OK(err, "map_update");
+ }
close:
xclose(s);
}
@@ -1289,7 +1290,7 @@ static void test_ops(struct test_sockmap_listen *skel, struct bpf_map *map,
/* insert */
TEST(test_insert_invalid),
TEST(test_insert_opened),
- TEST(test_insert_bound, SOCK_STREAM),
+ TEST(test_insert_bound),
TEST(test_insert),
/* delete */
TEST(test_delete_after_insert),
--
2.55.0
^ permalink raw reply related
* [PATCH bpf v4 2/4] bpf, sockmap: Reject unhashed UDP sockets on sockmap update
From: Michal Luczaj @ 2026-07-07 4:23 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Martin KaFai Lau,
Song Liu, Yonghong Song, Jiri Olsa, Emil Tsalapatis, Shuah Khan,
John Fastabend, Jakub Sitnicki, Jiayuan Chen, Eric Dumazet,
Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn, David S. Miller,
Jakub Kicinski, Simon Horman, Cong Wang
Cc: Michal Luczaj, bpf, linux-kselftest, linux-kernel, netdev
In-Reply-To: <20260707-sockmap-lookup-udp-leak-v4-0-f878346f27ab@rbox.co>
UDP sockets get SOCK_RCU_FREE set when (auto-)bound. This means
sk_is_refcounted(unbound) = true, while sk_is_refcounted(bound) = false.
Because sockmap accepts unbound UDP sockets, a BPF program can increment a
socket's refcount via lookup. If the socket is subsequently bound, the
transition from unbound to bound causes bpf_sk_release() to skip the
decrement of the refcount, causing a memory leak.
unreferenced object 0xffff88810bc2eb40 (size 1984):
comm "test_progs", pid 2451, jiffies 4295320596
hex dump (first 32 bytes):
7f 00 00 01 7f 00 00 01 d2 04 1b b7 04 d2 00 00 ................
02 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace (crc bdee079d):
kmem_cache_alloc_noprof+0x557/0x660
sk_prot_alloc+0x69/0x240
sk_alloc+0x30/0x460
inet_create+0x2ce/0xf80
__sock_create+0x25b/0x5c0
__sys_socket+0x119/0x1d0
__x64_sys_socket+0x72/0xd0
do_syscall_64+0xa1/0x5f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Instead of special-casing for refcounted sockets, reject unhashed UDP
sockets during sockmap updates, as there is no benefit to supporting those.
This effectively reverts the commit under Fixes, with two exceptions:
1. sock_map_sk_state_allowed() maintains a fall-through `return true`.
2. In the spirit of commit b8b8315e39ff ("bpf, sockmap: Remove unhash
handler for BPF sockmap usage"), the proto::unhash BPF handler is not
reintroduced.
Historical note: this issue is related to commit 67312adc96b5 ("bpf: reject
unhashed sockets in bpf_sk_assign").
Fixes: 0c48eefae712 ("sock_map: Lift socket state restriction for datagram sockets")
Suggested-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Michal Luczaj <mhal@rbox.co>
---
net/core/sock_map.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/core/sock_map.c b/net/core/sock_map.c
index c60ba6d292f9..9efbd8ca7db8 100644
--- a/net/core/sock_map.c
+++ b/net/core/sock_map.c
@@ -542,6 +542,8 @@ static bool sock_map_sk_state_allowed(const struct sock *sk)
{
if (sk_is_tcp(sk))
return (1 << sk->sk_state) & (TCPF_ESTABLISHED | TCPF_LISTEN);
+ if (sk_is_udp(sk))
+ return sk_hashed(sk);
if (sk_is_stream_unix(sk))
return (1 << READ_ONCE(sk->sk_state)) & TCPF_ESTABLISHED;
if (sk_is_vsock(sk) &&
--
2.55.0
^ permalink raw reply related
* Re: [PATCH net] net/smc: ignore peer-supplied rmbe_idx and dmbe_idx
From: Dust Li @ 2026-07-07 3:56 UTC (permalink / raw)
To: D. Wythe, Sidraya Jayagond, Wenjia Zhang, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Mahanta Jambigi, Tony Lu, Wen Gu, Simon Horman, Ursula Braun,
Hans Wippel, linux-rdma, linux-s390, netdev, linux-kernel, stable
In-Reply-To: <20260702171137.1099051-2-dust.li@linux.alibaba.com>
On 2026-07-03 01:11:38, Dust Li wrote:
>Linux always uses exactly one RMBE per RMB (index 1 for SMC-R) and
>one DMBE per DMB (index 0 for SMC-D), so conn->tx_off is always zero.
>Hardcode these fixed values instead of deriving tx_off from the
>peer-supplied rmbe_idx / dmbe_idx in the CLC Accept/Confirm message.
>
>Fixes: e6727f39004b ("smc: send data (through RDMA)")
>Fixes: 413498440e30 ("net/smc: add SMC-D support in af_smc")
>Cc: stable@vger.kernel.org
>Reported-by: Federico Kirschbaum <federico.kirschbaum@xbow.com>
>Signed-off-by: Dust Li <dust.li@linux.alibaba.com>
>---
> net/smc/af_smc.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
>diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
>index b5db69073e20..3706e8ac49e0 100644
>--- a/net/smc/af_smc.c
>+++ b/net/smc/af_smc.c
>@@ -729,11 +729,15 @@ static void smcr_conn_save_peer_info(struct smc_sock *smc,
> {
> int bufsize = smc_uncompress_bufsize(clc->r0.rmbe_size);
>
>- smc->conn.peer_rmbe_idx = clc->r0.rmbe_idx;
>+ /* Linux uses exactly one RMBE per RMB (always index 1); ignore the
>+ * peer-supplied rmbe_idx to prevent a malicious peer from setting an
>+ * out-of-bounds tx_off.
>+ */
>+ smc->conn.peer_rmbe_idx = 1;
> smc->conn.local_tx_ctrl.token = ntohl(clc->r0.rmbe_alert_token);
> smc->conn.peer_rmbe_size = bufsize;
> atomic_set(&smc->conn.peer_rmbe_space, smc->conn.peer_rmbe_size);
>- smc->conn.tx_off = bufsize * (smc->conn.peer_rmbe_idx - 1);
>+ smc->conn.tx_off = 0;
Althrough we only have 1 RMBE/DMBE per RMB/DMB, but this does break SMC
protocol.
I will send another patch, checking the bound in dibs_loopback.c, please
ignore this one.
Thanks sashiko for pointing this out!
Best regards,
Dust
^ permalink raw reply
* [PATCH net-next v2] selftests/net/openvswitch: add SCTP flow key test
From: Minxi Hou @ 2026-07-07 3:47 UTC (permalink / raw)
To: netdev
Cc: aconole, echaudro, i.maximets, i.maximets, davem, edumazet, kuba,
pabeni, horms, shuah, dev, linux-kselftest, linux-kernel,
Minxi Hou
Register OVS_KEY_ATTR_SCTP in the flow key parser so that sctp()
can be used in flow specifications. The ovs_key_sctp class already
exists (with src/dst fields matching the TCP/UDP siblings) but was
not wired into the parser, so the token was silently dropped and the
kernel rejected the flow.
Add test_sctp_connect_v4 exercising the SCTP flow key with
port-specific matching: sctp(dst=4443) for client-to-server and
sctp(src=4443) for server-to-client.
Wait for ncat readiness with ovs_wait instead of a fixed sleep so
the test does not race against ncat startup. Use grep -c on the
listening message to distinguish between successive ncat instances
that share the same stderr log. Kill the previous server before
respawning to avoid EADDRINUSE on the SCTP port.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
---
v1 -> v2: replace sleep with ovs_wait on ncat listening output,
kill previous ncat server before respawning to avoid
port conflict (Aaron review feedback)
.../selftests/net/openvswitch/openvswitch.sh | 102 ++++++++++++++++++
.../selftests/net/openvswitch/ovs-dpctl.py | 5 +
2 files changed, 107 insertions(+)
diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh b/tools/testing/selftests/net/openvswitch/openvswitch.sh
index 2954245129a2..9c364eeb2ec2 100755
--- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
+++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh
@@ -32,6 +32,7 @@ tests="
dec_ttl ttl: dec_ttl decrements IP TTL
flow_set flow-set: Flow modify
action_set set: SET action rewrites fields
+ sctp_connect_v4 sctp: SCTP flow key matching
psample psample: Sampling packets with psample"
info() {
@@ -443,6 +444,107 @@ test_action_set() {
return 0
}
+# sctp_connect_v4 test
+# - sctp(dst=4443) matches client-to-server INIT
+# - sctp(src=4443) matches server-to-client INIT-ACK
+# - remove flows and verify connection fails, reinstall and recover
+test_sctp_connect_v4() {
+ local t="test_sctp_connect_v4"
+
+ which ncat >/dev/null 2>&1 || return $ksft_skip
+ modprobe -q sctp 2>/dev/null || return $ksft_skip
+
+ sbx_add "$t" || return $?
+ ovs_add_dp "$t" sctp4 || return 1
+
+ info "create namespaces"
+ for ns in client server; do
+ ovs_add_netns_and_veths "$t" "sctp4" "$ns" \
+ "${ns:0:1}0" "${ns:0:1}1" || return 1
+ done
+
+ ip netns exec client ip addr add 172.31.110.10/24 dev c1
+ ip netns exec client ip link set c1 up
+ ip netns exec server ip addr add 172.31.110.20/24 dev s1
+ ip netns exec server ip link set s1 up
+
+ # ARP forwarding
+ ovs_add_flow "$t" sctp4 \
+ 'in_port(1),eth(),eth_type(0x0806),arp()' \
+ '2' || return 1
+ ovs_add_flow "$t" sctp4 \
+ 'in_port(2),eth(),eth_type(0x0806),arp()' \
+ '1' || return 1
+
+ # SCTP port matching: dst for request, src for reply
+ ovs_add_flow "$t" sctp4 \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4(proto=132),sctp(dst=4443)' \
+ '2' || return 1
+ ovs_add_flow "$t" sctp4 \
+ 'in_port(2),eth(),eth_type(0x0800),ipv4(proto=132),sctp(src=4443)' \
+ '1' || return 1
+
+ echo "server" | \
+ ovs_netns_spawn_daemon "$t" "server" \
+ ncat --sctp -l 172.31.110.20 -vn 4443
+ local server_pid=$pid
+ ovs_wait sh -c \
+ "[ \$(grep -c 'Ncat: Listening' ${ovs_dir}/stderr) -ge 1 ]" \
+ || return 1
+
+ info "verify SCTP association with port-keyed flows"
+ ovs_sbx "$t" ip netns exec client \
+ ncat --sctp -i 1 -zv 172.31.110.20 4443 \
+ || return 1
+
+ ovs_del_flows "$t" sctp4
+
+ info "verify connection fails without flows"
+ ovs_add_flow "$t" sctp4 \
+ 'in_port(1),eth(),eth_type(0x0806),arp()' \
+ '2' || return 1
+ ovs_add_flow "$t" sctp4 \
+ 'in_port(2),eth(),eth_type(0x0806),arp()' \
+ '1' || return 1
+
+ kill -TERM $server_pid 2>/dev/null
+ echo "server2" | \
+ ovs_netns_spawn_daemon "$t" "server" \
+ ncat --sctp -l 172.31.110.20 -vn 4443
+ server_pid=$pid
+ ovs_wait sh -c \
+ "[ \$(grep -c 'Ncat: Listening' ${ovs_dir}/stderr) -ge 2 ]" \
+ || return 1
+
+ ovs_sbx "$t" ip netns exec client \
+ ncat --sctp -w 2 -zv 172.31.110.20 4443 \
+ >/dev/null 2>&1 \
+ && { info "FAIL: connection should fail without flows"
+ return 1; }
+
+ info "reinstall flows and verify recovery"
+ ovs_add_flow "$t" sctp4 \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4(proto=132),sctp(dst=4443)' \
+ '2' || return 1
+ ovs_add_flow "$t" sctp4 \
+ 'in_port(2),eth(),eth_type(0x0800),ipv4(proto=132),sctp(src=4443)' \
+ '1' || return 1
+
+ kill -TERM $server_pid 2>/dev/null
+ echo "server3" | \
+ ovs_netns_spawn_daemon "$t" "server" \
+ ncat --sctp -l 172.31.110.20 -vn 4443
+ ovs_wait sh -c \
+ "[ \$(grep -c 'Ncat: Listening' ${ovs_dir}/stderr) -ge 3 ]" \
+ || return 1
+
+ ovs_sbx "$t" ip netns exec client \
+ ncat --sctp -i 1 -zv 172.31.110.20 4443 \
+ || return 1
+
+ return 0
+}
+
# psample test
# - use psample to observe packets
test_psample() {
diff --git a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
index e1ecfad2c03e..7cfc29ec7e59 100644
--- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
+++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
@@ -1982,6 +1982,11 @@ class ovskey(nla):
"icmp",
ovskey.ovs_key_icmp,
),
+ (
+ "OVS_KEY_ATTR_SCTP",
+ "sctp",
+ ovskey.ovs_key_sctp,
+ ),
(
"OVS_KEY_ATTR_TCP_FLAGS",
"tcp_flags",
--
2.55.0
^ permalink raw reply related
* Re: [PATCH net-next] net: ethernet: qualcomm: remove unneeded 'fast_io' parameter in regmap_config
From: Jie Luo @ 2026-07-07 3:15 UTC (permalink / raw)
To: Wolfram Sang, linux-kernel
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev
In-Reply-To: <20260705164208.2184-2-wsa+renesas@sang-engineering.com>
On 7/6/2026 12:41 AM, Wolfram Sang wrote:
> When using MMIO with regmap, fast_io is implied. No need to set it
> again.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
> No dependencies, can be applied directly to the subsystem tree. Buildbot is
> happy, too.
>
> drivers/net/ethernet/qualcomm/ppe/ppe.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/qualcomm/ppe/ppe.c b/drivers/net/ethernet/qualcomm/ppe/ppe.c
> index be747510d947..3c301e609d3e 100644
> --- a/drivers/net/ethernet/qualcomm/ppe/ppe.c
> +++ b/drivers/net/ethernet/qualcomm/ppe/ppe.c
> @@ -106,7 +106,6 @@ static const struct regmap_config regmap_config_ipq9574 = {
> .rd_table = &ppe_reg_table,
> .wr_table = &ppe_reg_table,
> .max_register = 0xbef800,
> - .fast_io = true,
> };
>
> static int ppe_clock_init_and_reset(struct ppe_device *ppe_dev)
Reviewed-by: Luo Jie <jie.luo@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH net-next] net: skbuff: use net_zcopy_get() instead of refcount_inc()
From: luyun @ 2026-07-07 2:36 UTC (permalink / raw)
To: Willem de Bruijn, davem, edumazet, kuba, pabeni, horms,
kerneljasonxing, kuniyu
Cc: mhal, bjorn, jiayuan.chen, netdev, minhnguyen.080505
In-Reply-To: <willemdebruijn.kernel.250ccf6e7c9be@gmail.com>
在 2026/7/6 21:55, Willem de Bruijn 写道:
> Yun Lu wrote:
>> From: Yun Lu <luyun@kylinos.cn>
>>
>> The net_zcopy_get() increments the uarg->refcnt, which is called both
>> in pskb_carve_inside_header() and pskb_carve_inside_nonlinear().
>> Also use net_zcopy_get() in pskb_expand_head for code consistency.
>>
>> No functional change intended.
>>
>> Signed-off-by: Yun Lu <luyun@kylinos.cn>
>> ---
>> net/core/skbuff.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>> index 18dabb4e9cfa..bcf3b2c65fb9 100644
>> --- a/net/core/skbuff.c
>> +++ b/net/core/skbuff.c
>> @@ -2326,7 +2326,7 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
>> if (skb_orphan_frags(skb, gfp_mask))
>> goto nofrags;
>> if (skb_zcopy(skb))
>> - refcount_inc(&skb_uarg(skb)->refcnt);
>> + net_zcopy_get(skb_zcopy(skb));
> This adds some unnecessary instructions in skb_zcopy.
>
> It's not terrible and I see the consistency argument. But would make
> more sense to update the recently added pskb_carve_.. variants instead.
Thanks for your review.
The skb_zcopy() does indeed make repeated checks. So following your
suggestion,
I have modified the code as follows:
- net_zcopy_get(skb_zcopy(skb));
+ net_zcopy_get(skb_uarg(skb));
Does it seem more reasonable?
And I plan to modify all three functions in patch version 2.
^ permalink raw reply
* Re: [PATCH v19 22/40] dept: track PG_locked with dept
From: Byungchul Park @ 2026-07-07 2:35 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-kernel, max.byungchul.park, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, david, amir73il, gregkh,
kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, boqun.feng, longman, yunseong.kim, ysk,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, miguel.ojeda.sandonis, neilb, bagasdotme,
wsa+renesas, dave.hansen, geert, ojeda, alex.gaynor, gary,
bjorn3_gh, lossin, a.hindborg, aliceryhl, tmgross, rust-for-linux
In-Reply-To: <akvueAxPl8aoLvMR@casper.infradead.org>
On Mon, Jul 06, 2026 at 07:05:44PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 06, 2026 at 03:19:10PM +0900, Byungchul Park wrote:
> > Makes dept able to track PG_locked waits and events, which will be
> > useful in practice. See the following link that shows dept worked with
> > PG_locked and detected real issues in practice:
> >
> > https://lore.kernel.org/lkml/1674268856-31807-1-git-send-email-byungchul.park@lge.com/
>
> > @@ -219,6 +220,7 @@ struct page {
> > struct page *kmsan_shadow;
> > struct page *kmsan_origin;
> > #endif
> > + struct dept_ext_wgen pg_locked_wgen;
> > } _struct_page_alignment;
>
> I may not understand this quite correctly, but I think that tracking
> PG_locked dependencies in the struct page has both false positive and
> false negative problems.
>
> Imagine we have a file mapping M1 containing folio F1 at index 0 and F2
> at index 1. It is correct locking order to lock F1 before locking F2
> (for example when doing writeback). Later, M1 has its folios reclaimed
> and returned to the free pool. Then each is added to mapping M2, this
> time with folio F2 at index 8 and F1 at index 9. Now the correct order
> to lock these folios in the order F2 followed by F1.
First of all, I appreciate your feedback. Thanks!
That case doesn't generate any dependency unless any other waits are
involved in. That should be handled in xxx_nested manner e.g.
folio_lock_nested() that I need to introduce. The work is in progress.
> I don't see a part of this patch where we clear pg_locked_wgen when the
> page is returned to the page allocator. Maybe I missed that.
You are right. pg_locked_wgen doesn't get cleared. However, DEPT works
this way:
folio_lock()
wait_for_pg_locked_cleared()
set_pg_locked() // (1) update pg_locked_wgen to the current wgen
... // there might be other waits
folio_unlock()
clear_pg_locked() // (2) check if there have been any waits since (1)
In other words, it's guranteed that pg_locked_wgen has been updated e.i.
(1) when DEPT refers to pg_locked_wgen e.i. (2). So I don't think it's
a problem.
> I think we should be tracking PG_locked dependencies in the owner
> of the folio. For files, that would be in the struct address_space.
> For anon memory, I think that's in the anon_vma, but if somebody told
> me it was in some other structure, I wouldn't argue with them.
I think it's a good point but it's a classification issue. folios owned
by struct address_space should be classified to e.g. address_space_class
and ones owned by struct anon_vma should be classified to e.g.
anon_vma_class. I will work on it to apply the insight you just gave
but better do it as follow-up patches since the initial patchset is
already too big to get reviewed.
> This requires slightly more complexity than lockdep currently has.
> We don't want to use a lockdep class for each folio, obviously. So we
> need something to say "I already have folio F1 locked, is it OK to lock
From DEPT's perspective, folio_lock(F1) and folio_lock(F2) are waits and
folio_unlock(F1) and folio_unlock(F2) are events. Since DEPT tracks
dependencies with specified classes between waits and events, DEPT's
interest in the following example is to detect a situation like:
< context X >
folio_lock(address_space_class'ed F1)
...
folio_lock(anon_vma_class'ed F2)
...
folio_unlock(anon_vma_class'ed F2)
...
folio_unlock(address_space_class'ed F1)
< context Y >
folio_lock(anon_vma_class'ed any folio)
...
folio_lock(address_space_class'ed any folio)
...
folio_unlock(address_space_class'ed any folio)
...
folio_unlock(anon_vma_class'ed any folio)
However, the following pattern should be manually annotated by
developers like using folio_lock_nested() or something. DEPT cannot
work with it automatically:
folio_lock(address_space_class'ed F1)
...
folio_lock(address_space_class'ed F2)
...
folio_unlock(address_space_class'ed F2)
...
folio_unlock(address_space_class'ed F1)
or
folio_lock(anon_vma_class'ed F1)
...
folio_lock(anon_vma_class'ed F2)
...
folio_unlock(anon_vma_class'ed F2)
...
folio_unlock(anon_vma_class'ed F1)
These should be explicitly annotated by developers if it's intended:
folio_lock(address_space_class'ed F1)
...
folio_lock_nested(address_space_class'ed F2)
...
folio_unlock(address_space_class'ed F2)
...
folio_unlock(address_space_class'ed F1)
or
folio_lock(anon_vma_class'ed F1)
...
folio_lock_nested(anon_vma_class'ed F2)
...
folio_unlock(anon_vma_class'ed F2)
...
folio_unlock(anon_vma_class'ed F1)
> folio F2?". Essentially figuring out how we can track all folios in a
> given mapping the same way, and making sure that we don't deadlock on
> folios in the same mapping.
At the moment, as I told you, DEPT cannot work with dependencies between
the same class'ed folios. However, it'd be much better if DEPT can work
with even those cases. Could you provide a scenario where a deadlock
happens between the same class'ed ones? Any idea how to detect for the
cases?
> If F1 and F2 are in different mappings, it's not a deadlock if F1 is in a
> filesystem mapping and F2 is in its backing dev. It's also not a deadlock
> if F1 and F2 are both filesystem folios and the inodes are both locked.
> See vfs_lock_two_folios() in fs/remap_range.c.
Yeah.. DEPT is a tracker to track dependencies between waits and events
even across different contexts, but not a magic unfortunately. That
lock ordering issue - with the same class'ed ones - should be resolved
in the manual manner as vfs_lock_two_folios() does.
> I have much less knowledge about anonymous memory locking order.
> Maybe it doesn't happen. Or about locking one anon and one file folio.
> For slab memory, we don't sleep on PG_locked (it's used as a spinlock bit).
> For other kinds of memory ... I don't know. Page migration is fun.
Anyway, the sophisticated classification you mentioned is necessary for
DEPT to be better especially for folio locking mechanism.
Thanks again!
Byungchul
^ permalink raw reply
* Re: [PATCH 0/18] pull request (net-next): ipsec-next 2026-06-12
From: Yan Yan @ 2026-07-07 2:33 UTC (permalink / raw)
To: Antony Antony
Cc: Jakub Kicinski, Steffen Klassert, Nathan Harold, Antony Antony,
David Miller, Herbert Xu, netdev, Tobias Brunner, Sabrina Dubroca
In-Reply-To: <akfveJrtxW9yMLXK@Antony2201.local>
Hi Antony,
I agree it starts to feel very convoluted. Please see the results inline below
4.2. [Wildcard Mark] Creates two SAs differing only by mark: SA
(mark_1) and an SA (mark_none). Migrating the mark_none to mark_1.
Expecting it will fail with EEXIST and both SAs intact BUT the
mark_none SA ends up being deleted.
The test fails the same way: EEXIST is returned and SA (mark_none) is
deleted. I still think we need to fix the collision pre-check in the
following block: x_new is expected to be SA(mark_1) but ends up being
SA (mark_none)
// This probably should be xfrm_state_lookup_exact
x_new = xfrm_state_lookup(net, new_mark_key, &m.new_daddr,
um->id.spi, um->id.proto,
m.new_family);
if (x_new) {
xfrm_state_put(x_new);
if (x_new != x) {
NL_SET_ERR_MSG(extack, "New SA tuple already occupied");
err = -EEXIST;
goto out;
}
/* self-match via wide mark mask; not a collision */
6. Creates two SAs differing only by mark: first SA (mark_1) and
secondly an SA (mark None).
Before the patch: Migrating the SA (mark_1) to mark_2 fails with
ESRCH, two SAs remain untouched
After the patch: Migrating the SA (mark_1) to mark_2 fails with
EEXIST, two SAs remain untouched
Thinking it through again I think the behavior of the new patch makes
sense. This migration should not succeed because we also not allow
adding a SA(mark_specific) after if there is a SA(mark_none)
installed. So now the migration behavior is consistent with it.
All other tests still pass.
On Fri, Jul 3, 2026 at 10:21 AM Antony Antony <antony@phenome.org> wrote:
>
> Hi Yan,
>
> thanks for testing. Would you please test on a new series?
>
> On Thu, Jun 25, 2026 at 06:58:47PM -0700, Yan Yan wrote:
> > Hi Antony,
> >
> > I ran the following test cases and two—4.2 and 6—are worth disucssing:
> >
> > 1. Mark Inheritance: Creates one SA and migrates it without
> > specifying a new mark. [PASSED]
> > 2. Mark Update: Creates one SA with a specific mark and migrates it
> > to a new specific mark. [PASSED]
> > 3. State Update Isolation: Creates two SAs differing only by mark and
> > verifies that migrating one does not affect the other. [PASSED]
> > 4. Mark Collision:
> > 4.1 [Specific Mark] Creates two SAs differing only by mark: SA
> > (mark_1) and an SA (mark_2). Verifies migrating SA (mark_1) to mark_2
> > fails with EEXIST and both SAs intact. [PASSED]
> > 4.2 [Wildcard Mark] Creates two SAs differing only by mark: SA
> > (mark_1) and an SA (mark_none). Migrate the mark_none to mark_1.
> > Expecting failure with EEXIST and both SAs intact. [FAILED: SA
> > (mark_none) ends up being deleted]
> > 5. Mark Mismatch:
> > 5.1 Creates only a wildcard SA and verifying migration using a
> > specific mark fails with ESRCH; SA intact [PASSED]
> > 5.2 Creates only one SA (mark_1) and verifying migration using a
> > mark_2 fails with ESRCH; SA intact [PASSED]
> > 6. Mark Shadowing Failure:: Creates two SAs differing only by mark:
> > the first SA (mark_1) and the second SA (mark None). Migrating the SA
> > (mark_1) fails with ESRCH, two SAs remain untouched [PASSED]
> >
> > --------------------------------
> > My questions are as follows:
> >
> > Regarding 4.2 I believe is a kernel bug. During the pre-migration
> > collision check, the lookup for the mark_1 matches the wildcard SA
> > itself first, causing the kernel to miss the collision with the
> > existing specific SA with mark_1
> >
> > At https://github.com/antonyantony/linux/blob/migrate-state-fixes-v0/net/xfrm/xfrm_user.c#L3450
> >
> > x_new = xfrm_state_lookup(net, new_mark_key, &m.new_daddr, ----> BUG:
> > We are looking for the existence of SA (mark_1) but SA (mark_none) is
> > returned.
> > um->id.spi, um->id.proto, m.new_family);
> > if (x_new) {
> > xfrm_state_put(x_new);
> > if (x_new != x) { ----> BUG: We end up having x_new == x
> > NL_SET_ERR_MSG(extack, "New SA tuple already occupied");
> > err = -EEXIST;
> > goto out;
> > }
> this should be fixed no. Would please try again?
>
>
> > /* self-match via wide mark mask; not a collision */
> >
> > Would it be possible to traverse the entire list or create a lookup
> > method for an exact match?
> >
> > Regarding 6. I wrote the tests as per the kernel implementation but
> > I'm not sure it is intended. Intuitively, this migration should
> > succeed by finding and updating the specific SA (mark_1) instead of
> > failing. Is this failure considered an acceptable limit, or should we
> > aim to support exact-match lookup here?
>
>
> While trying to fix MIGRATE_STATE I fell into a rabbit hole:)
> I realized many methods have this issue. Just never noticed, as it would be
> a misconfiguration, and would likely cause operational issues rather than
> crashes.
> However, given that xfrm accepts multiple identical SAs differing only in mark,
> a proper fix is to add __xfrm_state_locate_exact() for both spi and byaddr
> lookups. This should be used in all calls from userspace.
>
> I just send a new series.
> https://patchwork.kernel.org/project/netdevbpf/patch/migrate-state-fixes-v0-1-a69e8637ba3b@secunet.com/
>
> -antony
--
--
Best,
Yan
^ permalink raw reply
* Re: [PATCH] xfrm: clear mode callbacks after failed mode setup
From: Cen Zhang @ 2026-07-07 2:32 UTC (permalink / raw)
To: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Christian Hopps
Cc: netdev, linux-kernel, baijiaju1990
In-Reply-To: <20260627030117.2614741-1-zzzccc427@gmail.com>
Hi all,
Sorry for the noise, but I wanted to gently follow up on this patch in
case it got buried.
I would really appreciate any feedback when you have a chance. Please
let me know if I should make any changes or provide more testing
results.
Thanks a lot.
Best regards,
Cen Zhang
Cen Zhang <zzzccc427@gmail.com> 于2026年6月27日周六 11:01写道：
>
> xfrm_state_gc_task can run long after a failed IPTFS state setup. In the
> reproduced case, __xfrm_init_state() cached x->mode_cbs, IPTFS setup
> returned -ENOMEM before publishing mode_data, and the temporary module
> reference from xfrm_get_mode_cbs() was dropped immediately. The dead state
> then kept x->mode_cbs until deferred GC ran after xfrm_iptfs had been
> unloaded.
>
> Clear x->mode_cbs when mode init or clone fails before publishing
> mode_data. Those states never installed mode-specific state or the
> long-term IPTFS module pin, so deferred GC has nothing mode-specific to
> destroy and must not retain a callback table pointer past the temporary
> lookup reference.
>
> The buggy scenario involves two paths, with each column showing the order
> within that path:
>
> failed setup path:
> 1. cache x->mode_cbs
> 2. mode setup fails before mode_data
> 3. drop the temporary module ref
> 4. dead state keeps x->mode_cbs cached
>
> GC/unload path:
> 1. xfrm_state_put() queues GC work
> 2. xfrm_iptfs unloads later
> 3. xfrm_state_gc_task runs
> 4. GC dereferences stale x->mode_cbs
>
> This also covers the failed clone path where clone_state() returns before
> publishing mode_data.
>
> Validation reproduced this kernel report:
> Kernel panic - not syncing: Fatal exception
> CONFIG_FAULT_INJECTION_STACKTRACE_FILTER=y
> failslab_stacktrace_filter matched xfrm_iptfs frames
> ack_error=-12
> FAULT_INJECTION: forcing a failure
> BUG: unable to handle page fault
> Workqueue: events xfrm_state_gc_task
> RIP: xfrm_state_gc_task+0x142/0x650
> Modules linked in: esp4_offload xfrm_user [last unloaded: xfrm_iptfs]
> Kernel panic - not syncing: Fatal exception
>
> Fixes: 4b3faf610cc6 ("xfrm: iptfs: add new iptfs xfrm mode impl")
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
> ---
> net/xfrm/xfrm_state.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
> index c58cd024e3c6..4d95b2720894 100644
> --- a/net/xfrm/xfrm_state.c
> +++ b/net/xfrm/xfrm_state.c
> @@ -2071,8 +2071,11 @@ static struct xfrm_state *xfrm_state_clone_and_setup(struct xfrm_state *orig,
>
> x->mode_cbs = orig->mode_cbs;
> if (x->mode_cbs && x->mode_cbs->clone_state) {
> - if (x->mode_cbs->clone_state(x, orig))
> + if (x->mode_cbs->clone_state(x, orig)) {
> + if (!x->mode_data)
> + x->mode_cbs = NULL;
> goto error;
> + }
> }
>
> x->props.reqid = m->new_reqid;
> @@ -3291,6 +3294,8 @@ int __xfrm_init_state(struct xfrm_state *x, struct netlink_ext_ack *extack)
> if (x->mode_cbs->init_state)
> err = x->mode_cbs->init_state(x);
> module_put(x->mode_cbs->owner);
> + if (err && !x->mode_data)
> + x->mode_cbs = NULL;
> }
> error:
> return err;
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v5] net: gro: fix double aggregation of flush-marked skbs
From: Shiming Cheng (成诗明) @ 2026-07-07 2:26 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, dsahern@kernel.org,
imv4bel@gmail.com, linux-mediatek@lists.infradead.org,
alice@isovalent.com, daniel.zahka@gmail.com,
eilaimemedsnaimel@gmail.com, nbd@nbd.name,
steffen.klassert@secunet.com, horms@kernel.org, kuba@kernel.org,
pabeni@redhat.com, edumazet@google.com,
willemdebruijn.kernel@gmail.com, willemb@google.com,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
matthias.bgg@gmail.com, davem@davemloft.net,
AngeloGioacchino Del Regno, sd@queasysnail.net
Cc: Lena Wang (王娜), stable@vger.kernel.org
In-Reply-To: <willemdebruijn.kernel.27b4940999026@gmail.com>
On Mon, 2026-07-06 at 12:36 -0400, Willem de Bruijn wrote:
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> [PATCH net v5]
>
> Shiming Cheng wrote:
> > The skb_gro_receive_list() function is missing a critical safety
> > check
> > that exists in the skb_gro_receive() implementation. Specifically,
> > it
> > does not validate NAPI_GRO_CB(skb)->flush before allowing packet
> > aggregation
>
> In v3 I requested referring to the commit that fixed this in
> skb_gro_receive: commit 0ab03f353d36 ("net-gro: Fix GRO flush when
> receiving a GSO packet."). That explains the issue well.
updated in PATCH V6.
> >
> > This allows already-GRO'd packets with existing frag_list to be
> > re-aggregated into a new GRO session, corrupting the frag_list
> > chain
> > structure. When skb_segment() attempts to unpack these malformed
> > packets,
> > it encounters invalid state and triggers a kernel panic.
> >
> > Scenario (Tethering/Device forwarding):
> > 1. Driver: Generated aggregated packet P1 via LRO with frag_list
> > 2. Dev A: Receives aggregated fraglist packet and flush flag set
> > 3. Dev A: Re-enters GRO, skb_gro_receive_list() is called
> > 4. Missing flush check allows re-aggregation despite flush flag
> > 5. Frag_list chain becomes corrupted (loops or dangling refs)
> > 6. Dev B: TX path calls skb_segment(), crashes on corrupted
> > frag_list
> >
> > Root cause in skb_segment():
> > The check at line ~4891:
> > if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) &&
> > (skb_headlen(list_skb) == len || sg)) {
> >
> > When frag_list is corrupted by double aggregation, when list_skb
> > is
> > a NULL pointer from skb->next, skb_headlen(list_skb) dereference
> > NULL/corrupted pointers occurs.
> >
> > Call Trace:
> > skb_headlen(NULL skb)
> > skb_segment
> > tcp_gso_segment
> > tcp4_gso_segment
> > inet_gso_segment
> > skb_mac_gso_segment
> > __skb_gso_segment
> > skb_gso_segment
> > validate_xmit_skb
> > validate_xmit_skb_list
> > sch_direct_xmit
> > qdisc_restart
> > __qdisc_run
> > qdisc_run
> > net_tx_action
> >
> > Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return
> > check in
> > skb_gro_receive_list(), matching the defensive programming pattern
> > of
> > skb_gro_receive().
> >
> > Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Shiming Cheng <shiming.cheng@mediatek.com>
> > ---
> > net/core/gro.c | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/core/gro.c b/net/core/gro.c
> > index 35f2f708f010..b1573d98f3a5 100644
> > --- a/net/core/gro.c
> > +++ b/net/core/gro.c
> > @@ -229,7 +229,14 @@ int skb_gro_receive(struct sk_buff *p, struct
> > sk_buff *skb)
> >
> > int skb_gro_receive_list(struct sk_buff *p, struct sk_buff *skb)
> > {
> > - if (unlikely(p->len + skb->len >= 65536))
> > + /*
> > + * Packets marked with NAPI_GRO_CB(skb)->flush have already
> > gone
> > + * through GRO/LRO processing and must not be aggregated
> > again.
> > + * Re-entering frag_list GRO may corrupt the frag_list chain
> > and
> > + * later crash during GSO segmentaiont.
> > + */
>
> Such a verbose comment is not needed. Code would be overwhelmed by
> comments if done everywhere.
>
updated comment in PATCH V6.
> > + if (unlikely(p->len + skb->len >= 65536 ||
> > + NAPI_GRO_CB(skb)->flush))
> > return -E2BIG;
> >
> > if (!pskb_may_pull(skb, skb_gro_offset(skb))) {
> > --
> > 2.45.2
> >
>
>
^ permalink raw reply
* [PATCH v6] net: gro: fix double aggregation of flush-marked skbs
From: Shiming Cheng @ 2026-07-07 2:14 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni, horms, matthias.bgg,
angelogioacchino.delregno, willemb, daniel.zahka, alice, sd,
eilaimemedsnaimel, imv4bel, nbd, dsahern, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: stable, steffen.klassert, lena.wang, shiming.cheng
The skb_gro_receive_list() function is missing a critical safety check
that exists in the skb_gro_receive() implementation. Specifically, it
does not validate NAPI_GRO_CB(skb)->flush before allowing packet
aggregation, as of commit 0ab03f353d36 ("net-gro: Fix GRO flush
when receiving a GSO packet.").
This allows already-GRO'd packets with existing frag_list to be
re-aggregated into a new GRO session, corrupting the frag_list chain
structure. When skb_segment() attempts to unpack these malformed packets,
it encounters invalid state and triggers a kernel panic.
Scenario (Tethering/Device forwarding):
1. Driver: Generated aggregated packet P1 via LRO with frag_list
2. Dev A: Receives aggregated fraglist packet and flush flag set
3. Dev A: Re-enters GRO, skb_gro_receive_list() is called
4. Missing flush check allows re-aggregation despite flush flag
5. Frag_list chain becomes corrupted (loops or dangling refs)
6. Dev B: TX path calls skb_segment(), crashes on corrupted frag_list
Root cause in skb_segment():
The check at line ~4891:
if (hsize <= 0 && i >= nfrags && skb_headlen(list_skb) &&
(skb_headlen(list_skb) == len || sg)) {
When frag_list is corrupted by double aggregation, when list_skb is
a NULL pointer from skb->next, skb_headlen(list_skb) dereference
NULL/corrupted pointers occurs.
Call Trace:
skb_headlen(NULL skb)
skb_segment
tcp_gso_segment
tcp4_gso_segment
inet_gso_segment
skb_mac_gso_segment
__skb_gso_segment
skb_gso_segment
validate_xmit_skb
validate_xmit_skb_list
sch_direct_xmit
qdisc_restart
__qdisc_run
qdisc_run
net_tx_action
Fix: Add NAPI_GRO_CB(skb)->flush validation to the early-return check in
skb_gro_receive_list(), matching the defensive programming pattern of
skb_gro_receive().
Fixes: 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")
Cc: stable@vger.kernel.org
Signed-off-by: Shiming Cheng <shiming.cheng@mediatek.com>
---
net/core/gro.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/core/gro.c b/net/core/gro.c
index 35f2f708f010..b413f4a6462b 100644
--- a/net/core/gro.c
+++ b/net/core/gro.c
@@ -229,7 +229,9 @@ int skb_gro_receive(struct sk_buff *p, struct sk_buff *skb)
int skb_gro_receive_list(struct sk_buff *p, struct sk_buff *skb)
{
- if (unlikely(p->len + skb->len >= 65536))
+ /* make sure to check flush flag and to not merge */
+ if (unlikely(p->len + skb->len >= 65536 ||
+ NAPI_GRO_CB(skb)->flush))
return -E2BIG;
if (!pskb_may_pull(skb, skb_gro_offset(skb))) {
--
2.45.2
^ permalink raw reply related
* Re: [PATCH net v3] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
From: Qingfang Deng @ 2026-07-07 2:05 UTC (permalink / raw)
To: Norbert Szetei, netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Yue Haibing, Guillaume Nault, Kees Cook, Taegu Ha,
linux-ppp, linux-kernel
In-Reply-To: <E793FCF2-58DE-4387-A983-C7B4BC3158BD@doyensec.com>
On 2026/7/6 17:01, Norbert Szetei wrote:
> pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path:
>
> l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv()
> -> ppp_input(&po->chan)
>
> It runs under rcu_read_lock() holding only an l2tp_session reference and
> takes NO reference on the internal PPP channel (struct channel,
> chan->ppp) that ppp_input() dereferences.
>
> The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel
> are RCU-safe. But the internal struct channel is a separate allocation
> that ppp_release_channel() frees with a plain kfree():
>
> close(data socket) -> pppol2tp_release() -> pppox_unbind_sock()
> -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch)
>
> For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit
> (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips
> both ppp_disconnect_channel()'s synchronize_net() and
> ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace
> period. rcu_read_lock() in pppol2tp_recv() does not protect against a
> plain kfree(), so an in-flight ppp_input() on one CPU can dereference
> the channel just freed by close() on another CPU.
>
> The bug is reachable by an unprivileged user.
>
> Defer the channel free to an RCU callback via call_rcu() so the grace
> period fences any in-flight ppp_input(). The disconnect and unbridge
> teardown paths already fence with synchronize_net()/synchronize_rcu();
> call_rcu() does the same here without stalling the close() path.
>
> Fixes: ee40fb2e1eb5 ("l2tp: protect sock pointer of struct pppol2tp_session with RCU")
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Norbert Szetei <norbert@doyensec.com>
> ---
> v3:
> - Added rcu_barrier() at the end of ppp_cleanup() to ensure all
> ppp_release_channel_free() callbacks complete before the module's
> text segment is unloaded (Documentation/RCU/rcubarrier.rst).
> v2: https://lore.kernel.org/linux-ppp/D9C0245B-608B-4884-8A09-F55BA4A9F948@doyensec.com/
> - Moved skb_queue_purge() to a dedicated RCU callback to prevent leaking
> skbs added by an in-flight ppp_input() during the grace period (Sebastian).
> - Retained call_rcu() to avoid introducing synchronous multi-millisecond
> latency into the teardown path.
> v1: https://lore.kernel.org/netdev/C954A7EA-AA98-4E3C-80B5-42C34B3183A3@doyensec.com/
>
> drivers/net/ppp/ppp_generic.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
> index 57c68efa5ff8..717c1d3aa953 100644
> --- a/drivers/net/ppp/ppp_generic.c
> +++ b/drivers/net/ppp/ppp_generic.c
> @@ -184,6 +184,7 @@ struct channel {
> struct list_head clist; /* link in list of channels per unit */
> spinlock_t upl; /* protects `ppp' and 'bridge' */
> struct channel __rcu *bridge; /* "bridged" ppp channel */
> + struct rcu_head rcu; /* for RCU-deferred free of the channel */
> #ifdef CONFIG_PPP_MULTILINK
> u8 avail; /* flag used in multilink stuff */
> u8 had_frag; /* >= 1 fragments have been sent */
> @@ -3562,6 +3563,18 @@ ppp_disconnect_channel(struct channel *pch)
> return err;
> }
>
> +/* Purge after the grace period: a late ppp_input() may still queue an
> + * skb on pch->file.rq before the last RCU reader drains.
> + */
> +static void ppp_release_channel_free(struct rcu_head *rcu)
> +{
> + struct channel *pch = container_of(rcu, struct channel, rcu);
> +
> + skb_queue_purge(&pch->file.xq);
> + skb_queue_purge(&pch->file.rq);
> + kfree(pch);
> +}
> +
> /*
> * Drop a reference to a ppp channel and free its memory if the refcount reaches
> * zero.
> @@ -3581,9 +3594,7 @@ static void ppp_release_channel(struct channel *pch)
> pr_err("ppp: destroying undead channel %p !\n", pch);
> return;
> }
> - skb_queue_purge(&pch->file.xq);
> - skb_queue_purge(&pch->file.rq);
> - kfree(pch);
> + call_rcu(&pch->rcu, ppp_release_channel_free);
> }
>
> static void __exit ppp_cleanup(void)
> @@ -3596,6 +3607,7 @@ static void __exit ppp_cleanup(void)
> device_destroy(&ppp_class, MKDEV(PPP_MAJOR, 0));
> class_unregister(&ppp_class);
> unregister_pernet_device(&ppp_net_ops);
> + rcu_barrier(); /* wait for RCU callbacks before module unload */
> }
>
> /*
Reviewed-by: Qingfang Deng <qingfang.deng@linux.dev>
^ permalink raw reply
* Re: [PATCH] net: prestera: validate firmware header length
From: Pengpeng Hou @ 2026-07-07 1:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: Elad Nachman, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <ff1d3744-b61e-4ae3-9041-297f398f28a6@lunn.ch>
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] net: bnx2x: validate firmware section bounds without overflow
From: Pengpeng Hou @ 2026-07-07 1:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: Sudarsana Kalluru, Manish Chopra, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <2b37879c-5ba1-42b1-9d13-98acfcd5ee35@lunn.ch>
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] net: usb: sr9700: validate receive packet extent
From: Pengpeng Hou @ 2026-07-07 1:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ethan Nelson-Moore, Peter Korsgaard, Simon Horman,
linux-usb, netdev, linux-kernel
In-Reply-To: <f4490acc-e922-431f-a37e-31189cfac304@lunn.ch>
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] net: usb: cx82310_eth: bound partial receive continuation
From: Pengpeng Hou @ 2026-07-07 1:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Kees Cook, linux-usb, netdev, linux-kernel
In-Reply-To: <8ed2790f-05ab-4c6b-9982-e92a08c6c99d@lunn.ch>
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] atm: solos-pci: validate DMA receive size
From: Pengpeng Hou @ 2026-07-07 1:45 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Chas Williams, linux-atm-general, netdev, linux-kernel
In-Reply-To: <8ef7d67f-c47c-4342-a411-4ac126abd757@lunn.ch>
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
From: Nazle Asmade, Muhammad Nazim Amirul @ 2026-07-07 1:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: dinguyen@kernel.org, maxime.chevallier@bootlin.com,
rmk+kernel@armlinux.org.uk, krzk+dt@kernel.org,
conor+dt@kernel.org, robh@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
andrew+netdev@lunn.ch, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <bf7c6343-e0c0-47bd-a857-0f1881fc8659@lunn.ch>
On 3/7/2026 9:12 pm, Andrew Lunn wrote:
>>>> The delays are provided by the FPGA GMII-to-RGMII converter soft IP,
>>>> which is hardcoded in the FPGA bitstream and cannot be disabled or
>>>> modified from the driver side.
>>>>
>>>> Using phy-mode = "rgmii" is intentional here — it prevents the PHY from
>>>> adding its own internal delays on top, since the FPGA converter already
>>>> provides the full required delay. This is consistent with how all other
>>>> Agilex5 SoCDK board variants are described, as seen in commit
>>>> c5637e5ceb4b ("arm64: dts: socfpga: agilex5: Fix phy-mode to rgmii as HW
>>>> provides clock delay") already in Dinh Nguyen's tree, which applies the
>>>> same rationale across all Agilex5 boards.
>>>
>>> I've become more insistent that designs get this correct. So i don't
>>> care too much about past systems. Many vendors are having to fix up
>>> their drivers and DT in order to make new boards consistent.
>>>
>>> You can look at your system as the FPGA being the MAC, and the PHY is
>>> the PHY. The PCB is not providing the delay, the MAC is. This exactly
>>> fits the description above.
>>>
>>> Andrew
>> Hi Andrew,
>>
>> Thank you for the clarification. We agree with your framework in
>> principle, but would like to explain why phy-mode = "rgmii" is the
>> appropriate description for this specific case.
>
> So you want to be different to every other system? Please extend the
> text in that document to say that this device is special and has a
> different definition of phy-mode to all other systems.
>
>> After getting more information from hw team, for Agilex specific device,
>> the RGMII timing delays on this board are provided by an FPGA delay
>> chain (Input/Output Delay Chain primitives in the FPGA fabric). The
>> reason for using the FPGA rather than the PHY is that the Marvell PHY on
>> this board only supports 0ns or 2ns delay steps — too coarse to meet the
>> RGMII timing requirements. The FPGA delay chain provides up to 63 steps
>> of ~0.1ns precision, which the hardware team has tuned at design time to
>> achieve correct signal timing.
>
> As the text says, fine tuning is different. You can have fine tuning,
> in both the MAC or PHY, while using either rgmii or rgmii-id.
>
> Also, you cannot fine tune just the MAC, tuning needs to take into
> account the PCB design, the length of the clock and data tracks on the
> PCB. You can however take into account the difference in timing within
> the FPGA.
>
> Or does your FPGA team produce a different bitstream per board design,
> after some sort of calibration in order to determine what the PCB
> characteristics are?
>
> This however opens up a new possibility. It does sound like you can
> produce a new bitstream with the delays set to just the tuning delay,
> not the 2ns + tuning? You need to decide if this is simpler than
> changing the MAC driver to mask the phy-mode.
>
>> Changing to phy-mode = "rgmii-id" and having
>> the driver strip the delay before passing to the PHY would produce the
>> same hardware behaviour (PHY adds zero delay), but would add driver
>> complexity with no practical benefit, and would misrepresent the FPGA
>> delay as a driver-managed MAC delay when it is actually a fixed,
>> board-level hardware calibration.
>
> Look at the wording again. It does not say it is driver managed.
>
> # There are a small number of cases where the MAC has hard coded
> # delays which cannot be disabled.
>
> This exactly fits your situation.
>
>> Could you advise if you still prefer the rgmii-id approach given this
>> constraint?
>
> rgmii-id is the correct value for your PCB design. Please follow what
> the text says.
>
> Andrew
>
>
Hi Andrew,
Sure, will reflect this changes in v2, Thanks for the review
BR,
Nazim
^ permalink raw reply
* Re: Re: [PATCH net-next v9 6/6] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
From: 李志 @ 2026-07-07 1:39 UTC (permalink / raw)
To: Paolo Abeni
Cc: Andrew Lunn, sashiko-reviews, conor+dt, robh, devicetree, Min Lin,
netdev@vger.kernel.org
In-Reply-To: <41d0e6d6-f1fc-425e-a122-b0433a925a3d@redhat.com>
> -----Original Messages-----
> From: "Paolo Abeni" <pabeni@redhat.com>
> Send time:Monday, 06/07/2026 21:35:40
> To: 李志 <lizhi2@eswincomputing.com>, "Andrew Lunn" <andrew@lunn.ch>
> Cc: sashiko-reviews@lists.linux.dev, conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org, "Min Lin" <linmin@eswincomputing.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>
> Subject: Re: [PATCH net-next v9 6/6] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
>
> On 7/3/26 3:50 AM, 李志 wrote:
> >> -----Original Messages-----
> >> From: "Andrew Lunn" <andrew@lunn.ch>
> >> Send time:Thursday, 02/07/2026 21:22:34
> >> To: 李志 <lizhi2@eswincomputing.com>
> >> Cc: sashiko-reviews@lists.linux.dev, conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org, "Min Lin" <linmin@eswincomputing.com>
> >> Subject: Re: Re: [PATCH net-next v9 6/6] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
> >>
> >>> Hi Andrew,
> >>>
> >>> One question before I prepare the next revision.
> >>>
> >>> As discussed previously, the DTS patch was included only to provide the overall
> >>> Ethernet design context during the review of the binding and driver patches:
> >>>
> >>> https://lore.kernel.org/lkml/64bf6b40-b947-4ffa-8d48-4d6341931327@lunn.ch/
> >>>
> >>> For the next revision, would it be acceptable to drop the DTS patch from this
> >>> series and post only the binding and driver patches? The complete DTS
> >>> enablement is planned to be submitted later as a separate series after the
> >>> binding and driver have been merged.
> >>
> >> What normally happens is that I give an Acked-by: or a Reviewed-by:
> >> for the DT patch, and you submit it for merging via the DT Maintainer.
> >> Everything then meets up in linux-next.
> >>
> >> Why do you need to do this later? Why not now?
> >>
> >
> > There is an another seperate DT patch series
> > [https://lore.kernel.org/all/20260615122016.1110206-1-pinkesh.vaghela@einfochips.com/]
> > which is under review.
> > It also introduces DT nodes for reset, clock, pinctrl, HSP power domain.
> >
> > Therefore, our planned steps are as follows:
> > 1. In the next net-next v10 patch series, drop the DTS patches, and submit only
> > the bindings and driver.
> > 2. Wait for Pinkesh’s DT patch series to be merged.
> > 3. Once the HSPCRG patch series
> > [https://lore.kernel.org/all/20260605060730.1605-1-dongxuyang@eswincomputing.com/]
> > is merged, submit a new DT patch series to extend ESWIN EIC7700 SoC support
> > for all HSP modules—including USB, eMMC, SD, and Ethernet, since they are all
> > under the HSP bus node eventhough ethernet doese not depend on HSPCRG patch.
>
> In v10 please include some actual description of the series, beyond the
> changelog.
>
OK, thanks.
For v10, we'll drop the DTS patches (patches 5 and 6 in v9) from this
series and update the cover letter to include a proper description of
the series.
^ permalink raw reply
* Re: [PATCH net-next v2] ipv4: hold a consistent view of rt->dst.dev under RCU
From: luoxuanqiang @ 2026-07-07 1:26 UTC (permalink / raw)
To: Ido Schimmel
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
David Ahern, Simon Horman, Kuniyuki Iwashima, netdev,
linux-kernel, Xuanqiang Luo
In-Reply-To: <20260705164649.GA295849@shredder>
在 2026/7/6 00:46, Ido Schimmel 写道:
> On Wed, Jul 01, 2026 at 11:24:34AM +0800,xuanqiang.luo@linux.dev wrote:
>> From: Xuanqiang Luo<luoxuanqiang@kylinos.cn>
>>
>> rt_flush_dev() walks the per-CPU uncached route list and rewrites
>> rt->dst.dev in-place to blackhole_netdev under spin_lock_bh().
>> This lock does not exclude RCU readers, which may load rt->dst.dev
>> multiple times within a single rcu_read_lock() region.
>>
>> ip_rt_send_redirect() is a typical example: it reads rt->dst.dev
>> three times to obtain in_dev, the L3 master ifindex, and net.
>> A concurrent device unregistration can repoint rt->dst.dev to
>> blackhole_netdev between those reads, making the reader combine
>> state from two different net_devices — for instance, an in_dev
>> from the real device but a netns and peer lookup from the blackhole
>> device. ip_rt_get_source() has the same problem: it reads
>> rt->dst.dev four times to obtain the output ifindex, the netns,
>> and the source address, so a concurrent flush can cause the source
>> selection to mix state from different devices.
> Why only change ip_rt_send_redirect() and ip_rt_get_source() when the
> patch is titled "ipv4: hold a consistent view of rt->dst.dev under RCU"?
> What is the criterion?
Thanks! You are right, the subject is too broad. I will make them
more accurate in the next version.
>> Take a single dst_dev_rcu() snapshot of rt->dst.dev at the start
>> of each affected RCU reader and use that snapshot throughout, so
>> concurrent flushes cannot cause mid-function inconsistency.
>> Publish the in-place write in rt_flush_dev() with rcu_assign_pointer()
>> to match the readers.
> The rt_flush_dev() change should be a separate change. Note that
> dst_dev_put() was already converted to use rcu_assign_pointer().
>
I will split the rt_flush_dev() change into a separate patch.
>> Fixes: caacf05e5ad1a ("ipv4: Properly purge netdev references on uncached routes.")
> Please remove the Fixes tag given you are targeting net-next.
Just to clarify: is the suggestion to drop the Fixes tag here solely
because this patch is targeted at net-next? Or are there any other
reasons?
>> Signed-off-by: Xuanqiang Luo<luoxuanqiang@kylinos.cn>
>> ---
>> v2:
>> - Use dst_dev_rcu() and dev_net_rcu() for the RCU readers.
>> - Use rcu_assign_pointer() when publishing the uncached route device
>> replacement.
>> - Slightly adjust the commit message wording because this issue was found
>> by inspection, not from an observed user-visible failure.
>>
>> v1:https://lore.kernel.org/all/20260630094250.29386-1-xuanqiang.luo@linux.dev/
>>
>> net/ipv4/route.c | 29 +++++++++++++++++------------
>> 1 file changed, 17 insertions(+), 12 deletions(-)
>>
>> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
>> index 3f3de5164d6e5..57f38467e6d0c 100644
>> --- a/net/ipv4/route.c
>> +++ b/net/ipv4/route.c
>> @@ -873,6 +873,7 @@ static void ipv4_negative_advice(struct sock *sk,
>> void ip_rt_send_redirect(struct sk_buff *skb)
>> {
>> struct rtable *rt = skb_rtable(skb);
>> + struct net_device *dev;
> https://docs.kernel.org/process/maintainer-netdev.html#local-variable-ordering-reverse-xmas-tree-rcs
>
> Same in other places.
Thanks for pointing this out!
I will fix the local variable ordering in the next version.
^ permalink raw reply
* Re: [PATCH v3 1/9] ata: don't store pci_device_id
From: Damien Le Moal @ 2026-07-07 1:12 UTC (permalink / raw)
To: Gary Guo, Bjorn Helgaas, Zhenzhong Duan, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Niklas Cassel, GOTO Masanori,
YOKOTA Hiroshi, James E.J. Bottomley, Martin K. Petersen,
Vaibhav Gupta, Jens Taprogge, Ido Schimmel, Petr Machata,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Airlie
Cc: linux-pci, driver-core, linux-kernel, linux-ide, linux-scsi,
industrypack-devel, netdev, dri-devel
In-Reply-To: <20260706-pci_id_fix-v3-1-2d48fc025acc@garyguo.net>
On 7/6/26 23:11, Gary Guo wrote:
> pci_device_id is not guaranteed to live longer than probe due to presence
> of dynamic ID. All information apart from driver_data can be easily
> retrieved from pci_dev, so just store driver_data.
>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Gary Guo <gary@garyguo.net>
Looks good, but please change the commit title to:
ata: ata_generic: don't store pci_device_id
With that,
Acked-by: Damien Le Moal <dlemoal@kernel.org>
--
Damien Le Moal
Western Digital Research
^ permalink raw reply
* [PATCH net] bonding: fix devconf_all NULL dereference when IPv6 is disabled
From: zhangzl2013 @ 2026-07-07 1:06 UTC (permalink / raw)
To: Zhaolong Zhang, Jay Vosburgh, Andrew Lunn, Jakub Kicinski
Cc: David S . Miller, Eric Dumazet, Paolo Abeni, Hangbin Liu, netdev,
linux-kernel, Qianheng Peng, Zhaolong Zhang
From: Zhaolong Zhang <zhangzl68@chinatelecom.cn>
When booting with the 'ipv6.disable=1' parameter, the devconf_all is
never initialized because inet6_init() exits before addrconf_init() is
called which initializes it. bond_send_validate(), however, will still
call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to
NULL derefence of net->ipv6.devconf_all in ip6_pol_route().
BUG: kernel NULL pointer dereference, address: 000000000000000c
[...]
Workqueue: bond0 bond_arp_monitor [bonding]
RIP: 0010:ip6_pol_route+0x69/0x480
[...]
Call Trace:
<TASK>
? srso_return_thunk+0x5/0x5f
? __pfx_ip6_pol_route_output+0x10/0x10
fib6_rule_lookup+0xfe/0x260
? wakeup_preempt+0x8a/0x90
? srso_return_thunk+0x5/0x5f
? srso_return_thunk+0x5/0x5f
? sched_balance_rq+0x369/0x810
ip6_route_output_flags+0xd7/0x170
bond_ns_send_all+0xde/0x280 [bonding]
bond_ab_arp_probe+0x296/0x320 [bonding]
? srso_return_thunk+0x5/0x5f
bond_activebackup_arp_mon+0xb4/0x2c0 [bonding]
process_one_work+0x196/0x370
worker_thread+0x1af/0x320
? srso_return_thunk+0x5/0x5f
? __pfx_worker_thread+0x10/0x10
kthread+0xe3/0x120
? __pfx_kthread+0x10/0x10
ret_from_fork+0x199/0x260
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK>
Fix this by adding ipv6_mod_enabled() condition check in the caller.
Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets")
Signed-off-by: Qianheng Peng <pengqh1@chinatelecom.cn>
Signed-off-by: Zhaolong Zhang <zhangzl68@chinatelecom.cn>
---
drivers/net/bonding/bond_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index e044fc733b8c..522eab060f9e 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3455,7 +3455,8 @@ static void bond_send_validate(struct bonding *bond, struct slave *slave)
{
bond_arp_send_all(bond, slave);
#if IS_ENABLED(CONFIG_IPV6)
- bond_ns_send_all(bond, slave);
+ if (likely(ipv6_mod_enabled()))
+ bond_ns_send_all(bond, slave);
#endif
}
--
2.52.0
^ permalink raw reply related
* [PATCH net-next] net/tcp: Add explicit tracepoint for tcp_syn_ack_timeout()
From: Emil Tsalapatis @ 2026-07-07 1:01 UTC (permalink / raw)
To: netdev, linux-trace-kernel
Cc: edumazet, ncardwell, kuniyu, rostedt, mhiramat, davem, kuba,
pabeni, Emil Tsalapatis
Clang can inline the tcp_syn_ack_timeout() function during compilation,
making it impossible to use kprobes for tracing without preventing
inlining. Add an explicit tracepoint to it instead.
Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
---
include/trace/events/tcp.h | 72 ++++++++++++++++++++++++++++++++++++++
net/ipv4/tcp_timer.c | 3 ++
2 files changed, 75 insertions(+)
diff --git a/include/trace/events/tcp.h b/include/trace/events/tcp.h
index f155f95cdb6e..37ffaa50faad 100644
--- a/include/trace/events/tcp.h
+++ b/include/trace/events/tcp.h
@@ -332,6 +332,78 @@ TRACE_EVENT(tcp_retransmit_synack,
__entry->saddr_v6, __entry->daddr_v6)
);
+TRACE_EVENT(tcp_syn_ack_timeout,
+
+ TP_PROTO(const struct request_sock *req),
+
+ TP_ARGS(req),
+
+ TP_STRUCT__entry(
+ __field(const void *, req)
+ __field(__u16, sport)
+ __field(__u16, dport)
+ __field(__u16, family)
+ __array(__u8, saddr, 4)
+ __array(__u8, daddr, 4)
+ __array(__u8, saddr_v6, 16)
+ __array(__u8, daddr_v6, 16)
+ __field(u8, state)
+ __field(u8, num_timeout)
+ __field(bool, acked)
+ ),
+
+
+ TP_fast_assign(
+ const struct inet_request_sock *ireq = inet_rsk(req);
+ __be32 *p32;
+
+ __entry->req = req;
+
+ __entry->sport = ireq->ir_num;
+ __entry->dport = ntohs(ireq->ir_rmt_port);
+ __entry->family = req->__req_common.skc_family;
+
+ p32 = (__be32 *) __entry->saddr;
+ *p32 = ireq->ir_loc_addr;
+
+ p32 = (__be32 *) __entry->daddr;
+ *p32 = ireq->ir_rmt_addr;
+
+#if IS_ENABLED(CONFIG_IPV6)
+ /*
+ * Cannot use TP_STORE_ADDRS directly because it assumes
+ * there is an sk available.
+ */
+ if (__entry->family == AF_INET6) {
+ struct in6_addr *pin6;
+
+ pin6 = (struct in6_addr *)__entry->saddr_v6;
+ *pin6 = ireq->ir_v6_loc_addr;
+ pin6 = (struct in6_addr *)__entry->daddr_v6;
+ *pin6 = ireq->ir_v6_rmt_addr;
+ } else {
+ TP_STORE_V4MAPPED(__entry, ireq->ir_loc_addr, ireq->ir_rmt_addr);
+ }
+#else
+ TP_STORE_V4MAPPED(__entry, ireq->ir_loc_addr, ireq->ir_rmt_addr);
+#endif
+
+ __entry->state = ireq->ireq_state;
+ __entry->num_timeout = req->num_timeout;
+ __entry->acked = ireq->acked;
+ ),
+
+ TP_printk("family=%s sport=%hu dport=%hu saddr=%pI4 "
+ "daddr=%pI4 saddrv6=%pI6c daddrv6=%pI6c "
+ "ireq_state=%s num_timeout=%u acked=%d",
+ show_family_name(__entry->family),
+ __entry->sport, __entry->dport,
+ __entry->saddr, __entry->daddr,
+ __entry->saddr_v6, __entry->daddr_v6,
+ show_tcp_state_name(__entry->state),
+ __entry->num_timeout, __entry->acked)
+);
+
TRACE_EVENT(tcp_sendmsg_locked,
TP_PROTO(const struct sock *sk, const struct msghdr *msg,
const struct sk_buff *skb, int size_goal),
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index bf171b5e1eb3..8f482a6b43e3 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -24,6 +24,7 @@
#include <net/tcp.h>
#include <net/tcp_ecn.h>
#include <net/rstreason.h>
+#include <trace/events/tcp.h>
static u32 tcp_clamp_rto_to_user_timeout(const struct sock *sk)
{
@@ -753,6 +754,8 @@ void tcp_syn_ack_timeout(const struct request_sock *req)
struct net *net = read_pnet(&inet_rsk(req)->ireq_net);
__NET_INC_STATS(net, LINUX_MIB_TCPTIMEOUTS);
+
+ trace_tcp_syn_ack_timeout(req);
}
void tcp_reset_keepalive_timer(struct sock *sk, unsigned long len)
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net] vxlan: add missing NULL check for vxlan_sock in GRO path
From: Xiang Mei @ 2026-07-06 23:59 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: AutonomousCodeSecurity, andrew+netdev, davem, edumazet, kuba, kys,
linux-kernel, netdev, pabeni, tgopinath, tom
In-Reply-To: <20260706235614.1726605-1-kuniyu@google.com>
On Mon, Jul 6, 2026 at 4:56 PM Kuniyuki Iwashima <kuniyu@google.com> wrote:
>
> From: "Xiang Mei (Microsoft)" <xmei5@asu.edu>
> Date: Mon, 6 Jul 2026 23:33:44 +0000
> > vxlan_gro_prepare_receive() reads vs->flags from the vxlan_sock returned
> > by rcu_dereference_sk_user_data(sk) without a NULL check, unlike the rest
> > of the driver (e.g. vxlan_rcv() does "if (!vs) goto drop;").
> >
> > udp_tunnel_sock_release() clears sk_user_data to NULL and waits an RCU
> > grace period before the socket leaves the hash, so any callback running on
> > the tunnel socket during teardown must tolerate a NULL sk_user_data. If a
> > VXLAN device is torn down while GRO runs on its UDP tunnel socket,
> > sk_user_data can be NULL when a packet carrying VXLAN_HF_RCO arrives,
> > faulting in NAPI/softirq context.
> >
> > The GRO path was the only sk_user_data reader on the socket missing this
> > guard (vxlan_rcv and vxlan_err_lookup already have it; the gro_complete
> > callbacks do not touch sk_user_data). Add the same NULL check so GRO
> > flushes instead of dereferencing a NULL socket pointer.
> >
> > Oops: general protection fault ... SMP KASAN NOPTI
> > KASAN: probably user-memory-access in range [0x2018-0x201f]
> > RIP: 0010:vxlan_gro_prepare_receive (drivers/net/vxlan/vxlan_core.c:678)
> > vxlan_gro_receive (drivers/net/vxlan/vxlan_core.c:713)
> > udp_gro_receive (net/ipv4/udp_offload.c:841)
> > ...
> > dev_gro_receive (net/core/gro.c:522)
> > gro_receive_skb (net/core/gro.c:640)
> > tun_napi_poll (drivers/net/tun.c:259)
> > ...
> > Kernel panic - not syncing: Fatal exception in interrupt
> >
> > Fixes: 5602c48cf875 ("vxlan: change vxlan to use UDP socket GRO")
> > Reported-by: AutonomousCodeSecurity@microsoft.com
> > Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
> > ---
> > drivers/net/vxlan/vxlan_core.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
> > index b5b1253ac08b..f2235bae9bfe 100644
> > --- a/drivers/net/vxlan/vxlan_core.c
> > +++ b/drivers/net/vxlan/vxlan_core.c
> > @@ -663,6 +663,9 @@ static struct vxlanhdr *vxlan_gro_prepare_receive(struct sock *sk,
> > struct vxlan_sock *vs = rcu_dereference_sk_user_data(sk);
> > __be32 flags;
> >
> > + if (!vs)
> > + return NULL;
>
> Please work on the latest tree, it's fixed 2 months ago.
>
Thanks for the reminder. I apologize for my mistake.
Xiang
> commit 30a45c0bffdd62350261e2f2689fdba426a33578
> Author: Kuniyuki Iwashima <kuniyu@google.com>
> Date: Sat May 2 03:12:59 2026
>
> vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().
^ permalink raw reply
* Re: [PATCH net] vxlan: add missing NULL check for vxlan_sock in GRO path
From: Kuniyuki Iwashima @ 2026-07-06 23:56 UTC (permalink / raw)
To: xmei5
Cc: AutonomousCodeSecurity, andrew+netdev, davem, edumazet, kuba, kys,
linux-kernel, netdev, pabeni, tgopinath, tom
In-Reply-To: <20260706233344.3334648-1-xmei5@asu.edu>
From: "Xiang Mei (Microsoft)" <xmei5@asu.edu>
Date: Mon, 6 Jul 2026 23:33:44 +0000
> vxlan_gro_prepare_receive() reads vs->flags from the vxlan_sock returned
> by rcu_dereference_sk_user_data(sk) without a NULL check, unlike the rest
> of the driver (e.g. vxlan_rcv() does "if (!vs) goto drop;").
>
> udp_tunnel_sock_release() clears sk_user_data to NULL and waits an RCU
> grace period before the socket leaves the hash, so any callback running on
> the tunnel socket during teardown must tolerate a NULL sk_user_data. If a
> VXLAN device is torn down while GRO runs on its UDP tunnel socket,
> sk_user_data can be NULL when a packet carrying VXLAN_HF_RCO arrives,
> faulting in NAPI/softirq context.
>
> The GRO path was the only sk_user_data reader on the socket missing this
> guard (vxlan_rcv and vxlan_err_lookup already have it; the gro_complete
> callbacks do not touch sk_user_data). Add the same NULL check so GRO
> flushes instead of dereferencing a NULL socket pointer.
>
> Oops: general protection fault ... SMP KASAN NOPTI
> KASAN: probably user-memory-access in range [0x2018-0x201f]
> RIP: 0010:vxlan_gro_prepare_receive (drivers/net/vxlan/vxlan_core.c:678)
> vxlan_gro_receive (drivers/net/vxlan/vxlan_core.c:713)
> udp_gro_receive (net/ipv4/udp_offload.c:841)
> ...
> dev_gro_receive (net/core/gro.c:522)
> gro_receive_skb (net/core/gro.c:640)
> tun_napi_poll (drivers/net/tun.c:259)
> ...
> Kernel panic - not syncing: Fatal exception in interrupt
>
> Fixes: 5602c48cf875 ("vxlan: change vxlan to use UDP socket GRO")
> Reported-by: AutonomousCodeSecurity@microsoft.com
> Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
> ---
> drivers/net/vxlan/vxlan_core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
> index b5b1253ac08b..f2235bae9bfe 100644
> --- a/drivers/net/vxlan/vxlan_core.c
> +++ b/drivers/net/vxlan/vxlan_core.c
> @@ -663,6 +663,9 @@ static struct vxlanhdr *vxlan_gro_prepare_receive(struct sock *sk,
> struct vxlan_sock *vs = rcu_dereference_sk_user_data(sk);
> __be32 flags;
>
> + if (!vs)
> + return NULL;
Please work on the latest tree, it's fixed 2 months ago.
commit 30a45c0bffdd62350261e2f2689fdba426a33578
Author: Kuniyuki Iwashima <kuniyu@google.com>
Date: Sat May 2 03:12:59 2026
vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().
^ 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