netdev - Re: [syzbot ci] Re: xsk: move cq_cached_prod_lock to avoid touching a cacheline in sending path

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAL+tcoDQ6MyuGRE8mJi_cafqyO0wfgOw5WTqnCvKGbQBhKOGpA@mail.gmail.com>
Date: Tue, 9 Dec 2025 22:15:33 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: syzbot ci <syzbot+ci28a5ab4f329a6a88@...kaller.appspotmail.com>
Cc: ast@...nel.org, bjorn@...nel.org, bpf@...r.kernel.org, 
	daniel@...earbox.net, davem@...emloft.net, edumazet@...gle.com, 
	hawk@...nel.org, john.fastabend@...il.com, jonathan.lemon@...il.com, 
	kernelxing@...cent.com, kuba@...nel.org, maciej.fijalkowski@...el.com, 
	magnus.karlsson@...el.com, netdev@...r.kernel.org, pabeni@...hat.com, 
	sdf@...ichev.me, syzbot@...ts.linux.dev, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot ci] Re: xsk: move cq_cached_prod_lock to avoid touching a
 cacheline in sending path

On Tue, Dec 9, 2025 at 8:12 PM Jason Xing <kerneljasonxing@...il.com> wrote:
>
> On Tue, Dec 9, 2025 at 3:52 PM syzbot ci
> <syzbot+ci28a5ab4f329a6a88@...kaller.appspotmail.com> wrote:
> >
> > syzbot ci has tested the following series
> >
> > [v4] xsk: move cq_cached_prod_lock to avoid touching a cacheline in sending path
> > https://lore.kernel.org/all/20251209031628.28429-1-kerneljasonxing@gmail.com
> > * [PATCH RFC net-next v4] xsk: move cq_cached_prod_lock to avoid touching a cacheline in sending path
> >
> > and found the following issue:
> > BUG: unable to handle kernel NULL pointer dereference in xp_create_and_assign_umem
> >
> > Full report is available here:
> > https://ci.syzbot.org/series/d7e166a7-a880-4ea1-9707-8889afd4ebe8
> >
> > ***
> >
> > BUG: unable to handle kernel NULL pointer dereference in xp_create_and_assign_umem
> >
> > tree:      net-next
> > URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next.git
> > base:      0177f0f07886e54e12c6f18fa58f63e63ddd3c58
> > arch:      amd64
> > compiler:  Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> > config:    https://ci.syzbot.org/builds/d327cc4b-7471-413b-b244-519c6d16d43b/config
> > C repro:   https://ci.syzbot.org/findings/c8f7aeaf-0e2e-43dd-ae9c-ea2dd8db8d34/c_repro
> > syz repro: https://ci.syzbot.org/findings/c8f7aeaf-0e2e-43dd-ae9c-ea2dd8db8d34/syz_repro
>
> Interesting. Only rx logic is initialized while tx not. That causes

Actually, it should not happen or we can say the usage is against what
we expect because at the first time cq and fq need to be both
initialized and then the shared umem function can be used[1]. But the
repro tries to directly use the shared umem at the first time.

[1]:
net/xdp/xsk.c +1401
Corresponding patches can be seen here:
commit 7361f9c3d71 ("xsk: Move fill and completion rings to buffer pool")
commit fe2308328cd2f ("xsk: add umem completion queue support and mmap")

The above two patches make sure that in xdp_umem_validate_queues()
(which was renamed to xsk_validate_queues()) doesn't allow _only one_
of them to be initialized at the first time. To put it in a simpler
way, cq and fq are required to be initialized. So now what I have in
my mind is can we have the same test when using XDP_SHARED_UMEM?

I think this repro found an existing bug before this patch, IIUC.

Thanks,
Jason