* Re: [PATCH net v3 8/8] xsk: don't support AF_XDP on 32-bit architectures
From: David Laight @ 2026-04-22 20:27 UTC (permalink / raw)
To: Jason Xing
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, bpf, netdev, Jason Xing
In-Reply-To: <20260422033650.68457-9-kerneljasonxing@gmail.com>
On Wed, 22 Apr 2026 11:36:50 +0800
Jason Xing <kerneljasonxing@gmail.com> wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> In copy mode TX, xsk_skb_destructor_set_addr() stores the 64-bit
> descriptor address into skb_shinfo(skb)->destructor_arg (void *) via a
> uintptr_t cast:
>
> skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t)addr | 0x1UL);
>
> On 32-bit architectures uintptr_t is 32 bits, so the upper 32 bits of
> the descriptor address are silently dropped. In XDP_ZEROCOPY unaligned
> mode the chunk offset is encoded in bits 48-63 of the descriptor
> address (XSK_UNALIGNED_BUF_OFFSET_SHIFT = 48), meaning the offset is
> lost entirely. The completion queue then returns a truncated address to
> userspace, making buffer recycling impossible.
I had a look at how this is used.
I suspect that XSK_UNALIGNED_BUF_OFFSET_SHIFT can just be made smaller.
The 'addr' isn't really a normal address of any kind, it is a really
and offset into an array made up of pages of memory.
The actual address (kernel virtual of dma) is generated by:
ptr->array[addr >> PAGE_SHIFT] + addr & ~PAGE_MASK
(after removing the unaligned chunk offset from 'addr').
It is actually quite likely that there are enough free high bits
even in 32bit mode.
David
>
> Since we hear no one is using AF_XDP on 32-bit arch, we decided to
> strictly stop supporting it at compile time.
>
> Closes: https://lore.kernel.org/all/20260419045824.D9E5EC2BCAF@smtp.kernel.org/
> Fixes: 0ebc27a4c67d ("xsk: avoid data corruption on cq descriptor number")
> Suggested-by: Stanislav Fomichev <sdf@fomichev.me>
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> net/xdp/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/xdp/Kconfig b/net/xdp/Kconfig
> index 71af2febe72a..819aa5795f50 100644
> --- a/net/xdp/Kconfig
> +++ b/net/xdp/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
> config XDP_SOCKETS
> bool "XDP sockets"
> - depends on BPF_SYSCALL
> + depends on BPF_SYSCALL && 64BIT
> default n
> help
> XDP sockets allows a channel between XDP programs and
^ permalink raw reply
* Re: [PATCH bpf-next v4 0/4] bpf: Reject TCP_NODELAY in TCP header option
From: patchwork-bot+netdevbpf @ 2026-04-22 20:36 UTC (permalink / raw)
To: KaFai Wan
Cc: ast, daniel, john.fastabend, andrii, martin.lau, eddyz87, memxor,
song, yonghong.song, jolsa, sdf, davem, edumazet, kuba, pabeni,
horms, dsahern, shuah, ihor.solodrai, jiayuan.chen, hoyeon.lee,
ameryhung, bpf, linux-kernel, netdev, linux-kselftest
In-Reply-To: <20260421155804.135786-1-kafai.wan@linux.dev>
Hello:
This series was applied to bpf/bpf.git (master)
by Martin KaFai Lau <martin.lau@kernel.org>:
On Tue, 21 Apr 2026 23:58:00 +0800 you wrote:
> This small patchset is about avoid infinite recursion in TCP header option callbacks
> and bpf-tcp-cc callbacks via TCP_NODELAY setsockopt.
>
> v4:
> - Fix the test case for TCP header option callbacks (Martin and Jiayuan)
> - Reject TCP_NODELAY in bpf-tcp-cc callbacks (AI and Martin)
> - Add a test case for bpf-tcp-cc
>
> [...]
Here is the summary with links:
- [bpf-next,v4,1/4] bpf: Reject TCP_NODELAY in TCP header option callbacks
https://git.kernel.org/bpf/bpf/c/846c76ecc029
- [bpf-next,v4,2/4] bpf: Reject TCP_NODELAY in bpf-tcp-cc
https://git.kernel.org/bpf/bpf/c/54377fcab51f
- [bpf-next,v4,3/4] selftests/bpf: Test TCP_NODELAY in TCP hdr opt callbacks
https://git.kernel.org/bpf/bpf/c/52b6b5334924
- [bpf-next,v4,4/4] selftests/bpf: Verify bpf-tcp-cc rejects TCP_NODELAY
https://git.kernel.org/bpf/bpf/c/2c7e33f1fc2e
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH bpf v5 1/2] bpf: guard sock_ops rtt_min against non-locked tcp_sock
From: Martin KaFai Lau @ 2026-04-22 21:03 UTC (permalink / raw)
To: Werner Kasselman
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org,
stable@vger.kernel.org, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
Stanislav Fomichev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Lawrence Brakmo, open list
In-Reply-To: <20260420230030.2802408-2-werner@verivus.com>
On Mon, Apr 20, 2026 at 11:00:35PM +0000, Werner Kasselman wrote:
> sock_ops_convert_ctx_access() reads rtt_min without the is_locked_tcp_sock guard used for every other tcp_sock field. On request_sock-backed sock_ops callbacks, sk points at a tcp_request_sock and the converted load reads past the end of the allocation.
>
> Extract the guarded tcp_sock field load sequence into SOCK_OPS_LOAD_TCP_SOCK_FIELD() and use it for the rtt_min access after computing the sub-field offset with offsetof(struct minmax_sample, v). Reusing the shared helper keeps rtt_min aligned with the other guarded tcp_sock field loads and preserves the dst_reg == src_reg failure path that zeros the destination register when the guard fails.
I think some formatting instruction was not given to the AI this time and
no human bothered to look at the formatting of the commit message
before posting?
^ permalink raw reply
* Re: [PATCH bpf v5 2/2] selftests/bpf: cover same-reg sock_ops rtt_min request_sock access
From: Martin KaFai Lau @ 2026-04-22 21:11 UTC (permalink / raw)
To: Werner Kasselman
Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, Andrii Nakryiko,
Eduard Zingerman, Alexei Starovoitov, Daniel Borkmann,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
Shuah Khan, open list:KERNEL SELFTEST FRAMEWORK, open list
In-Reply-To: <20260420230030.2802408-3-werner@verivus.com>
On Mon, Apr 20, 2026 at 11:00:37PM +0000, Werner Kasselman wrote:
> Add a tcpbpf sock_ops selftest that forces a same-register ctx->rtt_min read on request_sock-backed callbacks and verifies the observed value is zero.
>
> This covers the dst_reg == src_reg path that the previous ctx_rewrite-only test did not exercise.
Same formatting issue.
>
> Signed-off-by: Werner Kasselman <werner@verivus.com>
> ---
> .../testing/selftests/bpf/prog_tests/tcpbpf_user.c | 4 ++++
> .../testing/selftests/bpf/progs/test_tcpbpf_kern.c | 14 ++++++++++++++
> tools/testing/selftests/bpf/test_tcpbpf.h | 2 ++
> 3 files changed, 20 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/tcpbpf_user.c b/tools/testing/selftests/bpf/prog_tests/tcpbpf_user.c
> index 7e8fe1bad03f..1b08e49327d0 100644
> --- a/tools/testing/selftests/bpf/prog_tests/tcpbpf_user.c
> +++ b/tools/testing/selftests/bpf/prog_tests/tcpbpf_user.c
> @@ -42,6 +42,10 @@ static void verify_result(struct tcpbpf_globals *result)
> /* check getsockopt for window_clamp */
> ASSERT_EQ(result->window_clamp_client, 9216, "window_clamp_client");
> ASSERT_EQ(result->window_clamp_server, 9216, "window_clamp_server");
> +
> + /* check same-reg rtt_min read on request_sock-backed callbacks */
> + ASSERT_NEQ(result->rtt_min_req_seen, 0, "rtt_min_req_seen");
> + ASSERT_EQ(result->rtt_min_req_nonzero, 0, "rtt_min_req_nonzero");
> }
>
> static void run_test(struct tcpbpf_globals *result)
> diff --git a/tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c b/tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c
> index 6935f32eeb8f..a488b282b5dd 100644
> --- a/tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c
> +++ b/tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c
> @@ -33,6 +33,7 @@ int bpf_testcb(struct bpf_sock_ops *skops)
> {
> char header[sizeof(struct ipv6hdr) + sizeof(struct tcphdr)];
> struct bpf_sock_ops *reuse = skops;
> + long rtt_min = (long)skops;
It is overly smart to test the same dst_reg == src_reg.
A new test has just been added to test it in a cleaner way.
pw-bot: cr
You haven't spent time to take a look of the patches first.
Please don't post again. I will stop reviewing your patches from now.
^ permalink raw reply
* Re: [PATCH bpf-next v3 2/9] bpf: Assign reg->id when getting referenced kptr from ctx
From: Eduard Zingerman @ 2026-04-22 21:46 UTC (permalink / raw)
To: Amery Hung, bpf
Cc: netdev, alexei.starovoitov, andrii, daniel, memxor, martin.lau,
mykyta.yatsenko5, kernel-team
In-Reply-To: <20260421221016.2967924-3-ameryhung@gmail.com>
On Tue, 2026-04-21 at 15:10 -0700, Amery Hung wrote:
> Assign reg->id when getting referenced kptr from read program context
> to be consistent with R0 of KF_ACQUIRE kfunc. skb dynptr will track the
> referenced skb in qdisc programs using a new field reg->parent_id in
> a later patch.
>
> Signed-off-by: Amery Hung <ameryhung@gmail.com>
> ---
> kernel/bpf/verifier.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 41e4ea41c72e..93003a2a96b0 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -6448,8 +6448,6 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> } else {
> mark_reg_known_zero(env, regs,
> value_regno);
> - if (type_may_be_null(info.reg_type))
> - regs[value_regno].id = ++env->id_gen;
> /* A load of ctx field could have different
> * actual load size with the one encoded in the
> * insn. When the dst is PTR, it is for sure not
> @@ -6459,8 +6457,11 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> if (base_type(info.reg_type) == PTR_TO_BTF_ID) {
> regs[value_regno].btf = info.btf;
> regs[value_regno].btf_id = info.btf_id;
> + regs[value_regno].id = info.ref_obj_id;
> regs[value_regno].ref_obj_id = info.ref_obj_id;
> }
Hi Amery,
Could you please help me double-check my understanding of this change?
It adds a new behavior, if struct_ops method parameter is annotated
with __ref, then if a field is read from such struct_ops context
the destination register would now have it's .id == ref_obj_id
allocated for the parameter at the beginning of do_check().
E.g. for `rB = *(T *)(rA + off)`, if `rA` is a pointer to struct_ops
context and parameter corresponding to `off` has `__ref` annotation
the `rB.id` will be assigned, contrary to old behavior, when it remained 0.
This change in behavior, however, becomes visible only after the
changes to release_reference() later in the series.
There the `rB.id` is used to initiate `mark_reg_invalid(env, reg)` for
the `rB`.
Are the above observations correct?
> + if (type_may_be_null(info.reg_type) && !regs[value_regno].id)
> + regs[value_regno].id = ++env->id_gen;
> }
> regs[value_regno].type = info.reg_type;
> }
^ permalink raw reply
* Re: [PATCH bpf-next v2 1/2] selftests/bpf: make btf_dump use xdp_dummy rather than xdping_kern
From: Paul Chaignon @ 2026-04-22 21:51 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Shuah Khan, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, ebpf, Bastien Curutchet, Thomas Petazzoni,
bpf, linux-kselftest, linux-kernel, netdev
In-Reply-To: <20260422-xdping-v2-1-c0f8ccedcf91@bootlin.com>
On Wed, Apr 22, 2026 at 06:20:24PM +0200, Alexis Lothoré (eBPF Foundation) wrote:
> In order to prepare xdping tool removal from the BPF selftests
> directory, make the btf_dump test use another BPF program for the btf
> datasec dump test. Use xdp_dummy.bpf.o, as it is already used by various
> other tests.
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
Acked-by: Paul Chaignon <paul.chaignon@gmail.com>
> ---
> tools/testing/selftests/bpf/prog_tests/btf_dump.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/btf_dump.c b/tools/testing/selftests/bpf/prog_tests/btf_dump.c
> index f1642794f70e..9f1b50e07a29 100644
> --- a/tools/testing/selftests/bpf/prog_tests/btf_dump.c
> +++ b/tools/testing/selftests/bpf/prog_tests/btf_dump.c
> @@ -1027,8 +1027,8 @@ static void test_btf_dump_datasec_data(char *str)
> char license[4] = "GPL";
> struct btf_dump *d;
>
> - btf = btf__parse("xdping_kern.bpf.o", NULL);
> - if (!ASSERT_OK_PTR(btf, "xdping_kern.bpf.o BTF not found"))
> + btf = btf__parse("xdp_dummy.bpf.o", NULL);
> + if (!ASSERT_OK_PTR(btf, "xdp_dummy.bpf.o BTF not found"))
> return;
>
> d = btf_dump__new(btf, btf_dump_snprintf, str, NULL);
>
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH bpf-next v2 2/2] selftests/bpf: drop xdping tool
From: Paul Chaignon @ 2026-04-22 21:53 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Shuah Khan, David S. Miller,
Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, ebpf, Bastien Curutchet, Thomas Petazzoni,
bpf, linux-kselftest, linux-kernel, netdev, Alan Maguire
In-Reply-To: <20260422-xdping-v2-2-c0f8ccedcf91@bootlin.com>
On Wed, Apr 22, 2026 at 06:20:25PM +0200, Alexis Lothoré (eBPF Foundation) wrote:
> As part of a larger cleanup effort in the bpf selftests directory,
> tests and scripts are either being converted to the test_progs framework
> (so they are executed automatically in bpf CI), or removed if not
> relevant for such integration.
>
> The test_xdping.sh script (with the associated xdping.c) acts as a RTT
> measurement tool, by attaching two small xdp programs to two interfaces.
> Converting this test to test_progs may not make much sense:
> - RTT measurement does not really fit in the scope of a functional test,
> this is rather about measuring some performance level.
> - there are other existing tests in test_progs that actively validate
> XDP features like program attachment, return value processing, packet
> modification, etc
>
> Drop test_xdping.sh, the corresponding xdping.c userspace part, the
> xdping_kern.c program, and the shared header, xdping.h
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Acked-by: Paul Chaignon <paul.chaignon@gmail.com>
> ---
> tools/testing/selftests/bpf/.gitignore | 1 -
> tools/testing/selftests/bpf/Makefile | 3 -
> tools/testing/selftests/bpf/progs/xdping_kern.c | 183 -----------------
> tools/testing/selftests/bpf/test_xdping.sh | 103 ----------
> tools/testing/selftests/bpf/xdping.c | 254 ------------------------
> tools/testing/selftests/bpf/xdping.h | 13 --
> 6 files changed, 557 deletions(-)
>
[...]
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net/ethernet/zte/dinghai: add hardware register access and PCI capability scanning
From: Vadim Fedorenko @ 2026-04-22 21:54 UTC (permalink / raw)
To: Junyang Han, netdev
Cc: davem, andrew+netdev, edumazet, kuba, pabeni, ran.ming,
han.chengfei, zhang.yanze
In-Reply-To: <20260422144901.2403456-4-han.junyang@zte.com.cn>
On 22.04.2026 15:49, Junyang Han wrote:
> Implement PCI configuration space access, BAR mapping, capability
> scanning (common/notify/device), and hardware queue register
> definitions for DingHai PF device.
>
> Signed-off-by: Junyang Han <han.junyang@zte.com.cn>
[...]
> +
> +void __iomem *zxdh_pf_map_capability(struct dh_core_dev *dh_dev, int32_t off,
> + size_t minlen, uint32_t align,
> + uint32_t start, uint32_t size,
> + size_t *len, resource_size_t *pa,
> + uint32_t *bar_off)
> +{
> + struct pci_dev *pdev = dh_dev->pdev;
> + uint8_t bar = 0;
> + uint32_t offset = 0;
> + uint32_t length = 0;
> + void __iomem *p = NULL;
Even though the changelog says that variable declaration ordering is fixed, this
patch (as some others in the series) still has the problem.
Also, please avoid using user-space fixed size types, kernel space uses short
type names, like u32/u8 etc.
Try to avoid meaningless initialization as well.
These comments apply to the whole series, not only to this single patch
> +
> + pci_read_config_byte(pdev, off + offsetof(struct zxdh_pf_pci_cap, bar), &bar);
> + pci_read_config_dword(pdev, off + offsetof(struct zxdh_pf_pci_cap, offset), &offset);
> + pci_read_config_dword(pdev, off + offsetof(struct zxdh_pf_pci_cap, length), &length);
> +
> + if (bar_off)
> + *bar_off = offset;
> +
^ permalink raw reply
* [PATCH 5.10.y] rxrpc: Fix recvmsg() unconditional requeue
From: Jay Wang @ 2026-04-22 22:24 UTC (permalink / raw)
To: stable
Cc: dhowells, marc.dionne, davem, edumazet, kuba, pabeni, netdev,
linux-afs, jay.wang.upstream, Faith, Pumpkin Chang
From: David Howells <dhowells@redhat.com>
[ Upstream commit 2c28769a51deb6022d7fbd499987e237a01dd63a ]
If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call
at the front of the recvmsg queue already has its mutex locked, it
requeues the call - whether or not the call is already queued. The call
may be on the queue because MSG_PEEK was also passed and so the call was
not dequeued or because the I/O thread requeued it.
The unconditional requeue may then corrupt the recvmsg queue, leading to
things like UAFs or refcount underruns.
Fix this by only requeuing the call if it isn't already on the queue -
and moving it to the front if it is already queued. If we don't queue
it, we have to put the ref we obtained by dequeuing it.
Also, MSG_PEEK doesn't dequeue the call so shouldn't call
rxrpc_notify_socket() for the call if we didn't use up all the data on
the queue, so fix that also.
Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
Reported-by: Faith <faith@zellic.io>
Reported-by: Pumpkin Chang <pumpkin@devco.re>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Cc: stable@vger.kernel.org
[Adapted to 5.10: use write_lock_bh/write_unlock_bh, trace_rxrpc_call
directly for see-call tracing, 5.10 trace enum naming convention, and
added entries to both plain enum and EM() macro list.]
Signed-off-by: Jay Wang <wanjay@amazon.com>
---
include/trace/events/rxrpc.h | 8 ++++++++
net/rxrpc/recvmsg.c | 20 ++++++++++++++++----
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -93,9 +93,13 @@ enum rxrpc_call_trace {
rxrpc_call_put_notimer,
rxrpc_call_put_timer,
rxrpc_call_put_userid,
+ rxrpc_call_put_recvmsg_peek_nowait,
rxrpc_call_queued,
rxrpc_call_queued_ref,
rxrpc_call_release,
+ rxrpc_call_see_recvmsg_requeue,
+ rxrpc_call_see_recvmsg_requeue_first,
+ rxrpc_call_see_recvmsg_requeue_move,
rxrpc_call_seen,
};
@@ -291,9 +295,13 @@ enum rxrpc_tx_point {
EM(rxrpc_call_put_notimer, "PnT") \
EM(rxrpc_call_put_timer, "PTM") \
EM(rxrpc_call_put_userid, "Pus") \
+ EM(rxrpc_call_put_recvmsg_peek_nowait, "PpN") \
EM(rxrpc_call_queued, "QUE") \
EM(rxrpc_call_queued_ref, "QUR") \
EM(rxrpc_call_release, "RLS") \
+ EM(rxrpc_call_see_recvmsg_requeue, "SrQ") \
+ EM(rxrpc_call_see_recvmsg_requeue_first,"SrF") \
+ EM(rxrpc_call_see_recvmsg_requeue_move, "SrM") \
E_(rxrpc_call_seen, "SEE")
#define rxrpc_transmit_traces \
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -607,7 +607,8 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
if (after(call->rx_top, call->rx_hard_ack) &&
call->rxtx_buffer[(call->rx_hard_ack + 1) & RXRPC_RXTX_BUFF_MASK])
- rxrpc_notify_socket(call);
+ if (!(flags & MSG_PEEK))
+ rxrpc_notify_socket(call);
break;
default:
ret = 0;
@@ -642,11 +643,24 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
error_requeue_call:
if (!(flags & MSG_PEEK)) {
write_lock_bh(&rx->recvmsg_lock);
- list_add(&call->recvmsg_link, &rx->recvmsg_q);
- write_unlock_bh(&rx->recvmsg_lock);
+ if (list_empty(&call->recvmsg_link)) {
+ list_add(&call->recvmsg_link, &rx->recvmsg_q);
+ trace_rxrpc_call(call->debug_id,
+ rxrpc_call_see_recvmsg_requeue,
+ refcount_read(&call->ref),
+ __builtin_return_address(0), NULL);
+ write_unlock_bh(&rx->recvmsg_lock);
+ } else if (list_is_first(&call->recvmsg_link, &rx->recvmsg_q)) {
+ write_unlock_bh(&rx->recvmsg_lock);
+ rxrpc_put_call(call, rxrpc_call_see_recvmsg_requeue_first);
+ } else {
+ list_move(&call->recvmsg_link, &rx->recvmsg_q);
+ write_unlock_bh(&rx->recvmsg_lock);
+ rxrpc_put_call(call, rxrpc_call_see_recvmsg_requeue_move);
+ }
trace_rxrpc_recvmsg(call, rxrpc_recvmsg_requeue, 0, 0, 0, 0);
} else {
- rxrpc_put_call(call, rxrpc_call_put);
+ rxrpc_put_call(call, rxrpc_call_put_recvmsg_peek_nowait);
}
error_no_call:
release_sock(&rx->sk);
--
2.43.0
^ permalink raw reply
* [PATCH 6.1.y] rxrpc: Fix recvmsg() unconditional requeue
From: Jay Wang @ 2026-04-22 22:24 UTC (permalink / raw)
To: stable
Cc: dhowells, marc.dionne, davem, edumazet, kuba, pabeni, netdev,
linux-afs, jay.wang.upstream, Faith, Pumpkin Chang
From: David Howells <dhowells@redhat.com>
[ Upstream commit 2c28769a51deb6022d7fbd499987e237a01dd63a ]
If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call
at the front of the recvmsg queue already has its mutex locked, it
requeues the call - whether or not the call is already queued. The call
may be on the queue because MSG_PEEK was also passed and so the call was
not dequeued or because the I/O thread requeued it.
The unconditional requeue may then corrupt the recvmsg queue, leading to
things like UAFs or refcount underruns.
Fix this by only requeuing the call if it isn't already on the queue -
and moving it to the front if it is already queued. If we don't queue
it, we have to put the ref we obtained by dequeuing it.
Also, MSG_PEEK doesn't dequeue the call so shouldn't call
rxrpc_notify_socket() for the call if we didn't use up all the data on
the queue, so fix that also.
Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
Reported-by: Faith <faith@zellic.io>
Reported-by: Pumpkin Chang <pumpkin@devco.re>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Cc: stable@vger.kernel.org
[Adapted to 6.1: use write_lock_bh/write_unlock_bh, trace_rxrpc_call
directly for see-call tracing, and 6.1 trace enum naming convention.]
Signed-off-by: Jay Wang <wanjay@amazon.com>
---
include/trace/events/rxrpc.h | 4 ++++
net/rxrpc/recvmsg.c | 20 ++++++++++++++++----
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -82,9 +82,13 @@
EM(rxrpc_call_put_notimer, "PnT") \
EM(rxrpc_call_put_timer, "PTM") \
EM(rxrpc_call_put_userid, "Pus") \
+ EM(rxrpc_call_put_recvmsg_peek_nowait, "PpN") \
EM(rxrpc_call_queued, "QUE") \
EM(rxrpc_call_queued_ref, "QUR") \
EM(rxrpc_call_release, "RLS") \
+ EM(rxrpc_call_see_recvmsg_requeue, "SrQ") \
+ EM(rxrpc_call_see_recvmsg_requeue_first,"SrF") \
+ EM(rxrpc_call_see_recvmsg_requeue_move, "SrM") \
E_(rxrpc_call_seen, "SEE")
#define rxrpc_transmit_traces \
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -607,7 +607,8 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
if (after(call->rx_top, call->rx_hard_ack) &&
call->rxtx_buffer[(call->rx_hard_ack + 1) & RXRPC_RXTX_BUFF_MASK])
- rxrpc_notify_socket(call);
+ if (!(flags & MSG_PEEK))
+ rxrpc_notify_socket(call);
break;
default:
ret = 0;
@@ -642,11 +643,24 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
error_requeue_call:
if (!(flags & MSG_PEEK)) {
write_lock_bh(&rx->recvmsg_lock);
- list_add(&call->recvmsg_link, &rx->recvmsg_q);
- write_unlock_bh(&rx->recvmsg_lock);
+ if (list_empty(&call->recvmsg_link)) {
+ list_add(&call->recvmsg_link, &rx->recvmsg_q);
+ trace_rxrpc_call(call->debug_id,
+ rxrpc_call_see_recvmsg_requeue,
+ refcount_read(&call->ref),
+ __builtin_return_address(0), NULL);
+ write_unlock_bh(&rx->recvmsg_lock);
+ } else if (list_is_first(&call->recvmsg_link, &rx->recvmsg_q)) {
+ write_unlock_bh(&rx->recvmsg_lock);
+ rxrpc_put_call(call, rxrpc_call_see_recvmsg_requeue_first);
+ } else {
+ list_move(&call->recvmsg_link, &rx->recvmsg_q);
+ write_unlock_bh(&rx->recvmsg_lock);
+ rxrpc_put_call(call, rxrpc_call_see_recvmsg_requeue_move);
+ }
trace_rxrpc_recvmsg(call, rxrpc_recvmsg_requeue, 0, 0, 0, 0);
} else {
- rxrpc_put_call(call, rxrpc_call_put);
+ rxrpc_put_call(call, rxrpc_call_put_recvmsg_peek_nowait);
}
error_no_call:
release_sock(&rx->sk);
--
2.43.0
^ permalink raw reply
* [PATCH 5.15.y] rxrpc: Fix recvmsg() unconditional requeue
From: Jay Wang @ 2026-04-22 22:24 UTC (permalink / raw)
To: stable
Cc: dhowells, marc.dionne, davem, edumazet, kuba, pabeni, netdev,
linux-afs, jay.wang.upstream, Faith, Pumpkin Chang
From: David Howells <dhowells@redhat.com>
[ Upstream commit 2c28769a51deb6022d7fbd499987e237a01dd63a ]
If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call
at the front of the recvmsg queue already has its mutex locked, it
requeues the call - whether or not the call is already queued. The call
may be on the queue because MSG_PEEK was also passed and so the call was
not dequeued or because the I/O thread requeued it.
The unconditional requeue may then corrupt the recvmsg queue, leading to
things like UAFs or refcount underruns.
Fix this by only requeuing the call if it isn't already on the queue -
and moving it to the front if it is already queued. If we don't queue
it, we have to put the ref we obtained by dequeuing it.
Also, MSG_PEEK doesn't dequeue the call so shouldn't call
rxrpc_notify_socket() for the call if we didn't use up all the data on
the queue, so fix that also.
Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg")
Reported-by: Faith <faith@zellic.io>
Reported-by: Pumpkin Chang <pumpkin@devco.re>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Cc: stable@vger.kernel.org
[Adapted to 5.15: use write_lock_bh/write_unlock_bh, trace_rxrpc_call
directly for see-call tracing, 5.15 trace enum naming convention, and
added entries to both plain enum and EM() macro list.]
Signed-off-by: Jay Wang <wanjay@amazon.com>
---
include/trace/events/rxrpc.h | 8 ++++++++
net/rxrpc/recvmsg.c | 20 ++++++++++++++++----
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -93,9 +93,13 @@ enum rxrpc_call_trace {
rxrpc_call_put_notimer,
rxrpc_call_put_timer,
rxrpc_call_put_userid,
+ rxrpc_call_put_recvmsg_peek_nowait,
rxrpc_call_queued,
rxrpc_call_queued_ref,
rxrpc_call_release,
+ rxrpc_call_see_recvmsg_requeue,
+ rxrpc_call_see_recvmsg_requeue_first,
+ rxrpc_call_see_recvmsg_requeue_move,
rxrpc_call_seen,
};
@@ -291,9 +295,13 @@ enum rxrpc_tx_point {
EM(rxrpc_call_put_notimer, "PnT") \
EM(rxrpc_call_put_timer, "PTM") \
EM(rxrpc_call_put_userid, "Pus") \
+ EM(rxrpc_call_put_recvmsg_peek_nowait, "PpN") \
EM(rxrpc_call_queued, "QUE") \
EM(rxrpc_call_queued_ref, "QUR") \
EM(rxrpc_call_release, "RLS") \
+ EM(rxrpc_call_see_recvmsg_requeue, "SrQ") \
+ EM(rxrpc_call_see_recvmsg_requeue_first,"SrF") \
+ EM(rxrpc_call_see_recvmsg_requeue_move, "SrM") \
E_(rxrpc_call_seen, "SEE")
#define rxrpc_transmit_traces \
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -607,7 +607,8 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
if (after(call->rx_top, call->rx_hard_ack) &&
call->rxtx_buffer[(call->rx_hard_ack + 1) & RXRPC_RXTX_BUFF_MASK])
- rxrpc_notify_socket(call);
+ if (!(flags & MSG_PEEK))
+ rxrpc_notify_socket(call);
break;
default:
ret = 0;
@@ -642,11 +643,24 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
error_requeue_call:
if (!(flags & MSG_PEEK)) {
write_lock_bh(&rx->recvmsg_lock);
- list_add(&call->recvmsg_link, &rx->recvmsg_q);
- write_unlock_bh(&rx->recvmsg_lock);
+ if (list_empty(&call->recvmsg_link)) {
+ list_add(&call->recvmsg_link, &rx->recvmsg_q);
+ trace_rxrpc_call(call->debug_id,
+ rxrpc_call_see_recvmsg_requeue,
+ refcount_read(&call->ref),
+ __builtin_return_address(0), NULL);
+ write_unlock_bh(&rx->recvmsg_lock);
+ } else if (list_is_first(&call->recvmsg_link, &rx->recvmsg_q)) {
+ write_unlock_bh(&rx->recvmsg_lock);
+ rxrpc_put_call(call, rxrpc_call_see_recvmsg_requeue_first);
+ } else {
+ list_move(&call->recvmsg_link, &rx->recvmsg_q);
+ write_unlock_bh(&rx->recvmsg_lock);
+ rxrpc_put_call(call, rxrpc_call_see_recvmsg_requeue_move);
+ }
trace_rxrpc_recvmsg(call, rxrpc_recvmsg_requeue, 0, 0, 0, 0);
} else {
- rxrpc_put_call(call, rxrpc_call_put);
+ rxrpc_put_call(call, rxrpc_call_put_recvmsg_peek_nowait);
}
error_no_call:
release_sock(&rx->sk);
--
2.43.0
^ permalink raw reply
* Re: [PATCH bpf-next v3 2/9] bpf: Assign reg->id when getting referenced kptr from ctx
From: Amery Hung @ 2026-04-22 22:45 UTC (permalink / raw)
To: Eduard Zingerman
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, memxor,
martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <9237d7b35463c79863488e3f2180239aab679049.camel@gmail.com>
On Wed, Apr 22, 2026 at 2:46 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
>
> On Tue, 2026-04-21 at 15:10 -0700, Amery Hung wrote:
> > Assign reg->id when getting referenced kptr from read program context
> > to be consistent with R0 of KF_ACQUIRE kfunc. skb dynptr will track the
> > referenced skb in qdisc programs using a new field reg->parent_id in
> > a later patch.
> >
> > Signed-off-by: Amery Hung <ameryhung@gmail.com>
> > ---
> > kernel/bpf/verifier.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 41e4ea41c72e..93003a2a96b0 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -6448,8 +6448,6 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> > } else {
> > mark_reg_known_zero(env, regs,
> > value_regno);
> > - if (type_may_be_null(info.reg_type))
> > - regs[value_regno].id = ++env->id_gen;
> > /* A load of ctx field could have different
> > * actual load size with the one encoded in the
> > * insn. When the dst is PTR, it is for sure not
> > @@ -6459,8 +6457,11 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> > if (base_type(info.reg_type) == PTR_TO_BTF_ID) {
> > regs[value_regno].btf = info.btf;
> > regs[value_regno].btf_id = info.btf_id;
> > + regs[value_regno].id = info.ref_obj_id;
> > regs[value_regno].ref_obj_id = info.ref_obj_id;
> > }
>
> Hi Amery,
>
> Could you please help me double-check my understanding of this change?
>
> It adds a new behavior, if struct_ops method parameter is annotated
> with __ref, then if a field is read from such struct_ops context
> the destination register would now have it's .id == ref_obj_id
> allocated for the parameter at the beginning of do_check().
> E.g. for `rB = *(T *)(rA + off)`, if `rA` is a pointer to struct_ops
> context and parameter corresponding to `off` has `__ref` annotation
> the `rB.id` will be assigned, contrary to old behavior, when it remained 0.
>
Right
> This change in behavior, however, becomes visible only after the
> changes to release_reference() later in the series.
> There the `rB.id` is used to initiate `mark_reg_invalid(env, reg)` for
> the `rB`.
>
I probably should mention it in the commit message. The purpose of the
patch is to make the implementation consistent with the design:
parent_id tracks the id of the parent objects.
Without this patch, it should still work since in this case ref_obj_id
always equals to id. When release_reference() is called on a
KF_RELEASE kfunc, the children objects will still be invalidated
correctly.
> Are the above observations correct?
>
> > + if (type_may_be_null(info.reg_type) && !regs[value_regno].id)
> > + regs[value_regno].id = ++env->id_gen;
> > }
> > regs[value_regno].type = info.reg_type;
> > }
^ permalink raw reply
* Re: [PATCH bpf-next v3 3/9] bpf: Preserve reg->id of pointer objects after null-check
From: Eduard Zingerman @ 2026-04-22 22:46 UTC (permalink / raw)
To: bot+bpf-ci, ameryhung, bpf
Cc: netdev, alexei.starovoitov, andrii, daniel, memxor, martin.lau,
mykyta.yatsenko5, kernel-team, ast, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <d5679e6f2b458bb8771f83e6985247befd68fbab894a0d2a09797f0ec3a90efe@mail.kernel.org>
On Tue, 2026-04-21 at 22:52 +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 93003a2a96b0..0313b7d5f6c9 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -15886,15 +15886,10 @@ static void mark_ptr_or_null_reg(struct bpf_func_state *state,
> >
> > mark_ptr_not_null_reg(reg);
> >
> > - if (!reg_may_point_to_spin_lock(reg)) {
> > - /* For not-NULL ptr, reg->ref_obj_id will be reset
> > - * in release_reference().
> > - *
> > - * reg->id is still used by spin_lock ptr. Other
> > - * than spin_lock ptr type, reg->id can be reset.
> > - */
> > - reg->id = 0;
> > - }
> > + /*
> > + * reg->id is preserved for object relationship tracking
> > + * and spin_lock lock state tracking
> > + */
>
> How does preserving reg->id interact with reg_is_init_pkt_pointer()?
>
> In v2 review, Alexei Starovoitov raised this concern: "That pointer has
> to have id == 0". Eduard Zingerman responded that dropping the id == 0
> check should be fine, but this change was not made in v3.
>
> The function reg_is_init_pkt_pointer() still checks reg->id == 0:
>
> return reg->type == which &&
> reg->id == 0 &&
> reg->off == 0 &&
>
> With this patch, if a PTR_TO_PACKET register goes through null-checking
> in mark_ptr_or_null_reg(), it will now preserve its reg->id instead of
> resetting it to 0. Would this cause reg_is_init_pkt_pointer() to
> incorrectly return false for init packet pointers?
>
> Reference: https://lore.kernel.org/bpf/CAADnVQLCKi_QL1FeybW+6MH6FAOAoRJyW06UvtX3my3yNSH5eQ@mail.gmail.com/
>
> > }
> > }
Bot concern is bogus here, reg_is_init_pkt_pointer() is called only
for PTR_TO_PACKET. mark_ptr_or_null_reg() checks for
type_may_be_null(reg->type), meaning that for it to trigger one would
need a register of type PTR_TO_PACKET | PTR_MAYBE_NULL.
It appears there is no way to construct such type at the moment.
^ permalink raw reply
* Re: [PATCH bpf-next v3 2/9] bpf: Assign reg->id when getting referenced kptr from ctx
From: Eduard Zingerman @ 2026-04-22 22:50 UTC (permalink / raw)
To: Amery Hung
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, memxor,
martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <CAMB2axMzeQs3WzFd1PZFB=DgR6d2ye4qzHKhATK2895ryzAEog@mail.gmail.com>
On Wed, 2026-04-22 at 15:45 -0700, Amery Hung wrote:
> On Wed, Apr 22, 2026 at 2:46 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
> >
> > On Tue, 2026-04-21 at 15:10 -0700, Amery Hung wrote:
> > > Assign reg->id when getting referenced kptr from read program context
> > > to be consistent with R0 of KF_ACQUIRE kfunc. skb dynptr will track the
> > > referenced skb in qdisc programs using a new field reg->parent_id in
> > > a later patch.
> > >
> > > Signed-off-by: Amery Hung <ameryhung@gmail.com>
> > > ---
> > > kernel/bpf/verifier.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > index 41e4ea41c72e..93003a2a96b0 100644
> > > --- a/kernel/bpf/verifier.c
> > > +++ b/kernel/bpf/verifier.c
> > > @@ -6448,8 +6448,6 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> > > } else {
> > > mark_reg_known_zero(env, regs,
> > > value_regno);
> > > - if (type_may_be_null(info.reg_type))
> > > - regs[value_regno].id = ++env->id_gen;
> > > /* A load of ctx field could have different
> > > * actual load size with the one encoded in the
> > > * insn. When the dst is PTR, it is for sure not
> > > @@ -6459,8 +6457,11 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> > > if (base_type(info.reg_type) == PTR_TO_BTF_ID) {
> > > regs[value_regno].btf = info.btf;
> > > regs[value_regno].btf_id = info.btf_id;
> > > + regs[value_regno].id = info.ref_obj_id;
> > > regs[value_regno].ref_obj_id = info.ref_obj_id;
> > > }
> >
> > Hi Amery,
> >
> > Could you please help me double-check my understanding of this change?
> >
> > It adds a new behavior, if struct_ops method parameter is annotated
> > with __ref, then if a field is read from such struct_ops context
> > the destination register would now have it's .id == ref_obj_id
> > allocated for the parameter at the beginning of do_check().
> > E.g. for `rB = *(T *)(rA + off)`, if `rA` is a pointer to struct_ops
> > context and parameter corresponding to `off` has `__ref` annotation
> > the `rB.id` will be assigned, contrary to old behavior, when it remained 0.
> >
>
> Right
Ack, thank you.
> > This change in behavior, however, becomes visible only after the
> > changes to release_reference() later in the series.
> > There the `rB.id` is used to initiate `mark_reg_invalid(env, reg)` for
> > the `rB`.
> >
>
> I probably should mention it in the commit message. The purpose of the
> patch is to make the implementation consistent with the design:
> parent_id tracks the id of the parent objects.
>
> Without this patch, it should still work since in this case ref_obj_id
> always equals to id. When release_reference() is called on a
> KF_RELEASE kfunc, the children objects will still be invalidated
> correctly.
bpf_qdisc_fail__invalid_dynptr_cross_frame.c:invalid_dynptr_cross_frame
fails if I comment out the line `regs[value_regno].id = info.ref_obj_id;`.
The added .id link is used to propagate invalidation triggered by
`free_skb(skb);` to `hdr`.
The patch seem mandatory for the series.
^ permalink raw reply
* Re: [PATCH] net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind
From: Rémi Denis-Courmont @ 2026-04-22 15:18 UTC (permalink / raw)
To: Remi Denis-Courmont, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Morduan Zang
Cc: Simon Horman, netdev, linux-kernel, syzkaller-bugs,
syzbot+706f5eb79044e686c794, Morduan Zang, zhanjun
In-Reply-To: <81A6570B633FF6FE+20260422013807.63087-1-zhangdandan@uniontech.com>
Hi,
Le keskiviikkona 22. huhtikuuta 2026, 4.38.07 Itä-Euroopan kesäaika Morduan
Zang a écrit :
> syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via
> pn_socket_autobind():
>
> kernel BUG at net/phonet/socket.c:213!
> RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline]
> RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421
> Call Trace:
> sock_sendmsg_nosec+0x112/0x150 net/socket.c:797
> __sock_sendmsg net/socket.c:812 [inline]
> __sys_sendto+0x402/0x590 net/socket.c:2280
> ...
>
> pn_socket_autobind() calls pn_socket_bind() with port 0 and, on
> -EINVAL, assumes the socket was already bound and asserts that the
> port is non-zero:
>
> err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn));
> if (err != -EINVAL)
> return err;
> BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
> return 0; /* socket was already bound */
>
> However pn_socket_bind() also returns -EINVAL when sk->sk_state is not
> TCP_CLOSE, even when the socket has never been bound and pn_port() is
> still 0. In that case the BUG_ON() fires and panics the kernel from a
> user-triggerable path.
>
> Treat the "bind returned -EINVAL but pn_port() is still 0" case as a
> regular error and propagate -EINVAL to the caller instead of crashing.
> Existing callers already translate a non-zero return from
> pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here
> only changes behaviour from panic to a normal errno.
>
> Fixes: ba113a94b750 ("Phonet: common socket glue")
> Reported-by: syzbot+706f5eb79044e686c794@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=706f5eb79044e686c794
> Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
> Signed-off-by: zhanjun <zhanjun@uniontech.com>
> ---
> net/phonet/socket.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/net/phonet/socket.c b/net/phonet/socket.c
> index 4423d483c630..de9108adfe1c 100644
> --- a/net/phonet/socket.c
> +++ b/net/phonet/socket.c
> @@ -210,7 +210,15 @@ static int pn_socket_autobind(struct socket *sock)
> sizeof(struct sockaddr_pn));
> if (err != -EINVAL)
> return err;
> - BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
> + /*
> + * pn_socket_bind() can return -EINVAL both when the socket is
> + * already bound (pn_port() != 0) and when sk_state != TCP_CLOSE
> + * without a prior bind. Only the former is an "already bound"
> + * success for autobind; otherwise propagate -EINVAL instead of
> + * crashing the kernel.
> + */
> + if (!pn_port(pn_sk(sock->sk)->sobject))
> + return -EINVAL;
This could be written as just if (err != -EINVAL || unlikely(...)) return err;
> return 0; /* socket was already bound */
> }
--
德尼-库尔蒙‧雷米
https://www.remlab.net/
^ permalink raw reply
* Re: [PATCH net v3 8/8] xsk: don't support AF_XDP on 32-bit architectures
From: Jason Xing @ 2026-04-22 23:45 UTC (permalink / raw)
To: David Laight
Cc: davem, edumazet, kuba, pabeni, bjorn, magnus.karlsson,
maciej.fijalkowski, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, bpf, netdev, Jason Xing
In-Reply-To: <20260422212741.50deeb06@pumpkin>
On Thu, Apr 23, 2026 at 4:27 AM David Laight
<david.laight.linux@gmail.com> wrote:
>
> On Wed, 22 Apr 2026 11:36:50 +0800
> Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > In copy mode TX, xsk_skb_destructor_set_addr() stores the 64-bit
> > descriptor address into skb_shinfo(skb)->destructor_arg (void *) via a
> > uintptr_t cast:
> >
> > skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t)addr | 0x1UL);
> >
> > On 32-bit architectures uintptr_t is 32 bits, so the upper 32 bits of
> > the descriptor address are silently dropped. In XDP_ZEROCOPY unaligned
> > mode the chunk offset is encoded in bits 48-63 of the descriptor
> > address (XSK_UNALIGNED_BUF_OFFSET_SHIFT = 48), meaning the offset is
> > lost entirely. The completion queue then returns a truncated address to
> > userspace, making buffer recycling impossible.
>
> I had a look at how this is used.
>
> I suspect that XSK_UNALIGNED_BUF_OFFSET_SHIFT can just be made smaller.
> The 'addr' isn't really a normal address of any kind, it is a really
> and offset into an array made up of pages of memory.
> The actual address (kernel virtual of dma) is generated by:
> ptr->array[addr >> PAGE_SHIFT] + addr & ~PAGE_MASK
> (after removing the unaligned chunk offset from 'addr').
>
> It is actually quite likely that there are enough free high bits
> even in 32bit mode.
Interesting idea. But if everything is folded into a 32-bit area, it
means the size of umem is only 20-bit. 20-bit reflects that users only
put a max 1MB data into it. It might be too small to use?
Thanks,
Jason
>
> David
>
> >
> > Since we hear no one is using AF_XDP on 32-bit arch, we decided to
> > strictly stop supporting it at compile time.
> >
> > Closes: https://lore.kernel.org/all/20260419045824.D9E5EC2BCAF@smtp.kernel.org/
> > Fixes: 0ebc27a4c67d ("xsk: avoid data corruption on cq descriptor number")
> > Suggested-by: Stanislav Fomichev <sdf@fomichev.me>
> > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > ---
> > net/xdp/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/xdp/Kconfig b/net/xdp/Kconfig
> > index 71af2febe72a..819aa5795f50 100644
> > --- a/net/xdp/Kconfig
> > +++ b/net/xdp/Kconfig
> > @@ -1,7 +1,7 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > config XDP_SOCKETS
> > bool "XDP sockets"
> > - depends on BPF_SYSCALL
> > + depends on BPF_SYSCALL && 64BIT
> > default n
> > help
> > XDP sockets allows a channel between XDP programs and
>
^ permalink raw reply
* Re: [PATCH net v3 8/8] xsk: don't support AF_XDP on 32-bit architectures
From: Jason Xing @ 2026-04-22 23:49 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: Alexander Lobakin, davem, edumazet, kuba, pabeni, bjorn,
magnus.karlsson, jonathan.lemon, sdf, ast, daniel, hawk,
john.fastabend, bpf, netdev, Jason Xing
In-Reply-To: <aej+JZyYwUrRXD6e@boxer>
On Thu, Apr 23, 2026 at 12:58 AM Maciej Fijalkowski
<maciej.fijalkowski@intel.com> wrote:
>
> On Thu, Apr 23, 2026 at 12:37:07AM +0800, Jason Xing wrote:
> > On Thu, Apr 23, 2026 at 12:10 AM Alexander Lobakin
> > <aleksander.lobakin@intel.com> wrote:
> > >
> > > From: Jason Xing <kerneljasonxing@gmail.com>
> > > Date: Wed, 22 Apr 2026 11:36:50 +0800
> > >
> > > > From: Jason Xing <kernelxing@tencent.com>
> > > >
> > > > In copy mode TX, xsk_skb_destructor_set_addr() stores the 64-bit
> > > > descriptor address into skb_shinfo(skb)->destructor_arg (void *) via a
> > > > uintptr_t cast:
> > > >
> > > > skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t)addr | 0x1UL);
> > > >
> > > > On 32-bit architectures uintptr_t is 32 bits, so the upper 32 bits of
> > > > the descriptor address are silently dropped. In XDP_ZEROCOPY unaligned
> > > > mode the chunk offset is encoded in bits 48-63 of the descriptor
> > > > address (XSK_UNALIGNED_BUF_OFFSET_SHIFT = 48), meaning the offset is
> > > > lost entirely. The completion queue then returns a truncated address to
> > > > userspace, making buffer recycling impossible.
> > >
> > > What if we relax the restriction a bit? For example, refuse to configure
> >
> > As to the bug itself, yes, It only affects the unaligned mode.
> >
> > I wonder if we can support this after someone requires us to support
> > 32-bit arch and use it in the real world, then we can use the previous
> > patch to complete the full support (which doesn't harm the path on
> > 64-bit arch).
> >
> > The code looks like this based on your suggestion. Just for the record.
> > diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> > index 58da2f4f4397..03417b04592f 100644
> > --- a/net/xdp/xdp_umem.c
> > +++ b/net/xdp/xdp_umem.c
> > @@ -177,6 +177,9 @@ static int xdp_umem_reg(struct xdp_umem *umem,
> > struct xdp_umem_reg *mr)
> > if (mr->flags & ~XDP_UMEM_FLAGS_VALID)
> > return -EINVAL;
> > + if (!IS_ENABLED(CONFIG_64BIT) && unaligned_chunks)
> > + return -EOPNOTSUPP;
> > +
> > if (!unaligned_chunks && !is_power_of_2(chunk_size))
> > return -EINVAL;
> >
> > Actually I'm fine with either of them. Right now I'm not so sure which
> > direction this patch should take :)
>
> Abstracting from discussion, that is not a patch we would want against
> -net. We should not forbid 32bit on stable kernels, maybe there is someone
> in the 'basement' using 32bit xsk on stable kernel. Plus the fixes tag vs
> patch's content looks weird ;)
Sorry, I don't follow this. Any specific suggestions on how to move forward?
Now we have three approaches w/o the fixes tag:
1. completely forbid 32-bit arch
2. only forbid unaligned mode on 32-bit arch
3. completely fix/modify the allocation logic of the first frag on
32-bit (see the v2-0008 patch)
I'm wondering how to proceed with that?
Thanks,
Jason
>
> >
> > Thanks,
> > Jason
> >
> > > an XSk socket in unaligned mode if on a 32-bit arch? Or add a check
> > > under CONFIG_32_BIT like it was done in Page Pool:
> > >
> > > skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t)addr | 0x1UL);
> > >
> > > #ifdef CONFIG_32BIT
> > > if (((uintptr_t)skb_shinfo(skb)->destructor_arg) & ~0x1UL) != addr)
> > > // WARN_ONCE or whatever + error path
> > > #endif
> > >
> > > I never used XSk on a 32-bit arch, but back when I was working on 32-bit
> > > MIPS 1G routers, I wanted to add native XSk support to the Eth driver.
> > > Sure, just for fun, now that we have cheap AArch64 and other 64-bit
> > > embedded chips, 32-bit embedded networking SoCs are almost dead, but
> > > OTOH, as you can see, other subsystems like PP still try to support 32 bit.
> > > Especially given that this issue applies to only to the skb XSk path,
> > > not native in-driver implementations.
> > >
> > > >
> > > > Since we hear no one is using AF_XDP on 32-bit arch, we decided to
> > > > strictly stop supporting it at compile time.
> > > >
> > > > Closes: https://lore.kernel.org/all/20260419045824.D9E5EC2BCAF@smtp.kernel.org/
> > > > Fixes: 0ebc27a4c67d ("xsk: avoid data corruption on cq descriptor number")
> > > > Suggested-by: Stanislav Fomichev <sdf@fomichev.me>
> > > > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > > > ---
> > > > net/xdp/Kconfig | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/net/xdp/Kconfig b/net/xdp/Kconfig
> > > > index 71af2febe72a..819aa5795f50 100644
> > > > --- a/net/xdp/Kconfig
> > > > +++ b/net/xdp/Kconfig
> > > > @@ -1,7 +1,7 @@
> > > > # SPDX-License-Identifier: GPL-2.0-only
> > > > config XDP_SOCKETS
> > > > bool "XDP sockets"
> > > > - depends on BPF_SYSCALL
> > > > + depends on BPF_SYSCALL && 64BIT
> > > > default n
> > > > help
> > > > XDP sockets allows a channel between XDP programs and
> > >
> > > Thanks,
> > > Olek
^ permalink raw reply
* [PATCH] mctp i2c: check packet length before marking flow active
From: William A. Kennington III @ 2026-04-23 0:15 UTC (permalink / raw)
To: Jeremy Kerr, Matt Johnston, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Wolfram Sang
Cc: William A. Kennington III, netdev, linux-kernel
Currently, mctp_i2c_get_tx_flow_state() is called before the packet length
sanity check. This function marks a new flow as active in the MCTP core.
If the sanity check fails, mctp_i2c_xmit() returns early without calling
mctp_i2c_lock_nest(). This results in a mismatched locking state: the
flow is active, but the I2C bus lock was never acquired for it.
When the flow is later released, mctp_i2c_release_flow() will see the
active state and queue an unlock marker. The TX thread will then
decrement midev->i2c_lock_count from 0, causing it to underflow to -1.
This underflow permanently breaks the driver's locking logic, allowing
future transmissions to occur without holding the I2C bus lock, leading
to bus collisions and potential hardware hangs.
Move the mctp_i2c_get_tx_flow_state() call to after the length sanity
check to ensure we only transition the flow state if we are actually
going to proceed with the transmission and locking.
Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver")
Signed-off-by: William A. Kennington III <william@wkennington.com>
---
drivers/net/mctp/mctp-i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/mctp/mctp-i2c.c b/drivers/net/mctp/mctp-i2c.c
index 15fe4d1163c1..ee2913758e54 100644
--- a/drivers/net/mctp/mctp-i2c.c
+++ b/drivers/net/mctp/mctp-i2c.c
@@ -496,8 +496,6 @@ static void mctp_i2c_xmit(struct mctp_i2c_dev *midev, struct sk_buff *skb)
u8 *pecp;
int rc;
- fs = mctp_i2c_get_tx_flow_state(midev, skb);
-
hdr = (void *)skb_mac_header(skb);
/* Sanity check that packet contents matches skb length,
* and can't exceed MCTP_I2C_BUFSZ
@@ -509,6 +507,8 @@ static void mctp_i2c_xmit(struct mctp_i2c_dev *midev, struct sk_buff *skb)
return;
}
+ fs = mctp_i2c_get_tx_flow_state(midev, skb);
+
if (skb_tailroom(skb) >= 1) {
/* Linear case with space, we can just append the PEC */
skb_put(skb, 1);
--
2.54.0.rc2.533.g4f5dca5207-goog
^ permalink raw reply related
* CL37 autonegotiation not working on amd-xgbe
From: Patrick Oppenlander @ 2026-04-23 0:18 UTC (permalink / raw)
To: netdev; +Cc: Shyam-sundar.S-k, Raju.Rangoju, kuba
Hi,
A recent change [1] stopped CL37 autonegotiation from working on
amd-xgbe hardware.
The driver thinks autonegotiation is succeeding, but no data is able
to transfer across the link. Here's an mdio/phy debug log showing the
link coming up successfully in the broken state:
amd-xgbe 0000:07:00.2 control-sfp: phy powered off
amd-xgbe 0000:07:00.2 control-sfp: CL73 AN disabled
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN disabled
amd-xgbe 0000:07:00.2 control-sfp: starting PHY
amd-xgbe 0000:07:00.2 control-sfp: 10GbE SFI mode set
amd-xgbe 0000:07:00.2 control-sfp: 1GbE X mode set
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN (BaseX) initialized
amd-xgbe 0000:07:00.2 control-sfp: AN PHY configuration
amd-xgbe 0000:07:00.2 control-sfp: CL73 AN disabled
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN disabled
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN (BaseX) initialized
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN enabled/restarted
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN Complete
amd-xgbe 0000:07:00.2 control-sfp: Auto negotiation successful
amd-xgbe 0000:07:00.2 control-sfp: CL37 AN result: Complete
amd-xgbe 0000:07:00.2 control-sfp: Link is Up - 1Gbps/Full - flow control off
I've tried SFP modules and switches from multiple vendors, and no
combination of hardware successfully autonegotiates after the change.
Unfortunately there appears to be no public documentation available
for amd-xgbe, so it's basically impossible for me to debug any
further. I've included a patch which "fixes" the issue, but given the
lack of documentation I have no idea what it really does.
If there's any more information I can provide to help diagnose the
issue, please let me know.
Patrick
[1] https://patch.msgid.link/20250630192636.3838291-1-Raju.Rangoju@amd.com
-- >8 --
From d17b2e685cc0e389f9c62b6cae735b2ef7d8c49b Mon Sep 17 00:00:00 2001
From: Patrick Oppenlander <patrick.oppenlander@gmail.com>
Date: Thu, 23 Apr 2026 09:37:51 +1000
Subject: [PATCH] amd-xgbe: fix CL37 autonegotiation
Broken after 42fd432fe6d320323215ebdf4de4d0d7e56e6792.
I can't find any documentation for this hardware, so this change really
just reverts the part of the commit which made autonegotation stop
working.
---
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
index e4334c12b3e15..7639961db0af4 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-mdio.c
@@ -377,10 +377,6 @@ static void xgbe_an37_set(struct xgbe_prv_data
*pdata, bool enable,
reg |= MDIO_VEND2_CTRL1_AN_RESTART;
XMDIO_WRITE(pdata, MDIO_MMD_VEND2, MDIO_CTRL1, reg);
-
- reg = XMDIO_READ(pdata, MDIO_MMD_VEND2, MDIO_PCS_DIG_CTRL);
- reg |= XGBE_VEND2_MAC_AUTO_SW;
- XMDIO_WRITE(pdata, MDIO_MMD_VEND2, MDIO_PCS_DIG_CTRL, reg);
}
static void xgbe_an37_restart(struct xgbe_prv_data *pdata)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind
From: Morduan Zang @ 2026-04-23 0:47 UTC (permalink / raw)
To: remi
Cc: courmisch, davem, edumazet, horms, kuba, linux-kernel, netdev,
pabeni, syzbot+706f5eb79044e686c794, syzkaller-bugs, zhangdandan,
zhanjun
In-Reply-To: <2466095.vKB9LnXJlr@basile.remlab.net>
Hi Remi,
On Wed, Apr 22, 2026 at 06:18:48PM +0300, Remi Denis-Courmont wrote:
> This could be written as just
> if (err != -EINVAL || unlikely(...)) return err;
Thanks, that reads much better. Folded into v2 and resending now.
Morduan
^ permalink raw reply
* [PATCH net v2] net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()
From: Morduan Zang @ 2026-04-23 0:49 UTC (permalink / raw)
To: petkan
Cc: davem, edumazet, kuba, pabeni, andrew+netdev, andrew,
michal.pecio, linux-usb, netdev, linux-kernel, syzkaller-bugs,
Zhan Jun, syzbot+3f46c095ac0ca048cb71
In-Reply-To: <73ACB7391A6DE033+20260421110412.14795-1-zhangdandan@uniontech.com>
From: Zhan Jun <zhanjun@uniontech.com>
syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit()
when accessing skb->len for tx statistics after usb_submit_urb() has
been called:
BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760
drivers/net/usb/rtl8150.c:712
Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226
The URB completion handler write_bulk_callback() frees the skb via
dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU
in softirq context before usb_submit_urb() returns in the submitter,
so by the time the submitter reads skb->len the skb has already been
queued to the per-CPU completion_queue and freed by net_tx_action():
CPU A (xmit) CPU B (USB completion softirq)
------------ ------------------------------
dev->tx_skb = skb;
usb_submit_urb() --+
|-------> write_bulk_callback()
| dev_kfree_skb_irq(dev->tx_skb)
| net_tx_action()
| napi_skb_cache_put() <-- free
netdev->stats.tx_bytes |
+= skb->len; <-- UAF read
Fix it by caching skb->len before submitting the URB and using the
cached value when updating the tx_bytes counter.
The pre-existing tx_bytes semantics are preserved: the counter tracks
the original frame length (skb->len), not the ETH_ZLEN/USB-alignment
padded "count" value that is handed to the device. Changing that
would be a user-visible accounting change and is out of scope for
this UAF fix.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+3f46c095ac0ca048cb71@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/69e69ee7.050a0220.24bfd3.002b.GAE@google.com/
Closes: https://syzkaller.appspot.com/bug?extid=3f46c095ac0ca048cb71
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Zhan Jun <zhanjun@uniontech.com>
---
Changes in v2:
- Drop the vague "This mirrors the fix pattern used by other USB
network drivers." claim from the changelog (Michal Pecio).
- Clarify that the patch intentionally preserves the existing
tx_bytes semantics (no ETH_ZLEN/USB padding accounted), and that
adjusting that is out of scope for this UAF fix (Michal Pecio).
- Use the correct "[PATCH net]" subject prefix per
Documentation/process/maintainer-netdev.rst (Andrew Lunn).
- Add Reviewed-by: Andrew Lunn.
- No functional changes; code diff is identical to v1.
v1: https://lore.kernel.org/all/73ACB7391A6DE033+20260421110412.14795-1-zhangdandan@uniontech.com/
---
drivers/net/usb/rtl8150.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 4cda0643afb6..6fc6be0cced6 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -683,6 +683,7 @@ static netdev_tx_t rtl8150_start_xmit(struct sk_buff *skb,
struct net_device *netdev)
{
rtl8150_t *dev = netdev_priv(netdev);
+ unsigned int skb_len;
int count, res;
/* pad the frame and ensure terminating USB packet, datasheet 9.2.3 */
@@ -694,6 +695,14 @@ static netdev_tx_t rtl8150_start_xmit(struct sk_buff *skb,
return NETDEV_TX_OK;
}
+ /*
+ * Cache skb->len before submitting the URB: the URB completion
+ * handler (write_bulk_callback) frees the skb, and it may run
+ * on another CPU before usb_submit_urb() returns, which would
+ * leave skb dangling here.
+ */
+ skb_len = skb->len;
+
netif_stop_queue(netdev);
dev->tx_skb = skb;
usb_fill_bulk_urb(dev->tx_urb, dev->udev, usb_sndbulkpipe(dev->udev, 2),
@@ -709,7 +718,7 @@ static netdev_tx_t rtl8150_start_xmit(struct sk_buff *skb,
}
} else {
netdev->stats.tx_packets++;
- netdev->stats.tx_bytes += skb->len;
+ netdev->stats.tx_bytes += skb_len;
netif_trans_update(netdev);
}
--
2.51.0
^ permalink raw reply related
* [syzbot] [net?] KCSAN: data-race in __udp4_lib_mcast_deliver / udp_lib_unhash (3)
From: syzbot @ 2026-04-23 1:06 UTC (permalink / raw)
To: davem, dsahern, edumazet, horms, kuba, linux-kernel, netdev,
pabeni, syzkaller-bugs, willemdebruijn.kernel
Hello,
syzbot found the following issue on:
HEAD commit: c23719abc330 Merge tag 'x86-urgent-2026-03-08' of git://gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=141b0806580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6b32b22d8934c136
dashboard link: https://syzkaller.appspot.com/bug?extid=04905b8b3523856476c0
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/c0ec3784100d/disk-c23719ab.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/ff5ee751c9be/vmlinux-c23719ab.xz
kernel image: https://storage.googleapis.com/syzbot-assets/1dda25fb6996/bzImage-c23719ab.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+04905b8b3523856476c0@syzkaller.appspotmail.com
==================================================================
BUG: KCSAN: data-race in __udp4_lib_mcast_deliver / udp_lib_unhash
read-write to 0xffff88810194a9c8 of 4 bytes by task 15107 on cpu 0:
udp_lib_unhash+0x1f4/0x3e0 net/ipv4/udp.c:2261
sk_common_release+0x7a/0x230 net/core/sock.c:3990
udp_lib_close+0x15/0x20 include/net/udp.h:324
inet_release+0xcd/0xf0 net/ipv4/af_inet.c:437
__sock_release net/socket.c:662 [inline]
sock_close+0x6b/0x150 net/socket.c:1455
__fput+0x29b/0x650 fs/file_table.c:469
____fput+0x1c/0x30 fs/file_table.c:497
task_work_run+0x130/0x1a0 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0x1f4/0x6f0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x249/0x370 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff88810194a9c8 of 4 bytes by task 15111 on cpu 1:
__udp4_lib_mcast_deliver+0x9a/0x790 net/ipv4/udp.c:2564
__udp4_lib_rcv+0x972/0x1250 net/ipv4/udp.c:2749
udp_rcv+0x4f/0x60 net/ipv4/udp.c:2936
ip_protocol_deliver_rcu+0x3f7/0x790 net/ipv4/ip_input.c:207
ip_local_deliver_finish+0x1fc/0x2f0 net/ipv4/ip_input.c:241
NF_HOOK include/linux/netfilter.h:318 [inline]
ip_local_deliver+0xe8/0x1e0 net/ipv4/ip_input.c:262
dst_input include/net/dst.h:480 [inline]
ip_sublist_rcv_finish net/ipv4/ip_input.c:584 [inline]
ip_list_rcv_finish net/ipv4/ip_input.c:628 [inline]
ip_sublist_rcv+0x415/0x6a0 net/ipv4/ip_input.c:644
ip_list_rcv+0x261/0x290 net/ipv4/ip_input.c:678
__netif_receive_skb_list_ptype net/core/dev.c:6207 [inline]
__netif_receive_skb_list_core+0x4dc/0x500 net/core/dev.c:6254
__netif_receive_skb_list net/core/dev.c:6306 [inline]
netif_receive_skb_list_internal+0x47d/0x5f0 net/core/dev.c:6397
netif_receive_skb_list+0x35/0x220 net/core/dev.c:6449
xdp_recv_frames net/bpf/test_run.c:269 [inline]
xdp_test_run_batch net/bpf/test_run.c:350 [inline]
bpf_test_run_xdp_live+0x104c/0x1360 net/bpf/test_run.c:379
bpf_prog_test_run_xdp+0x57b/0xa10 net/bpf/test_run.c:1397
bpf_prog_test_run+0x204/0x340 kernel/bpf/syscall.c:4722
__sys_bpf+0x52e/0x7e0 kernel/bpf/syscall.c:6246
__do_sys_bpf kernel/bpf/syscall.c:6341 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6339 [inline]
__x64_sys_bpf+0x41/0x50 kernel/bpf/syscall.c:6339
x64_sys_call+0x10cb/0x3020 arch/x86/include/generated/asm/syscalls_64.h:322
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x370 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000001 -> 0x00000000
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 15111 Comm: syz.6.4060 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [PATCH net v2] net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind
From: Morduan Zang @ 2026-04-23 1:05 UTC (permalink / raw)
To: Remi Denis-Courmont, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, netdev, linux-kernel, syzkaller-bugs,
syzbot+706f5eb79044e686c794, zhanjun, Morduan Zang
In-Reply-To: <81A6570B633FF6FE+20260422013807.63087-1-zhangdandan@uniontech.com>
syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via
pn_socket_autobind():
kernel BUG at net/phonet/socket.c:213!
RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline]
RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421
Call Trace:
sock_sendmsg_nosec+0x112/0x150 net/socket.c:797
__sock_sendmsg net/socket.c:812 [inline]
__sys_sendto+0x402/0x590 net/socket.c:2280
...
pn_socket_autobind() calls pn_socket_bind() with port 0 and, on
-EINVAL, assumes the socket was already bound and asserts that the
port is non-zero:
err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn));
if (err != -EINVAL)
return err;
BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
return 0; /* socket was already bound */
However pn_socket_bind() also returns -EINVAL when sk->sk_state is not
TCP_CLOSE, even when the socket has never been bound and pn_port() is
still 0. In that case the BUG_ON() fires and panics the kernel from a
user-triggerable path.
Treat the "bind returned -EINVAL but pn_port() is still 0" case as a
regular error and propagate -EINVAL to the caller instead of crashing.
Existing callers already translate a non-zero return from
pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here
only changes behaviour from panic to a normal errno.
Fixes: ba113a94b750 ("Phonet: common socket glue")
Reported-by: syzbot+706f5eb79044e686c794@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=706f5eb79044e686c794
Suggested-by: Remi Denis-Courmont <courmisch@gmail.com>
Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
Signed-off-by: zhanjun <zhanjun@uniontech.com>
---
Changes in v2:
- Fold the extra port check into the existing -EINVAL test so that
autobind now reads as a single compact "not already bound" guard
using unlikely() (Remi Denis-Courmont).
- Reword the accompanying comment accordingly; no functional change
vs. v1 other than the code-style simplification.
v1: https://lore.kernel.org/all/81A6570B633FF6FE+20260422013807.63087-1-zhangdandan@uniontech.com/
---
net/phonet/socket.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/phonet/socket.c b/net/phonet/socket.c
index 4423d483c630..bbd710d95b97 100644
--- a/net/phonet/socket.c
+++ b/net/phonet/socket.c
@@ -208,9 +208,15 @@ static int pn_socket_autobind(struct socket *sock)
sa.spn_family = AF_PHONET;
err = pn_socket_bind(sock, (struct sockaddr_unsized *)&sa,
sizeof(struct sockaddr_pn));
- if (err != -EINVAL)
+ /*
+ * pn_socket_bind() also returns -EINVAL when sk_state != TCP_CLOSE
+ * without a prior bind, so -EINVAL alone is not sufficient to infer
+ * that the socket was already bound. Only treat it as "already
+ * bound" when the port is non-zero; otherwise propagate the error
+ * instead of crashing the kernel.
+ */
+ if (err != -EINVAL || unlikely(!pn_port(pn_sk(sock->sk)->sobject)))
return err;
- BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));
return 0; /* socket was already bound */
}
--
2.50.1
^ permalink raw reply related
* [PATCH v1 net] udp: Use READ_ONCE()/WRITE_ONCE() for hslot->count.
From: Kuniyuki Iwashima @ 2026-04-23 1:09 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Willem de Bruijn
Cc: Simon Horman, David Held, Kuniyuki Iwashima, Kuniyuki Iwashima,
netdev, syzbot+04905b8b3523856476c0
__udp4_lib_mcast_demux_lookup() and __udp4_lib_mcast_deliver()
reads the number of sockets in the 1-tuple hash table chain
locklessly. [0]
Let's use READ_ONCE() and WRITE_ONCE() for hslot->count.
[0]:
BUG: KCSAN: data-race in __udp4_lib_mcast_deliver / udp_lib_unhash
read-write to 0xffff88810194a9c8 of 4 bytes by task 15107 on cpu 0:
udp_lib_unhash+0x1f4/0x3e0 net/ipv4/udp.c:2261
sk_common_release+0x7a/0x230 net/core/sock.c:3990
udp_lib_close+0x15/0x20 include/net/udp.h:324
inet_release+0xcd/0xf0 net/ipv4/af_inet.c:437
__sock_release net/socket.c:662 [inline]
sock_close+0x6b/0x150 net/socket.c:1455
__fput+0x29b/0x650 fs/file_table.c:469
____fput+0x1c/0x30 fs/file_table.c:497
task_work_run+0x130/0x1a0 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:67 [inline]
exit_to_user_mode_loop+0x1f4/0x6f0 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x249/0x370 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
read to 0xffff88810194a9c8 of 4 bytes by task 15111 on cpu 1:
__udp4_lib_mcast_deliver+0x9a/0x790 net/ipv4/udp.c:2564
__udp4_lib_rcv+0x972/0x1250 net/ipv4/udp.c:2749
udp_rcv+0x4f/0x60 net/ipv4/udp.c:2936
ip_protocol_deliver_rcu+0x3f7/0x790 net/ipv4/ip_input.c:207
ip_local_deliver_finish+0x1fc/0x2f0 net/ipv4/ip_input.c:241
NF_HOOK include/linux/netfilter.h:318 [inline]
ip_local_deliver+0xe8/0x1e0 net/ipv4/ip_input.c:262
dst_input include/net/dst.h:480 [inline]
ip_sublist_rcv_finish net/ipv4/ip_input.c:584 [inline]
ip_list_rcv_finish net/ipv4/ip_input.c:628 [inline]
ip_sublist_rcv+0x415/0x6a0 net/ipv4/ip_input.c:644
ip_list_rcv+0x261/0x290 net/ipv4/ip_input.c:678
__netif_receive_skb_list_ptype net/core/dev.c:6207 [inline]
__netif_receive_skb_list_core+0x4dc/0x500 net/core/dev.c:6254
__netif_receive_skb_list net/core/dev.c:6306 [inline]
netif_receive_skb_list_internal+0x47d/0x5f0 net/core/dev.c:6397
netif_receive_skb_list+0x35/0x220 net/core/dev.c:6449
xdp_recv_frames net/bpf/test_run.c:269 [inline]
xdp_test_run_batch net/bpf/test_run.c:350 [inline]
bpf_test_run_xdp_live+0x104c/0x1360 net/bpf/test_run.c:379
bpf_prog_test_run_xdp+0x57b/0xa10 net/bpf/test_run.c:1397
bpf_prog_test_run+0x204/0x340 kernel/bpf/syscall.c:4722
__sys_bpf+0x52e/0x7e0 kernel/bpf/syscall.c:6246
__do_sys_bpf kernel/bpf/syscall.c:6341 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6339 [inline]
__x64_sys_bpf+0x41/0x50 kernel/bpf/syscall.c:6339
x64_sys_call+0x10cb/0x3020 arch/x86/include/generated/asm/syscalls_64.h:322
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x12c/0x370 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
value changed: 0x00000001 -> 0x00000000
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 15111 Comm: syz.6.4060 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Fixes: 2dc41cff7545 ("udp: Use hash2 for long hash1 chains in __udp*_lib_mcast_deliver.")
Fixes: 63c6f81cdde5 ("udp: ipv4: do not waste time in __udp4_lib_mcast_demux_lookup")
Reported-by: syzbot+04905b8b3523856476c0@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/69e97093.050a0220.24bfd3.0048.GAE@google.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
net/ipv4/udp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 0ac2bf4f8759..f7e6045f5985 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -323,7 +323,7 @@ int udp_lib_get_port(struct sock *sk, unsigned short snum,
sock_set_flag(sk, SOCK_RCU_FREE);
sk_add_node_rcu(sk, &hslot->head);
- hslot->count++;
+ WRITE_ONCE(hslot->count, hslot->count + 1);
sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1);
hslot2 = udp_hashslot2(udptable, udp_sk(sk)->udp_portaddr_hash);
@@ -2200,7 +2200,7 @@ void udp_lib_unhash(struct sock *sk)
if (rcu_access_pointer(sk->sk_reuseport_cb))
reuseport_detach_sock(sk);
if (sk_del_node_init_rcu(sk)) {
- hslot->count--;
+ WRITE_ONCE(hslot->count, hslot->count - 1);
inet_sk(sk)->inet_num = 0;
sock_prot_inuse_add(net, sk->sk_prot, -1);
@@ -2471,7 +2471,7 @@ static int __udp4_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
hash2_any = 0;
hash2 = 0;
hslot = udp_hashslot(udptable, net, hnum);
- use_hash2 = hslot->count > 10;
+ use_hash2 = READ_ONCE(hslot->count) > 10;
offset = offsetof(typeof(*sk), sk_node);
if (use_hash2) {
@@ -2703,7 +2703,7 @@ static struct sock *__udp4_lib_mcast_demux_lookup(struct net *net,
hslot = &udptable->hash[slot];
/* Do not bother scanning a too big list */
- if (hslot->count > 10)
+ if (READ_ONCE(hslot->count) > 10)
return NULL;
result = NULL;
--
2.54.0.rc2.533.g4f5dca5207-goog
^ permalink raw reply related
* Re: [PATCH 19/23] cgroup/cpuset: Improve check for calling housekeeping_update()
From: Chen Ridong @ 2026-04-23 1:10 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Thomas Gleixner, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan
In-Reply-To: <20260421030351.281436-20-longman@redhat.com>
On 2026/4/21 11:03, Waiman Long wrote:
> By making sure that isolated_hk_cpus matches isolated_cpus at boot time,
> we can more accurately determine if calling housekeeping_update()
> is needed by comparing if the two cpumasks are equal. The
> update_housekeeping flag still have a use in cpuset_handle_hotplug()
> to determine if a work function should be queued to invoke
> cpuset_update_sd_hk_unlock() as it is not supposed to look at
> isolated_hk_cpus without holding cpuset_top_mutex.
>
Currently, isolated_hk_cpus is updated within the cpuset_mutex critical section
(before mutex_unlock(&cpuset_mutex)) in cpuset_update_sd_hk_unlock. Therefore, I
think update_housekeeping can now be removed.
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> kernel/cgroup/cpuset.c | 36 ++++++++++++++++++++----------------
> 1 file changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index a4eccb0ec0d1..1b0c50b46a49 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1339,26 +1339,29 @@ static void cpuset_update_sd_hk_unlock(void)
> __releases(&cpuset_mutex)
> __releases(&cpuset_top_mutex)
> {
> + update_housekeeping = false;
> +
> /* force_sd_rebuild will be cleared in rebuild_sched_domains_locked() */
> if (force_sd_rebuild)
> rebuild_sched_domains_locked();
>
> - if (update_housekeeping) {
> - update_housekeeping = false;
> - cpumask_copy(isolated_hk_cpus, isolated_cpus);
> -
> - /*
> - * housekeeping_update() is now called without holding
> - * cpus_read_lock and cpuset_mutex. Only cpuset_top_mutex
> - * is still being held for mutual exclusion.
> - */
> - mutex_unlock(&cpuset_mutex);
> - cpus_read_unlock();
> - WARN_ON_ONCE(housekeeping_update(isolated_hk_cpus, BIT(HK_TYPE_DOMAIN)));
> - mutex_unlock(&cpuset_top_mutex);
> - } else {
> + if (cpumask_equal(isolated_hk_cpus, isolated_cpus)) {
> + /* No housekeeping cpumask update needed */
> cpuset_full_unlock();
> + return;
> }
> +
> + cpumask_copy(isolated_hk_cpus, isolated_cpus);
> +
> + /*
> + * housekeeping_update() is now called without holding
> + * cpus_read_lock and cpuset_mutex. Only cpuset_top_mutex
> + * is still being held for mutual exclusion.
> + */
> + mutex_unlock(&cpuset_mutex);
> + cpus_read_unlock();
> + WARN_ON_ONCE(housekeeping_update(isolated_hk_cpus, BIT(HK_TYPE_DOMAIN)));
> + mutex_unlock(&cpuset_top_mutex);
> }
>
> /*
> @@ -3692,10 +3695,11 @@ int __init cpuset_init(void)
>
> BUG_ON(!alloc_cpumask_var(&cpus_attach, GFP_KERNEL));
>
> - if (housekeeping_enabled(HK_TYPE_DOMAIN_BOOT))
> + if (housekeeping_enabled(HK_TYPE_DOMAIN_BOOT)) {
> cpumask_andnot(isolated_cpus, cpu_possible_mask,
> housekeeping_cpumask(HK_TYPE_DOMAIN_BOOT));
> -
> + cpumask_copy(isolated_hk_cpus, isolated_cpus);
> + }
> return 0;
> }
>
--
Best regards,
Ridong
^ 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