In the Linux kernel, the following vulnerability has been resolved: xsk: avoid data corruption on cq descriptor number Since commit 30f241fcf52a ("xsk: Fix immature cq descriptor production"), the descriptor number is stored in skb control block and xskcqsubmitaddrlocked() relies on it to put the umem addrs onto pool's completion queue. skb control block shouldn't be used for this purpose as after transmit xsk doesn't have control over it and other subsystems could use it. This leads to the following kernel panic due to a NULL pointer dereference. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy) Debian 6.16.12-1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:xskdestructskb+0xd0/0x180 [...] Call Trace: <IRQ> ? napicompletedone+0x7a/0x1a0 iprcvcore+0x1bb/0x340 iprcv+0x30/0x1f0 __netifreceiveskb_onecore+0x85/0xa0 processbacklog+0x87/0x130 __napipoll+0x28/0x180 netrx_action+0x339/0x420 handlesoftirqs+0xdc/0x320 ? handleedgeirq+0x90/0x1e0 dosoftirq.part.0+0x3b/0x60 </IRQ> <TASK> __localbhenable_ip+0x60/0x70 __devdirectxmit+0x14e/0x1f0 __xskgenericxmit+0x482/0xb70 ? __remove_hrtimer+0x41/0xa0 ? __xskgenericxmit+0x51/0xb70 ? rawspinunlockirqrestore+0xe/0x40 xsk_sendmsg+0xda/0x1c0 __sys_sendto+0x1ee/0x200 __x64syssendto+0x24/0x30 dosyscall64+0x84/0x2f0 ? __pfx_pollwake+0x10/0x10 ? _rseqhandlenotifyresume+0xad/0x4c0 ? restorefpregsfromfpstate+0x3c/0x90 ? switchfpureturn+0x5b/0xe0 ? dosyscall64+0x204/0x2f0 ? dosyscall64+0x204/0x2f0 ? dosyscall64+0x204/0x2f0 entrySYSCALL64afterhwframe+0x76/0x7e </TASK> [...] Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Instead use the skb destructorarg pointer along with pointer tagging. As pointers are always aligned to 8B, use the bottom bit to indicate whether this a single address or an allocated struct containing several addresses.