netdev - Re: [PATCH bpf-next v3 2/2] xsk: introduce a dedicated local completion queue for each xsk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL+tcoB6eCogZXXxDQ58nxp-VxWFOPR2DP4pyLVxGtjXdWPQXA@mail.gmail.com>
Date: Sun, 4 Jan 2026 14:22:15 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: bot+bpf-ci@...nel.org
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, bjorn@...nel.org, magnus.karlsson@...el.com, 
	maciej.fijalkowski@...el.com, jonathan.lemon@...il.com, sdf@...ichev.me, 
	ast@...nel.org, daniel@...earbox.net, hawk@...nel.org, 
	john.fastabend@...il.com, bpf@...r.kernel.org, netdev@...r.kernel.org, 
	kernelxing@...cent.com, andrii@...nel.org, martin.lau@...nel.org, 
	eddyz87@...il.com, yonghong.song@...ux.dev, clm@...a.com, 
	ihor.solodrai@...ux.dev
Subject: Re: [PATCH bpf-next v3 2/2] xsk: introduce a dedicated local
 completion queue for each xsk

On Sun, Jan 4, 2026 at 11:39 AM <bot+bpf-ci@...nel.org> wrote:
>
> > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > index f41e0b480aa4..0a724cf20fcb 100644
> > --- a/net/xdp/xsk.c
> > +++ b/net/xdp/xsk.c
>
> [ ... ]
>
> > +static void xsk_cq_write_addr(struct sk_buff *skb, u32 desc_processed)
> > +{
> > +     struct xsk_buff_pool *pool = xdp_sk(skb->sk)->pool;
> > +     u32 idx, addr, pos = xsk_get_start_addr(skb);
>              ^^^^
>
> Should addr be u64 here? The lcq->desc[] array stores u64 values
> (descriptor addresses), and xskq_prod_write_addr() expects a u64 parameter.
> Declaring addr as u32 truncates the upper 32 bits when reading from
> lcq->desc[].
>
> For reference, struct local_cq in include/net/xdp_sock.h declares:
>
>     u64 desc[] ____cacheline_aligned_in_smp;
>
> And xskq_prod_write_addr() in net/xdp/xsk_queue.h has signature:
>
>     static inline void xskq_prod_write_addr(struct xsk_queue *q, u32 idx, u64 addr)
>
> If a umem is large enough that descriptor offsets exceed 4GB, this would
> silently write incorrect addresses to the completion queue, causing user
> space to receive corrupted descriptor addresses.

Yes, it can happen. Thanks for pointing this out.