* Re: [PATCH bpf v2 1/4] bpf, sockmap: Reject unhashed UDP sockets on sockmap update
From: John Fastabend @ 2026-07-01 22:59 UTC (permalink / raw)
To: Jakub Sitnicki
Cc: Michal Luczaj, Eric Dumazet, Kuniyuki Iwashima, Paolo Abeni,
Willem de Bruijn, Jiayuan Chen, David S. Miller, Jakub Kicinski,
Simon Horman, Alexei Starovoitov, Cong Wang, Daniel Borkmann,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Martin KaFai Lau, Song Liu, Yonghong Song, Jiri Olsa,
Emil Tsalapatis, Shuah Khan, netdev, bpf, linux-kernel,
linux-kselftest
In-Reply-To: <87pl1937c7.fsf@cloudflare.com>
On Mon, Jun 29, 2026 at 01:38:00PM +0200, Jakub Sitnicki wrote:
>On Fri, Jun 26, 2026 at 10:36 PM +02, Michal Luczaj wrote:
>> 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>
>> Signed-off-by: Michal Luczaj <mhal@rbox.co>
>> ---
>
>Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
For me as well.
Reviewed-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* [PATCH net-next v4 0/2] udp: fix FOU/GUE over multicast
From: Anton Danilov @ 2026-07-01 23:10 UTC (permalink / raw)
To: netdev
Cc: Willem de Bruijn, David S . Miller, David Ahern, Eric Dumazet,
Kuniyuki Iwashima, Jakub Kicinski, Paolo Abeni, Simon Horman,
Shuah Khan, linux-kselftest
UDP encapsulation (FOU, GUE) has never worked correctly with multicast
destination addresses. When a FOU-encapsulated packet arrives at a
multicast address, it enters __udp4_lib_mcast_deliver() which calls
consume_skb() on packets that need resubmission to the inner protocol
handler, silently dropping them instead.
The unicast delivery path handles this correctly by returning -ret,
but the multicast path was never updated to support UDP encapsulation
resubmit.
This causes silent packet loss for FOU/GRETAP tunnels configured with
multicast remote addresses. The loss ratio depends on the early demux
cache hit rate - packets that hit early demux bypass the multicast path
and work correctly, masking the issue.
Reproducing the issue:
ip netns add ns_a && ip netns add ns_b
ip link add veth0 type veth peer name veth1
ip link set veth0 netns ns_a && ip link set veth1 netns ns_b
ip -n ns_a addr add 10.0.0.1/24 dev veth0 && ip -n ns_a link set veth0 up
ip -n ns_b addr add 10.0.0.2/24 dev veth1 && ip -n ns_b link set veth1 up
# Multicast routes
ip -n ns_a route add 239.0.0.0/8 dev veth0
ip -n ns_b route add 239.0.0.0/8 dev veth1
# Disable early demux to expose the issue (otherwise it's partially masked)
ip netns exec ns_b sysctl -w net.ipv4.ip_early_demux=0
# Join multicast group on receiver
ip -n ns_b addr add 239.0.0.1/32 dev veth1 autojoin
# Sender: GRETAP with FOU encap
ip -n ns_a link add eoudp0 type gretap \
remote 239.0.0.1 local 10.0.0.1 \
encap fou encap-sport 4797 encap-dport 4797 key 239.0.0.1
ip -n ns_a link set eoudp0 up
ip -n ns_a addr add 192.168.99.1/24 dev eoudp0
# Receiver: FOU listener + GRETAP
ip netns exec ns_b ip fou add port 4797 ipproto 47
ip -n ns_b link add eoudp0 type gretap \
remote 239.0.0.1 local 10.0.0.2 \
encap fou encap-sport 4797 encap-dport 4797 key 239.0.0.1
ip -n ns_b link set eoudp0 up
ip -n ns_b addr add 192.168.99.2/24 dev eoudp0
# Static neigh: ARP replies can't traverse unidirectional mcast tunnel
recv_mac=$(ip -n ns_b link show eoudp0 | awk '/ether/{print $2}')
ip -n ns_a neigh add 192.168.99.2 lladdr $recv_mac dev eoudp0
# Test: ping through the FOU/GRETAP tunnel
ip netns exec ns_a ping -c 100 192.168.99.2
# -> without this patch: 0 packets received on eoudp0
# -> with this patch: all packets received on eoudp0
AI assistance (Claude, claude-opus-4-6) was used during root cause
analysis of the kernel source code (tracing the call chain from
udp_queue_rcv_skb through encap_rcv to ip_protocol_deliver_rcu,
comparing unicast/GSO/multicast paths) and during patch and selftest
authoring. The fix approach was identified by observing that the
unicast path (udp_unicast_rcv_skb) already handles encap resubmit
correctly via return -ret, while the multicast path did not.
v4:
- Promoted from RFC to PATCH; no functional changes since v3.
v3 was posted as RFC and consequently dropped from patchwork,
which explains the lack of review feedback.
v3: https://lore.kernel.org/netdev/cover.1777934869.git.littlesmilingcloud@gmail.com/
- Use return -ret instead of calling ip_protocol_deliver_rcu()
directly, matching the unicast path and avoiding call stack
growth with nested encapsulations (Kuniyuki Iwashima)
- Only change the first-socket path; the clone loop is not
reachable for tunnel sockets (no SO_REUSEADDR/SO_REUSEPORT)
- Replace Python packet generator with ping through a properly
configured FOU/GRETAP tunnel in the selftest
- Add static neighbor entry (ARP replies cannot traverse the
unidirectional multicast tunnel)
v2: https://lore.kernel.org/netdev/ad_dal164gVmImWl@dau-home-pc/
- Moved inline Python packet generator into a separate helper
- Fixed author email typo in Signed-off-by
v1 (RFC): https://lore.kernel.org/netdev/ad7MsSJOuUU6EGwS@dau-home-pc/
Anton Danilov (2):
udp: fix encapsulation packet resubmit in multicast deliver
selftests: net: add FOU multicast encapsulation resubmit test
net/ipv4/udp.c | 6 +-
net/ipv6/udp.c | 6 +-
tools/testing/selftests/net/Makefile | 1 +
.../testing/selftests/net/fou_mcast_encap.sh | 112 ++++++++++++++++++
4 files changed, 121 insertions(+), 4 deletions(-)
create mode 100755 tools/testing/selftests/net/fou_mcast_encap.sh
--
2.47.3
^ permalink raw reply
* [PATCH net-next v4 1/2] udp: fix encapsulation packet resubmit in multicast deliver
From: Anton Danilov @ 2026-07-01 23:10 UTC (permalink / raw)
To: netdev
Cc: Willem de Bruijn, David S . Miller, David Ahern, Eric Dumazet,
Kuniyuki Iwashima, Jakub Kicinski, Paolo Abeni, Simon Horman,
Shuah Khan, linux-kselftest
In-Reply-To: <cover.1782945956.git.littlesmilingcloud@gmail.com>
When a UDP encapsulation socket (e.g., FOU) receives a multicast
packet, __udp4_lib_mcast_deliver() and __udp6_lib_mcast_deliver()
call consume_skb() when udp_queue_rcv_skb() returns a positive value.
A positive return value from udp_queue_rcv_skb() indicates that the
encap_rcv handler (e.g., fou_udp_recv) has consumed the UDP header
and wants the packet to be resubmitted to the IP protocol handler
for further processing (e.g., as a GRE packet).
The unicast path in udp_unicast_rcv_skb() handles this correctly by
returning -ret, which propagates up to ip_protocol_deliver_rcu() for
resubmission. However, the multicast path destroys the packet via
consume_skb() instead of resubmitting it, causing silent packet loss.
This affects any UDP encapsulation (FOU, GUE) combined with multicast
destination addresses.
Fix this by returning -ret instead of calling consume_skb() when the
return value is positive, matching the behavior of the unicast path.
This avoids growing the call stack compared to calling
ip_protocol_deliver_rcu() directly.
Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com>
Assisted-by: Claude:claude-opus-4-6
---
net/ipv4/udp.c | 6 ++++--
net/ipv6/udp.c | 6 ++++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 70f6cbd4ef73..b0910659391e 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -2475,6 +2475,7 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
struct udp_hslot *hslot;
struct sk_buff *nskb;
bool use_hash2;
+ int ret;
hash2_any = 0;
hash2 = 0;
@@ -2519,8 +2520,9 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
}
if (first) {
- if (udp_queue_rcv_skb(first, skb) > 0)
- consume_skb(skb);
+ ret = udp_queue_rcv_skb(first, skb);
+ if (ret > 0)
+ return -ret;
} else {
kfree_skb(skb);
__UDP_INC_STATS(net, UDP_MIB_IGNOREDMULTI);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 15e032194ecc..ff2e389e286b 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -949,6 +949,7 @@ static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
struct udp_hslot *hslot;
struct sk_buff *nskb;
bool use_hash2;
+ int ret;
hash2_any = 0;
hash2 = 0;
@@ -998,8 +999,9 @@ static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
}
if (first) {
- if (udpv6_queue_rcv_skb(first, skb) > 0)
- consume_skb(skb);
+ ret = udpv6_queue_rcv_skb(first, skb);
+ if (ret > 0)
+ return -ret;
} else {
kfree_skb(skb);
__UDP6_INC_STATS(net, UDP_MIB_IGNOREDMULTI);
--
2.47.3
^ permalink raw reply related
* [PATCH net-next v4 2/2] selftests: net: add FOU multicast encapsulation resubmit test
From: Anton Danilov @ 2026-07-01 23:10 UTC (permalink / raw)
To: netdev
Cc: Willem de Bruijn, David S . Miller, David Ahern, Eric Dumazet,
Kuniyuki Iwashima, Jakub Kicinski, Paolo Abeni, Simon Horman,
Shuah Khan, linux-kselftest
In-Reply-To: <cover.1782945956.git.littlesmilingcloud@gmail.com>
Add a selftest to verify that FOU-encapsulated packets addressed to a
multicast destination are correctly resubmitted to the inner protocol
handler (GRE) via the UDP multicast delivery path.
The test creates two network namespaces connected by a veth pair with
a FOU/GRETAP tunnel using a multicast remote address (239.0.0.1).
Ping is sent through the tunnel and received packets are counted on
the receiver's tunnel interface.
A static neighbor entry is configured on the sender because ARP
replies from the receiver cannot traverse the unidirectional multicast
tunnel back to the sender.
The early demux optimization (net.ipv4.ip_early_demux) is disabled on
the receiver to force packets through __udp4_lib_mcast_deliver(),
which is the code path being tested.
Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com>
Assisted-by: Claude:claude-opus-4-6
---
tools/testing/selftests/net/Makefile | 1 +
.../testing/selftests/net/fou_mcast_encap.sh | 112 ++++++++++++++++++
2 files changed, 113 insertions(+)
create mode 100755 tools/testing/selftests/net/fou_mcast_encap.sh
diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile
index 708d960ae07d..7e9ae937cffa 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -39,6 +39,7 @@ TEST_PROGS := \
fib_rule_tests.sh \
fib_tests.sh \
fin_ack_lat.sh \
+ fou_mcast_encap.sh \
fq_band_pktlimit.sh \
gre_gso.sh \
gre_ipv6_lladdr.sh \
diff --git a/tools/testing/selftests/net/fou_mcast_encap.sh b/tools/testing/selftests/net/fou_mcast_encap.sh
new file mode 100755
index 000000000000..8db9633f4c28
--- /dev/null
+++ b/tools/testing/selftests/net/fou_mcast_encap.sh
@@ -0,0 +1,112 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# Test that UDP encapsulation (FOU) correctly handles packet resubmit
+# when packets are delivered via the multicast UDP delivery path.
+#
+# When a FOU-encapsulated packet arrives with a multicast destination IP,
+# __udp4_lib_mcast_deliver() must resubmit it to the inner protocol
+# handler (e.g., GRE) rather than consuming it. This test verifies that
+# by creating a FOU/GRETAP tunnel with a multicast remote address and
+# sending ping through it.
+#
+# The early demux optimization can mask this issue by routing packets via
+# the unicast path (udp_unicast_rcv_skb), so we disable it to force
+# packets through __udp4_lib_mcast_deliver().
+
+source lib.sh
+
+NSENDER=""
+NRECV=""
+
+cleanup() {
+ cleanup_all_ns
+}
+
+trap cleanup EXIT
+
+setup() {
+ setup_ns NSENDER NRECV
+
+ ip link add veth_s type veth peer name veth_r
+ ip link set veth_s netns "$NSENDER"
+ ip link set veth_r netns "$NRECV"
+
+ ip -n "$NSENDER" addr add 10.0.0.1/24 dev veth_s
+ ip -n "$NSENDER" link set veth_s up
+
+ ip -n "$NRECV" addr add 10.0.0.2/24 dev veth_r
+ ip -n "$NRECV" link set veth_r up
+
+ # Disable early demux to force multicast delivery path
+ ip netns exec "$NRECV" sysctl -wq net.ipv4.ip_early_demux=0
+
+ # Join multicast group on receiver
+ ip -n "$NRECV" addr add 239.0.0.1/32 dev veth_r autojoin
+
+ # Multicast routes
+ ip -n "$NRECV" route add 239.0.0.0/8 dev veth_r
+ ip -n "$NSENDER" route add 239.0.0.0/8 dev veth_s
+
+ # Sender: GRETAP with FOU encap (no FOU listener needed on TX side)
+ ip -n "$NSENDER" link add eoudp0 type gretap \
+ remote 239.0.0.1 local 10.0.0.1 \
+ encap fou encap-sport 4797 encap-dport 4797 \
+ key 239.0.0.1
+ ip -n "$NSENDER" link set eoudp0 up
+ ip -n "$NSENDER" addr add 192.168.99.1/24 dev eoudp0
+
+ # Receiver: FOU listener + GRETAP
+ ip netns exec "$NRECV" ip fou add port 4797 ipproto 47
+ ip -n "$NRECV" link add eoudp0 type gretap \
+ remote 239.0.0.1 local 10.0.0.2 \
+ encap fou encap-sport 4797 encap-dport 4797 \
+ key 239.0.0.1
+ ip -n "$NRECV" link set eoudp0 up
+ ip -n "$NRECV" addr add 192.168.99.2/24 dev eoudp0
+
+ # Static neigh entry on sender: ARP replies cannot traverse the
+ # multicast tunnel back, so pre-populate the neighbor cache.
+ local recv_mac
+ recv_mac=$(ip -n "$NRECV" link show eoudp0 | awk '/ether/{print $2}')
+ ip -n "$NSENDER" neigh add 192.168.99.2 lladdr "$recv_mac" dev eoudp0
+}
+
+get_rx_packets() {
+ ip -n "$NRECV" -s link show eoudp0 | awk '/RX:/{getline; print $2}'
+}
+
+test_fou_mcast_encap() {
+ local count=100
+ local rx_before
+ local rx_after
+ local rx_delta
+
+ # Warmup: let any initial broadcast/ARP traffic settle
+ ip netns exec "$NSENDER" ping -c 1 -W 1 192.168.99.2 >/dev/null 2>&1
+ sleep 1
+
+ rx_before=$(get_rx_packets)
+ ip netns exec "$NSENDER" ping -c $count -W 1 192.168.99.2 >/dev/null 2>&1
+ sleep 1
+ rx_after=$(get_rx_packets)
+
+ rx_delta=$((rx_after - rx_before))
+
+ if [ "$rx_delta" -ge "$count" ]; then
+ echo "PASS: received $rx_delta/$count packets via multicast FOU/GRETAP"
+ return "$ksft_pass"
+ elif [ "$rx_delta" -gt 0 ]; then
+ echo "FAIL: only $rx_delta/$count packets received (partial delivery)"
+ return "$ksft_fail"
+ else
+ echo "FAIL: 0/$count packets received (multicast encap resubmit broken)"
+ return "$ksft_fail"
+ fi
+}
+
+echo "TEST: FOU/GRETAP multicast encapsulation resubmit"
+
+setup
+test_fou_mcast_encap
+exit $?
--
2.47.3
^ permalink raw reply related
* Re: [PATCH bpf v2 4/4] selftests/bpf: Fail unbound UDP on sockmap update
From: Michal Luczaj @ 2026-07-01 23:19 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: Eric Dumazet, Paolo Abeni, Willem de Bruijn, John Fastabend,
Jakub Sitnicki, Jiayuan Chen, David S. Miller, Jakub Kicinski,
Simon Horman, Alexei Starovoitov, Cong Wang, Daniel Borkmann,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Martin KaFai Lau, Song Liu, Yonghong Song, Jiri Olsa,
Emil Tsalapatis, Shuah Khan, netdev, bpf, linux-kernel,
linux-kselftest
In-Reply-To: <CAAVpQUAJYkOBEtgUpL5UgnwM9Hu3Y57a9xZWRy7zHg5XkGnW5w@mail.gmail.com>
On 6/26/26 23:03, Kuniyuki Iwashima wrote:
> On Fri, Jun 26, 2026 at 1:37 PM Michal Luczaj <mhal@rbox.co> wrote:
>>
>> sockmap now rejects unbound UDP sockets. Adjust test_maps.
>>
>> This effectively reverts commit c39aa2159974 ("bpf, selftests: Fix
>> test_maps now that sockmap supports UDP").
>>
>> Signed-off-by: Michal Luczaj <mhal@rbox.co>
>> ---
>> tools/testing/selftests/bpf/test_maps.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
>> index c32da7bd8be2..81cd5d0d69c1 100644
>> --- a/tools/testing/selftests/bpf/test_maps.c
>> +++ b/tools/testing/selftests/bpf/test_maps.c
>> @@ -759,12 +759,12 @@ static void test_sockmap(unsigned int tasks, void *data)
>> goto out_sockmap;
>> }
>>
>> - /* Test update with unsupported UDP socket */
>> + /* Test update with unsupported unbound UDP socket */
>> udp = socket(AF_INET, SOCK_DGRAM, 0);
>> i = 0;
>> err = bpf_map_update_elem(fd, &i, &udp, BPF_ANY);
>> - if (err) {
>> - printf("Failed socket update SOCK_DGRAM '%i:%i'\n",
>> + if (!err) {
>> + printf("Failed allowed unbound SOCK_DGRAM socket update '%i:%i'\n",
>
> nit: Maybe s/Failed/Unexpectedly succeeded/ ?
Sure. I've tried to align with the other printfs ("failed allowed..."), but
I agree it was unclear.
> If we want to avoid breakage, this patch needs to be squashed to
> the fix patch, but it's discouraged in netdev, not sure about bpf tree.
I guess I'll just post v3 as is, and squash if requested.
thanks,
Michal
^ permalink raw reply
* Re: Ethtool : PRBS feature
From: Lee Trager @ 2026-07-01 23:28 UTC (permalink / raw)
To: Andrew Lunn, Srinivasan, Vijay
Cc: Das, Shubham, Alexander Duyck, Maxime Chevallier,
netdev@vger.kernel.org, mkubecek@suse.cz, D H, Siddaraju,
Chintalapalle, Balaji, Lindberg, Magnus,
niklas.damberg@ericsson.com, Wirandi, Jonas
In-Reply-To: <26d44b09-d72c-4e23-84a6-3d0ea4a521ef@lunn.ch>
On 7/1/26 3:02 PM, Andrew Lunn wrote:
> On Wed, Jul 01, 2026 at 09:38:08PM +0000, Srinivasan, Vijay wrote:
>> Hi Andrew,
>> I think there is a disconnect here.
> Which proves my point. The specification is not sufficient if you have
> to keep correcting me.
>
> The kAPI should be understandable by somebody who has a general
> networking background. Please write a specification with that
> assumption in mind. Don't assume the reader is a test engineer who has
> used PRBS for half his life. Assume it is a brand new test engineer
> who is hearing PRBS for the first time. That is what most engineers on
> the netdev list are. Me included.
I think part of the disconnect is that PRBS testing is a signal
integrity test, not a network test. In this case the phy happens to be
Ethernet but it could just as easily be PCIE or USB. That is why it was
heavily suggested to me at netdev 0x19 that this should be done on the
generic phy layer, not netdev.
Lee
^ permalink raw reply
* [PATCH bpf v3 3/4] selftests/bpf: Adapt sockmap update error handling
From: Michal Luczaj @ 2026-07-01 23:28 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: <20260702-sockmap-lookup-udp-leak-v3-0-ff8de8782468@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>
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..b87118aab7c4 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 if (err) {
+ 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.54.0
^ permalink raw reply related
* [PATCH bpf v3 0/4] bpf, sockmap: Fix sockmap leaking UDP socks
From: Michal Luczaj @ 2026-07-01 23:28 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
Fix for UDP sockets getting leaked during sockmap lookup/release.
Accompanied by selftests updates.
Two Sashiko's concerns to be addressed separately:
https://lore.kernel.org/bpf/20260626205814.BAC3C1F000E9@smtp.kernel.org/
Signed-off-by: Michal Luczaj <mhal@rbox.co>
---
Changes in v3:
- selftest: better error handling, ASSERT_*() macros [Sashiko]
- selftest: fix grammar, reorder patches [Kuniyuki]
- Link to v2: https://patch.msgid.link/20260626-sockmap-lookup-udp-leak-v2-0-7e7e201c951a@rbox.co
Changes in v2:
- selftest: drop the original, adapt old tests
- fix: change approach to rejecting unbound UDP [Kuniyuki]
- Link to v1: https://patch.msgid.link/20260623-sockmap-lookup-udp-leak-v1-0-05804f9308e4@rbox.co
To: Alexei Starovoitov <ast@kernel.org>
To: Daniel Borkmann <daniel@iogearbox.net>
To: Andrii Nakryiko <andrii@kernel.org>
To: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
To: Martin KaFai Lau <martin.lau@linux.dev>
To: Song Liu <song@kernel.org>
To: Yonghong Song <yonghong.song@linux.dev>
To: Jiri Olsa <jolsa@kernel.org>
To: Emil Tsalapatis <emil@etsalapatis.com>
To: Shuah Khan <shuah@kernel.org>
To: John Fastabend <john.fastabend@gmail.com>
To: Jakub Sitnicki <jakub@cloudflare.com>
To: Jiayuan Chen <jiayuan.chen@linux.dev>
To: Eric Dumazet <edumazet@google.com>
To: Kuniyuki Iwashima <kuniyu@google.com>
To: Paolo Abeni <pabeni@redhat.com>
To: Willem de Bruijn <willemb@google.com>
To: "David S. Miller" <davem@davemloft.net>
To: Jakub Kicinski <kuba@kernel.org>
To: Simon Horman <horms@kernel.org>
To: Cong Wang <cong.wang@bytedance.com>
Cc: bpf@vger.kernel.org
Cc: linux-kselftest@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
---
Michal Luczaj (4):
selftests/bpf: Ensure UDP sockets are bound
bpf, sockmap: Reject unhashed UDP sockets on sockmap update
selftests/bpf: Adapt sockmap update error handling
selftests/bpf: Fail unbound UDP on sockmap update
net/core/sock_map.c | 2 ++
.../selftests/bpf/prog_tests/sockmap_basic.c | 6 +++---
.../selftests/bpf/prog_tests/sockmap_listen.c | 21 +++++++++++----------
tools/testing/selftests/bpf/test_maps.c | 13 ++++++-------
4 files changed, 22 insertions(+), 20 deletions(-)
---
base-commit: c341792c9c7272cf91c8b17eae929caed7c2a732
change-id: 20260617-sockmap-lookup-udp-leak-bc4e5c5481d7
Best regards,
--
Michal Luczaj <mhal@rbox.co>
^ permalink raw reply
* [PATCH bpf v3 4/4] selftests/bpf: Fail unbound UDP on sockmap update
From: Michal Luczaj @ 2026-07-01 23:28 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: <20260702-sockmap-lookup-udp-leak-v3-0-ff8de8782468@rbox.co>
sockmap now rejects unbound UDP sockets. Adjust test_maps. While at it,
check socket()'s return value.
This effectively reverts commit c39aa2159974 ("bpf, selftests: Fix
test_maps now that sockmap supports UDP").
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Michal Luczaj <mhal@rbox.co>
---
tools/testing/selftests/bpf/test_maps.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
index c32da7bd8be2..6a2641ee7897 100644
--- a/tools/testing/selftests/bpf/test_maps.c
+++ b/tools/testing/selftests/bpf/test_maps.c
@@ -759,16 +759,15 @@ static void test_sockmap(unsigned int tasks, void *data)
goto out_sockmap;
}
- /* Test update with unsupported UDP socket */
+ /* Test update with unsupported unbound UDP socket */
udp = socket(AF_INET, SOCK_DGRAM, 0);
- i = 0;
- err = bpf_map_update_elem(fd, &i, &udp, BPF_ANY);
- if (err) {
- printf("Failed socket update SOCK_DGRAM '%i:%i'\n",
- i, udp);
+ CHECK(udp < 0, "socket(AF_INET, SOCK_DGRAM)", "errno:%d\n", errno);
+ err = bpf_map_update_elem(fd, &(int){0}, &udp, BPF_ANY);
+ close(udp);
+ if (!err) {
+ printf("Unexpectedly succeeded unbound UDP update '0:%i'\n", udp);
goto out_sockmap;
}
- close(udp);
/* Test update without programs */
for (i = 0; i < 6; i++) {
--
2.54.0
^ permalink raw reply related
* [PATCH bpf v3 1/4] selftests/bpf: Ensure UDP sockets are bound
From: Michal Luczaj @ 2026-07-01 23:28 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: <20260702-sockmap-lookup-udp-leak-v3-0-ff8de8782468@rbox.co>
Update sockmap_basic tests to bind sockets before they are used. This
accommodates the recent change in sockmap that rejects unbound UDP sockets.
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Michal Luczaj <mhal@rbox.co>
---
tools/testing/selftests/bpf/prog_tests/sockmap_basic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
index cb3229711f93..2d22a9058a8e 100644
--- a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
+++ b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
@@ -853,7 +853,7 @@ static void test_sockmap_many_socket(void)
return;
}
- udp = xsocket(AF_INET, SOCK_DGRAM | SOCK_NONBLOCK, 0);
+ udp = socket_loopback(AF_INET, SOCK_DGRAM | SOCK_NONBLOCK);
if (udp < 0) {
close(dgram);
close(tcp);
@@ -922,7 +922,7 @@ static void test_sockmap_many_maps(void)
return;
}
- udp = xsocket(AF_INET, SOCK_DGRAM | SOCK_NONBLOCK, 0);
+ udp = socket_loopback(AF_INET, SOCK_DGRAM | SOCK_NONBLOCK);
if (udp < 0) {
close(dgram);
close(tcp);
@@ -993,7 +993,7 @@ static void test_sockmap_same_sock(void)
return;
}
- udp = xsocket(AF_INET, SOCK_DGRAM | SOCK_NONBLOCK, 0);
+ udp = socket_loopback(AF_INET, SOCK_DGRAM | SOCK_NONBLOCK);
if (udp < 0) {
close(dgram);
close(tcp);
--
2.54.0
^ permalink raw reply related
* [PATCH bpf v3 2/4] bpf, sockmap: Reject unhashed UDP sockets on sockmap update
From: Michal Luczaj @ 2026-07-01 23:28 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: <20260702-sockmap-lookup-udp-leak-v3-0-ff8de8782468@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.54.0
^ permalink raw reply related
* Re: [PATCH net] net/packet: avoid fanout hook re-registration after unregister
From: Willem de Bruijn @ 2026-07-01 23:34 UTC (permalink / raw)
To: David Lee, david.lee, Willem de Bruijn
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Dominik 'Disconnect3d' Czarnota, Simon Horman, netdev,
linux-kernel
In-Reply-To: <20260701113947.23180-1-david.lee@trailofbits.com>
David Lee wrote:
> packet_set_ring() temporarily detaches a socket from packet delivery while
> reconfiguring its ring. It records the previous running state, clears
> po->num, unregisters the protocol hook when needed, drops po->bind_lock,
> and later restores po->num and re-registers the hook from the saved
> was_running value.
>
> That unlocked window can race with NETDEV_UNREGISTER. The notifier can
> observe the socket as not running, skip __unregister_prot_hook(), and
> invalidate the per-socket binding by setting po->ifindex to -1 and clearing
> po->prot_hook.dev. A one-member fanout group can still retain its shared
> fanout hook device pointer. When packet_set_ring() resumes, re-registering
> solely from the stale was_running state can re-add the fanout hook after
> the device has been unregistered.
Thanks for the report with fix.
> Treat po->ifindex == -1 as an invalidated binding after reacquiring
> po->bind_lock. Restore po->num as before, but do not re-register the hook
> if device unregister already detached the socket.
I guess key here is that po->ifindex == -1 is not the normal device
unbound state. That would be po->ifindex 0, and those sockets do need
to be restored.
So this LGTM.
The bug here is having a stale fanout->prot_hook->dev.
If this is the only socket in a fanout group then
__unregister_prot_hook calls __fanout_unlink calls
__dev_remove_pack(&f->prot_hook).
Then later __register_prot_hook calls __fanout_link and
dev_add_pack(&f->prot_hook), rather than checking po->prot_hook.dev,
which packet_notifier modified.
An alternative would be for __fanout_link to check
@@ -1518,7 +1518,8 @@ static void __fanout_link(struct sock *sk, struct packet_sock *po)
rcu_assign_pointer(f->arr[f->num_members], sk);
smp_wmb();
f->num_members++;
- if (f->num_members == 1)
+ if (f->num_members == 1 &&
+ f->prot_hook.dev == po->prot_hook.dev)
dev_add_pack(&f->prot_hook);
spin_unlock(&f->lock);
}
This condition is true when the group is created and checked on every
socket joining the group.
Or even simpler
+ if (f->num_members == 1 && READ_ONCE(po->ifindex) != -1)
But as said the patch as shared should work too.
Patches to net need a Fixes tag:
Fixes: dc99f600698d ("packet: Add fanout support.")
> Signed-off-by: Dominik 'Disconnect3d' Czarnota <dominik.czarnota@trailofbits.com>
I'm not entirely sure what the policy on nicknames is. But at best it
is uncommon. Consider dropping.
> Assisted-by: Codex:gpt-5
> ---
> Bug found and triaged by David Lee from Trail of Bits.
Instead, a Reported-by tag?
> Trail of Bits has a PoC that achieves local privilege escalation using this
> bug on a custom kernel config with CONFIG_LIST_HARDENED disabled, which can
> be shared further if needed.
>
> net/packet/af_packet.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index 8e6f3a734ba0..000000000000 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -4561,7 +4561,11 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
>
> spin_lock(&po->bind_lock);
> WRITE_ONCE(po->num, num);
> - if (was_running)
> + /*
> + * NETDEV_UNREGISTER may have invalidated the binding while bind_lock
> + * was dropped above. Do not re-add a fanout hook to a dead device.
> + */
> + if (was_running && READ_ONCE(po->ifindex) != -1)
> register_prot_hook(sk);
>
> spin_unlock(&po->bind_lock);
> --
> 2.43.0
x
^ permalink raw reply
* [PATCH net v3] ipv4: igmp: remove multicast group from hash table on device destruction
From: Yuyang Huang @ 2026-07-01 23:50 UTC (permalink / raw)
To: Yuyang Huang
Cc: David S. Miller, Cong Wang, David Ahern, Eric Dumazet,
Ido Schimmel, Jakub Kicinski, Paolo Abeni, Simon Horman,
linux-kernel, netdev, stable
When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through
the multicast list and calls ip_ma_put() on each membership, scheduling
them for RCU reclamation. However, they are not unlinked from the device's
multicast hash table (mc_hash).
Since the device remains published in dev->ip_ptr until after
ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash
can still locate and access the multicast group after its refcount is
decremented. If the RCU callback runs and frees the group while a reader is
accessing it, a use-after-free occurs.
Fix this by unlinking the multicast group from mc_hash using
ip_mc_hash_remove() before scheduling it for reclamation.
BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0
Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276
Call Trace:
<IRQ>
dump_stack_lvl+0x67/0x90
print_report+0x175/0x7c0
kasan_report+0x147/0x180
ip_check_mc_rcu+0x149/0x3f0
udp_v4_early_demux+0x36d/0x12d0
ip_rcv_finish_core+0xb8b/0x1390
ip_rcv_finish+0x54/0x120
NF_HOOK+0x213/0x2b0
__netif_receive_skb+0x126/0x340
process_backlog+0x4f2/0xf00
__napi_poll+0x92/0x2c0
net_rx_action+0x583/0xc60
handle_softirqs+0x236/0x7f0
do_softirq+0x57/0x80
</IRQ>
Allocated by task 2239:
kasan_save_track+0x3e/0x80
__kasan_kmalloc+0x72/0x90
____ip_mc_inc_group+0x31a/0xa40
__ip_mc_join_group+0x334/0x3f0
do_ip_setsockopt+0x16fa/0x2010
ip_setsockopt+0x3f/0x90
do_sock_setsockopt+0x1ad/0x300
Freed by task 0:
kasan_save_track+0x3e/0x80
kasan_save_free_info+0x40/0x50
__kasan_slab_free+0x3a/0x60
__rcu_free_sheaf_prepare+0xd4/0x220
rcu_free_sheaf+0x36/0x190
rcu_core+0x8d9/0x12f0
handle_softirqs+0x236/0x7f0
Fixes: e9897071350b ("igmp: hash a hash table to speedup ip_check_mc_rcu()")
Cc: stable@vger.kernel.org
Signed-off-by: Yuyang Huang <yuyanghuang@google.com>
---
v3:
- Target 'net' instead of 'net-next'.
- Add the KASAN Use-After-Free traceback to the commit message.
v2:
- Add Fixes tag in the commit message.
net/ipv4/igmp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index b6337a47c141..d520ea4f6d14 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1922,6 +1922,7 @@ void ip_mc_destroy_dev(struct in_device *in_dev)
#endif
while ((i = rtnl_dereference(in_dev->mc_list)) != NULL) {
+ ip_mc_hash_remove(in_dev, i);
in_dev->mc_list = i->next_rcu;
WRITE_ONCE(in_dev->mc_count, in_dev->mc_count - 1);
ip_mc_clear_src(i);
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* Re: [PATCH iproute2-next v3 2/2] devlink: support u64-array values in devlink param show/set
From: David Ahern @ 2026-07-01 23:53 UTC (permalink / raw)
To: Ratheesh Kannoth, stephen, kuba, linux-kernel, netdev
Cc: andrew+netdev, edumazet, pabeni, jiri
In-Reply-To: <20260701031359.839221-3-rkannoth@marvell.com>
On 6/30/26 9:13 PM, Ratheesh Kannoth wrote:
> Add support for DEVLINK_VAR_ATTR_TYPE_U64_ARRAY parameters that carry
> multiple DEVLINK_ATTR_PARAM_VALUE_DATA attributes. Parse and display
> u64 array values in param show, and accept space- or comma-separated
> u64 values in devlink and port param set commands.
>
> - Show search order
>
> devlink dev param show pci/0002:01:00.0 name npc_srch_order
> pci/0002:01:00.0:
> name npc_srch_order type driver-specific
> values:
> cmode runtime value value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
"value value"? Is that correct or a typo in the commit message?
You are dumping it as a string which for json is wrong -- it should be
an array.
^ permalink raw reply
* [PATCH] net/sched: cake: reject overhead values that underflow length
From: Samuel Moelius @ 2026-07-01 23:56 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Samuel Moelius, Jamal Hadi Salim, Jiri Pirko, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
moderated list:CAKE QDISC, open list:TC subsystem, open list
CAKE accepts signed overhead values and stores them in an s16, but the
adjusted packet length calculation uses unsigned arithmetic. A negative
effective length can therefore wrap to a large value.
Such configurations make rate accounting depend on integer wraparound
rather than on the packet size userspace intended to model. A static
netlink lower bound is not enough because packets reaching CAKE can be
smaller than any reasonable manual-overhead allowance.
Fold the signed overhead adjustment into the existing datapath MPU clamp
so negative adjusted lengths are clamped before link-layer framing
adjustments.
Fixes: a729b7f0bd5b ("sch_cake: Add overhead compensation support to the rate shaper")
Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
---
Changes in v3:
- Adjust how check is performed
Changes in v2:
- Add fixes tag
net/sched/sch_cake.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index a3c185505afc..f78f8e950776 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -1389,10 +1389,7 @@ static u32 cake_calc_overhead(struct cake_sched_data *qd, u32 len, u32 off)
if (qd->min_netlen > len)
WRITE_ONCE(qd->min_netlen, len);
- len += q->rate_overhead;
-
- if (len < q->rate_mpu)
- len = q->rate_mpu;
+ len = max((s32)len + q->rate_overhead, (s32)q->rate_mpu);
if (q->atm_mode == CAKE_ATM_ATM) {
len += 47;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH bpf v3 3/4] selftests/bpf: Adapt sockmap update error handling
From: bot+bpf-ci @ 2026-07-02 0:00 UTC (permalink / raw)
To: mhal, ast, daniel, andrii, eddyz87, memxor, martin.lau, song,
yonghong.song, jolsa, emil, shuah, john.fastabend, jakub,
jiayuan.chen, edumazet, kuniyu, pabeni, willemb, davem, kuba,
horms, cong.wang
Cc: mhal, bpf, linux-kselftest, linux-kernel, netdev, ast, andrii,
daniel, martin.lau, eddyz87, yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260702-sockmap-lookup-udp-leak-v3-3-ff8de8782468@rbox.co>
[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]
> diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c b/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c
> index cc0c68bab907..b87118aab7c4 100644
> --- a/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c
> +++ b/tools/testing/selftests/bpf/prog_tests/sockmap_listen.c
[ ... ]
> @@ -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 if (err) {
> + ASSERT_OK(err, "map_update");
> + }
This isn't a bug, but could the UDP branch just be `else ASSERT_OK(err,
"map_update");` — the `if (err)` guard looks redundant since ASSERT_OK is
a no-op on success?
> close:
> xclose(s);
> }
[ ... ]
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28554911192
^ permalink raw reply
* Re: Ethtool : PRBS feature
From: Lee Trager @ 2026-07-01 23:15 UTC (permalink / raw)
To: Das, Shubham, Alexander Duyck, Andrew Lunn
Cc: Maxime Chevallier, netdev@vger.kernel.org, mkubecek@suse.cz,
D H, Siddaraju, Chintalapalle, Balaji, Lindberg, Magnus,
niklas.damberg@ericsson.com
In-Reply-To: <SN7PR11MB810921E7DA70DB3F6FD1C41DFFE82@SN7PR11MB8109.namprd11.prod.outlook.com>
On 6/29/26 9:15 AM, Das, Shubham wrote:
> Hi All,
>
> Below are the proposed modifications to the UAPI, data structures, and Netlink messages to support PRBS/BERT and test pattern configuration.
>
> diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml
> index 5e9135e3774f..cb11e139dd81 100644
> --- a/Documentation/netlink/specs/ethtool.yaml
> +++ b/Documentation/netlink/specs/ethtool.yaml
> @@ -30,6 +30,36 @@ definitions:
> + name: phy-test-pattern
> + enum-name: phy-test-pattern
> + type: enum
> + name-prefix: phy-test-pattern-
> + doc: PRBS and other PHY test patterns
> + entries:
> + - off
> + - prbs7
> + - prbs9
> + - prbs11
fbnic supports a number of other tests as well. Getting the full list of
common PRBS tests codified would be ideal
- prbs11.0
- prbs11.1
- prbs11.2
- prbs11.3
> + - prbs13
- prbs13.0
- prbs13.1
- prbs13.2
- prbs13.3
> + - prbs15
- prbs16
> + - prbs23
> + - prbs31
- prbs32
> + - ssprq
> + - prbs13q
> + - prbs31q
> + - square
> + -
> + name: phy-test-action
> + enum-name: phy-test-action
Each lane and each direction is a completely separate test with its own
test of statistics. The test is actually verified on the Rx side, Tx is
your generator so you won't have data to collect. So when you run PRBS
testing on a 2 lane NIC you are actually running 4 independent tests.
While its fine to have a shortcut to run the same test on all lanes we
absolutely need a way to run tests per lane and the ability to choose
Rx, Tx, or both.
> + type: enum
> + name-prefix: phy-test-action-
> + doc: Actions for PHY BERT test control
> + entries:
> + - none
> + - start
> + - stop
> + - stats
I wouldn't consider stats a phy-test action. It shouldn't change the
state of the NIC at all. I would just add phy-test-stats as set of
standard ethtool statistics.
> -
> name: header-flags
> type: flags
> @@ -1818,6 +1848,58 @@ attribute-sets:
> type: u32
> enum: loopback-type
>
> + -
> + name: phy-test
> + attr-cnt-name: __ethtool-a-phy-test-cnt
> + doc: |
> + PHY test configuration for pattern generation/checking,
> + BERT (Bit Error Rate Test), and statistics.
> + attributes:
> + -
> + name: unspec
> + type: unused
> + value: 0
> + -
> + name: header
> + type: nest
> + nested-attributes: header
> + -
> + name: tx-pattern
> + type: u32
> + doc: TX test pattern type (PRBS or square wave)
> + enum: phy-test-pattern
> + -
> + name: rx-pattern
> + type: u32
> + doc: RX checker pattern type (PRBS or square wave)
> + enum: phy-test-pattern
> + -
> + name: bert-action
> + type: u32
> + doc: BERT test start/stop/stats
> + enum: phy-test-action
> + -
> + name: inject-error-count
> + type: u32
> + doc: |
> + Number of errors to inject. Each invocation injects the specified
> + number of bit errors into the data stream.
> + -
> + name: ber-lock-status
> + type: u8
> + doc: PRBS lock status (1=locked, 0=not locked)
> + -
> + name: ber-error-count
> + type: u64
> + doc: BERT bit error count
> + -
> + name: ber-total-bits-sent
> + type: u64
> + doc: BERT total bits tested
> + -
> + name: supported-test-patterns
> + type: u32
> + doc: Bitmask of supported test patterns
Again all of this needs to be per lane.
>
> -
> name: phy-tunable
> @@ -2924,6 +3006,53 @@ operations:
> - header
> - enabled
> - type
> + -
> + name: phy-test-act
> + doc: |
> + Configure PHY test parameters. Each attribute is optional and only
> + specified attributes are applied. TX/RX patterns are set on the
> + local port. BERT and error injection operate on the receiver port.
> + When bert-action is stats, a reply with BERT counters is returned.
> + Typical workflow:
> + ethtool --phy-test eth1 tx-pattern prbs7 (TX side)
> + ethtool --phy-test eth2 rx-pattern prbs7 (RX side)
> + ethtool --phy-test eth2 bert start (start BERT on RX)
> + ethtool --phy-test eth2 bert stats (read counters and lock status)
> + ethtool --phy-test eth2 bert stop (stop BERT)
> +
> + attribute-set: phy-test
> +
> + do:
> + request:
> + attributes:
> + - header
> + - tx-pattern
> + - rx-pattern
> + - bert-action
> + - inject-error-count
> + reply:
> + attributes:
> + - header
> + - ber-lock-status
> + - ber-error-count
> + - ber-total-bits-sent
> + -
> + name: phy-test-get
> + doc: |
> + Get PHY test configuration status and supported patterns.
> +
> + attribute-set: phy-test
> +
> + do:
> + request:
> + attributes:
> + - header
> + reply:
> + attributes:
> + - header
> + - tx-pattern
> + - rx-pattern
> + - supported-test-patterns
>
> mcast-groups:
> list:
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 1ac85b8aebd7..3bcca506cf7b 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
>
> +/* Bitmask of which ethtool_phy_test fields were explicitly specified */
> +#define PHY_TEST_CMD_TX_PATTERN BIT(0)
> +#define PHY_TEST_CMD_RX_PATTERN BIT(1)
> +#define PHY_TEST_CMD_BERT_ACTION BIT(2)
> +#define PHY_TEST_CMD_INJECT_COUNT BIT(3)
> +
> +/**
> + * struct ethtool_phy_test - PHY test configuration and status
> + * @cmd: Bitmask of PHY_TEST_CMD_* indicating which fields to apply (SET)
> + * @tx_pattern: TX test pattern
> + * @rx_pattern: RX checker pattern
> + * @bert_action: BERT start/stop/stats action
> + * @inject_error_count: Number of bit errors to inject (SET only)
> + * @supported_test_patterns: Bitmask of supported patterns (GET only)
> + * @ber_lock_status: BER lock status 1=locked, 0=not locked (GET only)
> + * @ber_error_count: BERT bit error count (GET only)
> + * @ber_total_bits_sent: BERT total bits tested (GET only)
> + */
> +struct ethtool_phy_test {
> + u32 cmd;
> + enum phy_test_pattern tx_pattern;
> + enum phy_test_pattern rx_pattern;
> + enum phy_test_action bert_action;
> + u32 inject_error_count;
> + u32 supported_test_patterns;
> + u8 ber_lock_status;
> + u64 ber_error_count;
> + u64 ber_total_bits_sent;
> +};
> +
> /**
> * struct ethtool_ops - optional netdev operations
> * @supported_input_xfrm: supported types of input xfrm from %RXH_XFRM_*.
> @@ -1091,7 +1121,8 @@ struct ethtool_loopback {
> * @get_mm: Query the 802.3 MAC Merge layer state.
> * @set_mm: Set the 802.3 MAC Merge layer parameters.
> * @get_mm_stats: Query the 802.3 MAC Merge layer statistics.
> - *
> + * @get_phy_test: Get PHY test status, patterns, and BERT counters.
> + * @set_phy_test: Configure PHY test (pattern, BERT, error injection). *
> * All operations are optional (i.e. the function pointer may be set
> * to %NULL) and callers must take this into account. Callers must
> * hold the RTNL lock.
> @@ -1260,6 +1291,10 @@ struct ethtool_ops {
> void (*get_mm_stats)(struct net_device *dev, struct ethtool_mm_stats *stats);
> + int (*get_phy_test)(struct net_device *dev,
> + struct ethtool_phy_test *test);
> + int (*set_phy_test)(struct net_device *dev,
> + struct ethtool_phy_test *test);
> };
>
>
> The 'tx_prbs' and 'rx_prbs' command parameters have been renamed to 'tx_pattern' and 'rx_pattern' to allow support
> for additional test patterns defined in the RFC, such as square patterns, in addition to PRBS.
>
> The statistics have been moved to the 'ber' test command.
>
> I also think it would be better to expose 'tx_pattern' and 'rx_pattern' as separate commands,
> since the TX and RX ports can be different. They are only the same when operating in loopback mode.
>
>
>> You need to think about the units for inject errors. There is no floating point support. Also, is this corrupt packets?
>> Or single bit flips in the stream? It needs to be well defined what it actually means. The driver can then convert it to whatever the hardware supports. How does 802.3 specify this?
> I believe it is not mentioned in IEEE specs, But it will be helpful in debug in both data and PRBS mode.
> Maybe we can have number of errors injected in steam when we issue command rather than error rate ?
>
>
>> Traditionally, Unix does not offer a way to clear statistic counters back to zero. So i'm not sure about clear-stats.
>> We also need to think about hardware which does not support that. And there is locking issues, can the stats be cleared while a test is active?
> I think we can auto clear in PHY FW or in implementation when we start the test.
>
> Also, as previously suggested we need new status to indicate device is under test for net device.
>
> - Shubham D
>
>> -----Original Message-----
>> From: Alexander Duyck <alexander.duyck@gmail.com>
>> Sent: 24 June 2026 21:06
>> To: Andrew Lunn <andrew@lunn.ch>
>> Cc: Lee Trager <lee@trager.us>; Das, Shubham <shubham.das@intel.com>;
>> Maxime Chevallier <maxime.chevallier@bootlin.com>; netdev@vger.kernel.org;
>> mkubecek@suse.cz; D H, Siddaraju <siddaraju.dh@intel.com>; Chintalapalle,
>> Balaji <balaji.chintalapalle@intel.com>; Lindberg, Magnus
>> <magnus.k.lindberg@ericsson.com>; niklas.damberg@ericsson.com
>> Subject: Re: Ethtool : PRBS feature
>>
>> On Tue, Jun 23, 2026 at 7:30 PM Andrew Lunn <andrew@lunn.ch> wrote:
>>>> To avoid race conditions, maybe some of these commands need combining.
>>>> ethtool --phy-test eth1 tx-prbs prbs7 rx-prbs prbs7 bert start
>>>>
>>>> The configuration is then atomic, with respect to the uAPI, so we
>>>> don't get two users configuring it at the same time, ending up with a
>>>> messed up configuration.
>>>>
>>>> Testing consumes the link so you really don't want anything done to
>>>> the netdev while testing is running. fbnic does the following.
>>>>
>>>> 1. Testing cannot start when the link is up
>>> That is not going to work in the generic case. Many MAC drivers don't
>>> bind to there PCS or PHY until open() is called. So there is no way to
>>> pass the uAPI calls onto the PCS or PHY if the interface is down.
>>> There are also some MACs which connect to multiple PCSs, and there can
>>> be multiple PHYs. So you need to somehow indicate which PCS/PHY should
>>> perform the PRBS. There was a discussion about loopback recently,
>>> which has the same issue, you can perform loopback testing in multiple
>>> places. So i expect the same concept will be used for this.
>> I would think something like this would still be usable. You would just need to
>> specify the phy address and possibly device address in the case that you support
>> doing such testing at multiple layers.
>> Basically it would be up to the driver to provide a way to connect the request with
>> the desired interface. I would imagine something similar is the case for the
>> loopback handling since there are so many layers where you can hairpin things
>> back to the port it came in on.
>>
>>>> 2. Once testing starts the driver removes the netdev to prevent use.
>>>> The netdev is only added back when testing stops. The upstream
>>>> solution will need something that can keep the netdev but lock
>>>> everything down while testing is running.
>>> Probably IF_OPER_TESTING would be part of this. If the interface is in
>>> this state, you want many other things blocked. However, probably
>>> ksettings get/set need to work, so you can force the link into a
>>> specific mode.
>> I would imagine it depends on if you want to enforce ordering on this or not. I
>> would say the set would probably need to be blocked as you wouldn't normally
>> want to be changing the setting in the middle of a test as it would cause the error
>> stats to climb quickly.
>>
>>>> 3. Once testing starts you cannot change the test, even on an
>>>> individual lane basis. You must stop testing first.
>>>>
>>>>
>>>> Traditionally, Unix does not offer a way to clear statistic counters
>>>> back to zero. So i'm not sure about clear-stats. We also need to think
>>>> about hardware which does not support that. And there is locking
>>>> issues, can the stats be cleared while a test is active?
>>>>
>>>> fbnic actually has separate registers for PRBS test results. Results
>>>> do need to be clean between runs but I never created an explicit
>>>> clear interface. Firmware automatically reset the registers when a
>>>> new test was started. This also allows results to be viewed after testing has
>> stopped.
>>> We should really take 802.3 as the model, but i've not had time yet to
>>> read what it says about the statistics.
>> I think most of this is all called out in the IEEE 802.3-2022 spec under section
>> 45.2.1.169 - 45.2.1.174. Basically the ability and controls live in the 1500 range,
>> Tx error statistics in the 1600, and Rx statistics in the 1700 range.
>>
>>>> Reading results was a little tricky due to roll over between two
>>>> 32bit registers.
>>> 802.3 is make this even more interesting, since those registers are 16
>>> bits.
>> Yeah, normally to deal with something like that we would likely be looking at
>> having to maintain a fairly high read frequency. Although in theory the error
>> counts shouldn't be climbing that fast anyway. The spec calls out that the registers
>> are clear on read and held at ~0 in the event of overflow which would be a failing
>> case for any reasonable test anyway.
>>
>>>> When I spoke to hardware engineers at Meta they did not want a
>>>> timeout. Testing often occurred over days, so they wanted to be able
>>>> to start it and explicitly stop it. I'm not against a time out but I do think it
>> should be optional.
>>>> Since PRBS testing is handled by firmware one safety measure I added
>>>> is if firmware lost contact with the host testing was automatically
>>>> stopped and TX FIR values were reset to factory. This ensured that
>>>> the NIC won't get stuck in testing and on initialization the driver
>>>> doesn't have to worry about testing state.
>>> That will work for firmware, but not when Linux is driving the
>>> hardware. I don't know if netlink will allow it, or if RTNL will get
>>> in the way etc, but it could be we actually don't want a start and
>>> stop commands at all, it is a blocking netlink call, and the test runs
>>> until the user space process closes the socket?
>> What we would probably need to do is look at testing as a state rather than an
>> operation. Basically the NIC would be put into the testing state and as a result it
>> would just be sitting there emitting whatever test pattern it is supposed to emit,
>> and validating it is receiving the pattern it expects to receive.
>>
>> The statistics could probably just be a subset of the PHY statistics that could be
>> collected separately. Actually now that I think about it I wonder if we couldn't
>> look at putting together the interface similar to how we currently handle FEC
>> where you have the --set-fec interface to configure things and the --show-fec
>> interface with the -I option to show the current state and also dump the
>> statistics.
^ permalink raw reply
* [PATCH v3] net/sched: cake: reject overhead values that underflow length
From: Samuel Moelius @ 2026-07-02 0:07 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Samuel Moelius, Jamal Hadi Salim, Jiri Pirko, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
moderated list:CAKE QDISC, open list:TC subsystem, open list
CAKE accepts signed overhead values and stores them in an s16, but the
adjusted packet length calculation uses unsigned arithmetic. A negative
effective length can therefore wrap to a large value.
Such configurations make rate accounting depend on integer wraparound
rather than on the packet size userspace intended to model. A static
netlink lower bound is not enough because packets reaching CAKE can be
smaller than any reasonable manual-overhead allowance.
Fold the signed overhead adjustment into the existing datapath MPU clamp
so negative adjusted lengths are clamped before link-layer framing
adjustments.
Fixes: a729b7f0bd5b ("sch_cake: Add overhead compensation support to the rate shaper")
Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
---
Changes in v3:
- Adjust how check is performed
- Resend with v3 suffix
Changes in v2:
- Add fixes tag
net/sched/sch_cake.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/sched/sch_cake.c b/net/sched/sch_cake.c
index a3c185505afc..f78f8e950776 100644
--- a/net/sched/sch_cake.c
+++ b/net/sched/sch_cake.c
@@ -1389,10 +1389,7 @@ static u32 cake_calc_overhead(struct cake_sched_data *qd, u32 len, u32 off)
if (qd->min_netlen > len)
WRITE_ONCE(qd->min_netlen, len);
- len += q->rate_overhead;
-
- if (len < q->rate_mpu)
- len = q->rate_mpu;
+ len = max((s32)len + q->rate_overhead, (s32)q->rate_mpu);
if (q->atm_mode == CAKE_ATM_ATM) {
len += 47;
--
2.43.0
^ permalink raw reply related
* Re: [RFC] connectat()/bindat() or an alternative design
From: Cong Wang @ 2026-07-02 0:32 UTC (permalink / raw)
To: John Ericson
Cc: Li Chen, Andy Lutomirski, Christian Brauner, Jens Axboe,
network dev, linux-fsdevel
In-Reply-To: <e396ce86-ec84-4189-9da2-98af7cfa6c41@app.fastmail.com>
On Tue, Jun 30, 2026 at 04:22:25PM -0400, John Ericson wrote:
> I'm bumping this and adding new recipients again in light of the
> discussion happening elsewhere in
> <https://lore.kernel.org/all/a49ce818-f38d-41b0-bbf7-80b8aad998b1@app.fastmail.com/>.
> I don't want to count my chickens before they are hatched, but it is
> looking to me like a consensus in that thread is building around the
> ability to opt into intentionally empty/unusable root and working
> directories (at least with nullfs, maybe but less likely with other
> mechanisms instead).
>
> That new functionality concretizes the motivation for what I am
> proposing in this thread: in such a world, there is little to no point
> binding listening sockets in the file system, because the containing
> directory would have to be conveyed by file descriptor anyways --- might
> as well just directly convey the socket to connect to by file
> descriptor. Likewise, abstract sockets are not appealing, because the
> abstract socket namespace is either too coarse-grained (leaking info in
> the same way root/cwd would), or too cumbersome to keep it from leaking.
>
> To recap (with some slight changes, like renames), my latest proposal (a
> new version, not either of the two variations in the original email) is
> new syscalls `bind_unix_anon` and `connectat`, supporting a workflow
> like this:
>
> /* server */
> int lfd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
> int addrfd = bind_unix_anon(
> lfd,
> /*flags, for the future*/0);
> listen(lfd, 64);
>
> /* client, handed `addrfd` */
> int cfd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
> connectat(addrfd, cfd, AT_EMPTY_PATH);
>
> Or, more radically, `bind_unix_anon` and `connectat` could let one skip
> the initial `socket` calls by returning those new sockets directly:
Hm? Why not just setsockopt()? Something like:
struct unix_lookup_ctx {
int dirfd;
__u64 resolve_flags; /* RESOLVE_BENEATH, RESOLVE_NO_SYMLINKS, etc. */
__u64 op_flags; /* maybe future */
};
setsockopt(fd, SOL_UNIX, UNIX_NEXT_LOOKUP,
&ctx, sizeof(ctx));
bind(fd, (struct sockaddr *)&addr, addrlen);
/* or connect(fd, ...) */
Zero new syscall is needed.
Regards,
Cong
^ permalink raw reply
* Re: [PATCH v2 6.6.y/6.12.y/6.18.y] af_unix: Set gc_in_progress to true in unix_gc().
From: Sasha Levin @ 2026-07-02 0:38 UTC (permalink / raw)
To: stable
Cc: Sasha Levin, kuniyu, kuba, pabeni, davem, edumazet, netdev,
sysroot314
In-Reply-To: <20260701065306.281809-1-sysroot314@gmail.com>
> [ Upstream commit d82ba05263c69fa2437fe93e4e561cc40f4c03af ]
>
> Igor Ushakov reported that unix_gc() could run with gc_in_progress
> being false if the work is scheduled while running:
Queued for 6.18.y, 6.12.y, and 6.6.y, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 5.10] net: cpsw_new: Fix potential unregister of netdev that has not been registered yet
From: Sasha Levin @ 2026-07-02 0:38 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman
Cc: Sasha Levin, Elizaveta Tereshkina, Grygorii Strashko,
David S. Miller, Jakub Kicinski, Kevin Hao, Alexander Sverdlin,
Wenshan Lan, Ilias Apalodimas, Murali Karicheri, linux-omap,
netdev, linux-kernel, lvc-project
In-Reply-To: <20260630200717.1994713-1-etereshkina@astralinux.ru>
> If an error occurs during register_netdev() for the first MAC in
> cpsw_register_ports(), even though cpsw->slaves[0].ndev is set to NULL,
> cpsw->slaves[1].ndev would remain unchanged. This could later cause
> cpsw_unregister_ports() to attempt unregistering the second MAC.
Queued for 5.10.y, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 5.10.y] net/sched: fix pedit partial COW leading to page cache corruption
From: Sasha Levin @ 2026-07-02 0:38 UTC (permalink / raw)
To: dominique.martinet, stable
Cc: Sasha Levin, Jamal Hadi Salim, Cong Wang, Jiri Pirko,
David S. Miller, Jakub Kicinski, Mat Martineau, Paolo Abeni,
netdev, linux-kernel, Rajat Gupta, Yiming Qian, Keenan Dong,
Han Guidong, Zhang Cen, Davide Caratti,
Toke Høiland-Jørgensen, Victor Nogueira
In-Reply-To: <20260630-cve-2026-46331-v1-2-c1986f356f26@atmark-techno.com>
> [Dominique: plenty of context conflict but the code itself could still
> mostly be used]
Thanks! However, the same upstream fix (899ee91156e5) is already queued for
5.10.y via Wentao Guan's backport, which brings in the act_pedit
RCU/percpu-stats prerequisites first and then applies the fix nearly
verbatim.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 5.10.y] net/sched: fix pedit partial COW leading to page cache corruption
From: Dominique Martinet @ 2026-07-02 1:00 UTC (permalink / raw)
To: Sasha Levin
Cc: stable, Jamal Hadi Salim, Cong Wang, Jiri Pirko, David S. Miller,
Jakub Kicinski, Mat Martineau, Paolo Abeni, netdev, linux-kernel,
Rajat Gupta, Yiming Qian, Keenan Dong, Han Guidong, Zhang Cen,
Davide Caratti, Toke Høiland-Jørgensen, Victor Nogueira
In-Reply-To: <stable-reply-pedit-cow-510-20260701193800@kernel.org>
Sasha Levin wrote on Wed, Jul 01, 2026 at 08:38:34PM -0400:
> > [Dominique: plenty of context conflict but the code itself could still
> > mostly be used]
>
> Thanks! However, the same upstream fix (899ee91156e5) is already queued for
> 5.10.y via Wentao Guan's backport, which brings in the act_pedit
> RCU/percpu-stats prerequisites first and then applies the fix nearly
> verbatim.
Oh, thanks!
Sorry for the noise, I'll remember to check next time.
--
Dominique
^ permalink raw reply
* [PATCH ipsec] xfrm6: clear dst.dev on error to avoid double netdev_put in xfrm6_fill_dst()
From: Xiang Mei (Microsoft) @ 2026-07-02 1:05 UTC (permalink / raw)
To: Steffen Klassert, Herbert Xu, David S . Miller, netdev
Cc: Simon Horman, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
AutonomousCodeSecurity, tgopinath, kys, Xiang Mei (Microsoft)
On the error path where in6_dev_get(dev) returns NULL, xfrm6_fill_dst()
releases the device reference with netdev_put() but leaves
xdst->u.dst.dev set. dst_destroy() later calls netdev_put(dst->dev)
again, so the same net_device reference is released twice, underflowing
its refcount (ref_tracker WARNING + "unregister_netdevice: waiting for
<dev> to become free").
Clear xdst->u.dst.dev after the netdev_put(), the same way the XFRM
device-offload paths xfrm_dev_state_add() and xfrm_dev_policy_add() in
net/xfrm/xfrm_device.c NULL ->dev when releasing the reference on error.
ref_tracker: reference already released.
ref_tracker: allocated in:
xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:86)
...
udpv6_sendmsg (net/ipv6/udp.c:1696)
...
ref_tracker: freed in:
xfrm6_fill_dst (net/ipv6/xfrm6_policy.c:90)
...
WARNING: lib/ref_tracker.c:322 at ref_tracker_free+0x58b/0x780
dst_destroy (net/core/dst.c:115)
rcu_core
handle_softirqs
...
Fixes: 84c4a9dfbf43 ("xfrm6: release dev before returning error")
Reported-by: AutonomousCodeSecurity@microsoft.com
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
---
net/ipv6/xfrm6_policy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/xfrm6_policy.c b/net/ipv6/xfrm6_policy.c
index 125ea9a5b8a0..3b749475f6ed 100644
--- a/net/ipv6/xfrm6_policy.c
+++ b/net/ipv6/xfrm6_policy.c
@@ -88,6 +88,7 @@ static int xfrm6_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,
xdst->u.rt6.rt6i_idev = in6_dev_get(dev);
if (!xdst->u.rt6.rt6i_idev) {
netdev_put(dev, &xdst->u.dst.dev_tracker);
+ xdst->u.dst.dev = NULL;
return -ENODEV;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] af_unix: mark MSG_SPLICE_PAGES frags shared
From: 钱一铭 @ 2026-07-02 2:05 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: security, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev, linux-kernel, lingchen5202005
In-Reply-To: <CAAVpQUC_EcpFf9GmNnD07KhFAOcPhrCa5xNF-idz0CsB=TJV9A@mail.gmail.com>
Thanks, I agree plain AF_UNIX does not by itself provide the writer side.
The concern was that MSG_SPLICE_PAGES imports externally owned pages into
skb frags, while unlike TCP/UDP/KCM this path does not mark them with
SKBFL_SHARED_FRAG. I checked the AF_UNIX sockmap path as well, but I do
not currently have a concrete in-tree chain where those frags reach a
writer that skips COW based on skb_has_shared_frag().
So this should be treated as a defensive consistency cleanup rather than
a security fix. I will drop the Fixes tag and the duplicate Reported-by
tags in v2.
Kuniyuki Iwashima <kuniyu@google.com> 于2026年6月30日周二 23:51写道：
>
> On Tue, Jun 30, 2026 at 12:06 AM Yiming Qian <yimingqian591@gmail.com> wrote:
> >
> > unix_stream_sendmsg() splices external pages directly into skb frags when
> > MSG_SPLICE_PAGES is set, but it does not propagate SKBFL_SHARED_FRAG
> > afterward.
>
> I think it doesn't matter with the plain AF_UNIX.
>
> Please elaborate on the scenario where this could be a problem.
> e.g. sockmap ?
>
>
> >
> > That leaves later writers without the shared-frag marker even though the
> > skb still references externally owned pages.
> >
> > Set the marker after a successful skb_splice_from_iter() call.
> >
> > Fixes: a0dbf5f818f90 ("af_unix: Support MSG_SPLICE_PAGES")
> > Reported-by: Yiming Qian <yimingqian591@gmail.com>
> > Reported-by: Can Liu <lingchen5202005@gmail.com>
>
> Reported-by is not needed when it's identical to SOB tag.
>
>
> > Signed-off-by: Yiming Qian <yimingqian591@gmail.com>
> > Signed-off-by: Can Liu <lingchen5202005@gmail.com>
> > ---
> > net/unix/af_unix.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> > index f7a9d55eee8a1..f2cd0f8ec0914 100644
> > --- a/net/unix/af_unix.c
> > +++ b/net/unix/af_unix.c
> > @@ -2458,6 +2458,7 @@ static int unix_stream_sendmsg(struct socket *sock, struct msghdr *msg,
> > goto out_free;
> >
> > size = err;
> > + skb_shinfo(skb)->flags |= SKBFL_SHARED_FRAG;
> > refcount_add(size, &sk->sk_wmem_alloc);
> > } else {
> > skb_put(skb, size - data_len);
> > --
> > 2.34.1
^ 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