* null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
@ 2025-10-20 4:45 mc36
2025-10-20 6:41 ` Jason Xing
0 siblings, 1 reply; 19+ messages in thread
From: mc36 @ 2025-10-20 4:45 UTC (permalink / raw)
To: Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel
Cc: 1118437, netdev, bpf
hi,
freertr.org xsk dataplane is triggering a null pointer de-reference after sending
a single ip packet from user space to an xsk socket bound to a veth interface.
the same code works fine when using physical interfaces to send packets to...
it does not matter if an ip address is assigned to the veth pair or not...
please find below the reproducer code with some comments on how to use it...
tldr: create a veth pair, bring them up, compile and run the c code...
this happens 10/10 on host or in qemu-system-x86_64-kvm running 6.16.12 or 6.17.2...
if it does not belongs here, just let me know....
have a nice day,
csaba
------------------------------------------------------[cut]---------------------------------------------------------
p4emu login: [ 119.074634] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 119.076747] #PF: supervisor read access in kernel mode
[ 119.078334] #PF: error_code(0x0000) - not-present page
[ 119.079855] PGD 0 P4D 0
[ 119.080648] Oops: Oops: 0000 [#1] SMP NOPTI
[ 119.081993] 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
[ 119.085247] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 119.088065] RIP: 0010:xsk_destruct_skb+0xd0/0x180
[ 119.089502] Code: 40 10 48 89 cf 89 28 e8 9e 7e 07 00 48 89 df 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f e9 c8 cc da ff 48 8b 7b 30 4c 8d 5b 30 <48> 8b 07 4c 8d 67 f8 4c 8d 70
f8 49 39 fb 74 b7 48 89 5c 24 10 4c
[ 119.094947] RSP: 0018:ffffcd5b4012cd48 EFLAGS: 00010002
[ 119.096499] RAX: ffffcd5b40fcf000 RBX: ffff898e05dfcf00 RCX: ffff898e043cf9e8
[ 119.098612] RDX: ffff898e048ccc80 RSI: 0000000000000246 RDI: 0000000000000000
[ 119.100687] RBP: 0000000000000001 R08: 0000000000000000 R09: ffff898e01d21900
[ 119.102794] R10: 0000000000000000 R11: ffff898e05dfcf30 R12: ffff898e05f95000
[ 119.104880] R13: ffff898e043cf900 R14: ffff898e7dd32bd0 R15: 0000000000000002
[ 119.107000] FS: 00007f0cd9e0a6c0(0000) GS:ffff898ede530000(0000) knlGS:0000000000000000
[ 119.109358] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 119.111080] CR2: 0000000000000000 CR3: 00000000043ba003 CR4: 0000000000372ef0
[ 119.113175] Call Trace:
[ 119.113996] <IRQ>
[ 119.114662] ? napi_complete_done+0x7a/0x1a0
[ 119.115952] ip_rcv_core+0x1bb/0x340
[ 119.117050] ip_rcv+0x30/0x1f0
[ 119.118014] __netif_receive_skb_one_core+0x85/0xa0
[ 119.119468] process_backlog+0x87/0x130
[ 119.120617] __napi_poll+0x28/0x180
[ 119.121685] net_rx_action+0x339/0x420
[ 119.122850] handle_softirqs+0xdc/0x320
[ 119.124003] ? handle_edge_irq+0x90/0x1e0
[ 119.125218] do_softirq.part.0+0x3b/0x60
[ 119.126422] </IRQ>
[ 119.127085] <TASK>
[ 119.127753] __local_bh_enable_ip+0x60/0x70
[ 119.128998] __dev_direct_xmit+0x14e/0x1f0
[ 119.130128] __xsk_generic_xmit+0x482/0xb70
[ 119.131184] ? __remove_hrtimer+0x41/0xa0
[ 119.132199] ? __xsk_generic_xmit+0x51/0xb70
[ 119.133300] ? _raw_spin_unlock_irqrestore+0xe/0x40
[ 119.134637] xsk_sendmsg+0xda/0x1c0
[ 119.135580] __sys_sendto+0x1ee/0x200
[ 119.136509] __x64_sys_sendto+0x24/0x30
[ 119.137493] do_syscall_64+0x84/0x2f0
[ 119.138452] ? __pfx_pollwake+0x10/0x10
[ 119.139454] ? __rseq_handle_notify_resume+0xad/0x4c0
[ 119.140718] ? restore_fpregs_from_fpstate+0x3c/0x90
[ 119.141999] ? switch_fpu_return+0x5b/0xe0
[ 119.143023] ? do_syscall_64+0x204/0x2f0
[ 119.144007] ? do_syscall_64+0x204/0x2f0
[ 119.144990] ? do_syscall_64+0x204/0x2f0
[ 119.146022] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 119.147278] RIP: 0033:0x7f0cde0a49ee
[ 119.148217] Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00
00 0f 1f 80 00 00 00 00 48 83 ec 08
[ 119.152877] RSP: 002b:00007f0cd9e09c98 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[ 119.154774] RAX: ffffffffffffffda RBX: 00007f0cd9e0a6c0 RCX: 00007f0cde0a49ee
[ 119.156526] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000029
[ 119.158317] RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000000
[ 119.160078] R10: 0000000000000040 R11: 0000000000000246 R12: 0000000000000405
[ 119.161893] R13: 00007f0ccc055ce0 R14: 0000000000000001 R15: 00007f0cde8db900
[ 119.163646] </TASK>
[ 119.164243] Modules linked in: veth intel_rapl_msr intel_rapl_common iosf_mbi binfmt_misc kvm_intel kvm irqbypass ghash_clmulni_intel sha512_ssse3 sha1_ssse3 aesni_intel rapl
button evdev sg efi_pstore configfs nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci qemu_fw_cfg ip_tables x_tables autofs4 sd_mod
sr_mod cdrom ata_generic ata_piix libata virtio_net scsi_mod net_failover serio_raw failover scsi_common
[ 119.174216] CR2: 0000000000000000
[ 119.175068] ---[ end trace 0000000000000000 ]---
[ 119.176224] RIP: 0010:xsk_destruct_skb+0xd0/0x180
[ 119.177432] Code: 40 10 48 89 cf 89 28 e8 9e 7e 07 00 48 89 df 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f e9 c8 cc da ff 48 8b 7b 30 4c 8d 5b 30 <48> 8b 07 4c 8d 67 f8 4c 8d 70
f8 49 39 fb 74 b7 48 89 5c 24 10 4c
[ 119.182155] RSP: 0018:ffffcd5b4012cd48 EFLAGS: 00010002
[ 119.183462] RAX: ffffcd5b40fcf000 RBX: ffff898e05dfcf00 RCX: ffff898e043cf9e8
[ 119.185237] RDX: ffff898e048ccc80 RSI: 0000000000000246 RDI: 0000000000000000
[ 119.187022] RBP: 0000000000000001 R08: 0000000000000000 R09: ffff898e01d21900
[ 119.188872] R10: 0000000000000000 R11: ffff898e05dfcf30 R12: ffff898e05f95000
[ 119.190693] R13: ffff898e043cf900 R14: ffff898e7dd32bd0 R15: 0000000000000002
[ 119.192655] FS: 00007f0cd9e0a6c0(0000) GS:ffff898ede530000(0000) knlGS:0000000000000000
[ 119.194681] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 119.196244] CR2: 0000000000000000 CR3: 00000000043ba003 CR4: 0000000000372ef0
[ 119.198034] Kernel panic - not syncing: Fatal exception in interrupt
[ 119.199761] Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 119.202403] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
------------------------------------------------------[cut]---------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <pthread.h>
#include <arpa/inet.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <poll.h>
#include <linux/if_link.h>
#include <xdp/xsk.h>
////// gcc xskInt.c -lxdp
////// sudo ip link add veth1 type veth
////// sudo ip link set veth0 up
////// sudo ip link set veth1 up
////// sudo ./a.out
void err(char*buf) {
printf("%s\n", buf);
_exit(1);
}
int main(int argc, char **argv) {
int bpf_flag = XDP_FLAGS_SKB_MODE;
char ifaceName[] = "veth0";
printf("opening interface %s\n", ifaceName);
#define framesNum 1024
struct xsk_umem *ifaceUmem;
struct xsk_socket *ifaceXsk;
struct xsk_ring_prod ifaceFq;
struct xsk_ring_cons ifaceCq;
struct xsk_ring_cons ifaceRx;
struct xsk_ring_prod ifaceTx;
char *ifaceBuf;
struct pollfd ifacePfd;
posix_memalign((void**)&ifaceBuf, getpagesize(), XSK_UMEM__DEFAULT_FRAME_SIZE * 2 * framesNum);
if (ifaceBuf == NULL) err("error allocating buffer");
if (xsk_umem__create(&ifaceUmem, ifaceBuf, XSK_UMEM__DEFAULT_FRAME_SIZE * 2 * framesNum, &ifaceFq, &ifaceCq, NULL) != 0) err("error creating umem");
struct xsk_socket_config cfg;
memset(&cfg, 0, sizeof(cfg));
cfg.rx_size = XSK_RING_CONS__DEFAULT_NUM_DESCS;
cfg.tx_size = XSK_RING_PROD__DEFAULT_NUM_DESCS;
cfg.xdp_flags = bpf_flag;
if (xsk_socket__create(&ifaceXsk, ifaceName, 0, ifaceUmem, &ifaceRx, &ifaceTx, &cfg) != 0) err("error creating xsk");
unsigned int i = 0;
xsk_ring_prod__reserve(&ifaceFq, framesNum, &i);
for (i=0; i < framesNum; i++) *xsk_ring_prod__fill_addr(&ifaceFq, i) = i * XSK_UMEM__DEFAULT_FRAME_SIZE;
xsk_ring_prod__submit(&ifaceFq, framesNum);
memset(&ifacePfd, 0, sizeof (ifacePfd));
ifacePfd.fd = xsk_socket__fd(ifaceXsk);
ifacePfd.events = POLLIN | POLLERR;
setgid(1);
setuid(1);
printf("serving others\n");
unsigned char bufD[] = {0x3a, 0x10, 0x5c, 0x53, 0xb3, 0x5c, 0x0, 0x1e, 0x11, 0x4c, 0x7e, 0x66, 0x8, 0x0, 0x45, 0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x0, 0xff, 0x1, 0xb7, 0xa0, 0x1, 0x1,
0x1, 0xd, 0x1, 0x1, 0x1, 0xe, 0x8, 0x0, 0xa5, 0xfd, 0x16, 0x3b, 0x3b, 0xc7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
int bufS = sizeof(bufD);
unsigned int idx;
idx = xsk_ring_cons__peek(&ifaceCq, 16, &idx);
xsk_ring_cons__release(&ifaceCq, idx);
if (xsk_ring_prod__reserve(&ifaceTx, 1, &idx) < 1) err("error getting index");
struct xdp_desc *dsc = xsk_ring_prod__tx_desc(&ifaceTx, idx);
dsc->addr = (framesNum + (idx % framesNum)) * XSK_UMEM__DEFAULT_FRAME_SIZE;
dsc->options = 0;
dsc->len = bufS;
memcpy(ifaceBuf + dsc->addr, bufD, bufS);
xsk_ring_prod__submit(&ifaceTx, 1);
if (!xsk_ring_prod__needs_wakeup(&ifaceTx)) err("error waking up");
sendto(xsk_socket__fd(ifaceXsk), NULL, 0, MSG_DONTWAIT, NULL, 0);
sleep(10);
}
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-20 4:45 null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space mc36
@ 2025-10-20 6:41 ` Jason Xing
2025-10-20 7:15 ` mc36
2025-10-20 8:55 ` mc36
0 siblings, 2 replies; 19+ messages in thread
From: Jason Xing @ 2025-10-20 6:41 UTC (permalink / raw)
To: mc36
Cc: Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
Hi,
On Mon, Oct 20, 2025 at 12:50 PM mc36 <csmate@nop.hu> wrote:
>
> hi,
>
> freertr.org xsk dataplane is triggering a null pointer de-reference after sending
>
> a single ip packet from user space to an xsk socket bound to a veth interface.
>
> the same code works fine when using physical interfaces to send packets to...
>
> it does not matter if an ip address is assigned to the veth pair or not...
>
> please find below the reproducer code with some comments on how to use it...
>
> tldr: create a veth pair, bring them up, compile and run the c code...
>
> this happens 10/10 on host or in qemu-system-x86_64-kvm running 6.16.12 or 6.17.2...
Thanks for the report.
I'm wondering if you have time to bisect which recent commit has
brought this problem. It looks like it never happens before 6.16?
Thanks,
Jason
>
> if it does not belongs here, just let me know....
>
> have a nice day,
>
> csaba
>
>
> ------------------------------------------------------[cut]---------------------------------------------------------
>
>
> p4emu login: [ 119.074634] BUG: kernel NULL pointer dereference, address: 0000000000000000
> [ 119.076747] #PF: supervisor read access in kernel mode
> [ 119.078334] #PF: error_code(0x0000) - not-present page
> [ 119.079855] PGD 0 P4D 0
> [ 119.080648] Oops: Oops: 0000 [#1] SMP NOPTI
> [ 119.081993] 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
> [ 119.085247] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
> [ 119.088065] RIP: 0010:xsk_destruct_skb+0xd0/0x180
> [ 119.089502] Code: 40 10 48 89 cf 89 28 e8 9e 7e 07 00 48 89 df 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f e9 c8 cc da ff 48 8b 7b 30 4c 8d 5b 30 <48> 8b 07 4c 8d 67 f8 4c 8d 70
> f8 49 39 fb 74 b7 48 89 5c 24 10 4c
> [ 119.094947] RSP: 0018:ffffcd5b4012cd48 EFLAGS: 00010002
> [ 119.096499] RAX: ffffcd5b40fcf000 RBX: ffff898e05dfcf00 RCX: ffff898e043cf9e8
> [ 119.098612] RDX: ffff898e048ccc80 RSI: 0000000000000246 RDI: 0000000000000000
> [ 119.100687] RBP: 0000000000000001 R08: 0000000000000000 R09: ffff898e01d21900
> [ 119.102794] R10: 0000000000000000 R11: ffff898e05dfcf30 R12: ffff898e05f95000
> [ 119.104880] R13: ffff898e043cf900 R14: ffff898e7dd32bd0 R15: 0000000000000002
> [ 119.107000] FS: 00007f0cd9e0a6c0(0000) GS:ffff898ede530000(0000) knlGS:0000000000000000
> [ 119.109358] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 119.111080] CR2: 0000000000000000 CR3: 00000000043ba003 CR4: 0000000000372ef0
> [ 119.113175] Call Trace:
> [ 119.113996] <IRQ>
> [ 119.114662] ? napi_complete_done+0x7a/0x1a0
> [ 119.115952] ip_rcv_core+0x1bb/0x340
> [ 119.117050] ip_rcv+0x30/0x1f0
> [ 119.118014] __netif_receive_skb_one_core+0x85/0xa0
> [ 119.119468] process_backlog+0x87/0x130
> [ 119.120617] __napi_poll+0x28/0x180
> [ 119.121685] net_rx_action+0x339/0x420
> [ 119.122850] handle_softirqs+0xdc/0x320
> [ 119.124003] ? handle_edge_irq+0x90/0x1e0
> [ 119.125218] do_softirq.part.0+0x3b/0x60
> [ 119.126422] </IRQ>
> [ 119.127085] <TASK>
> [ 119.127753] __local_bh_enable_ip+0x60/0x70
> [ 119.128998] __dev_direct_xmit+0x14e/0x1f0
> [ 119.130128] __xsk_generic_xmit+0x482/0xb70
> [ 119.131184] ? __remove_hrtimer+0x41/0xa0
> [ 119.132199] ? __xsk_generic_xmit+0x51/0xb70
> [ 119.133300] ? _raw_spin_unlock_irqrestore+0xe/0x40
> [ 119.134637] xsk_sendmsg+0xda/0x1c0
> [ 119.135580] __sys_sendto+0x1ee/0x200
> [ 119.136509] __x64_sys_sendto+0x24/0x30
> [ 119.137493] do_syscall_64+0x84/0x2f0
> [ 119.138452] ? __pfx_pollwake+0x10/0x10
> [ 119.139454] ? __rseq_handle_notify_resume+0xad/0x4c0
> [ 119.140718] ? restore_fpregs_from_fpstate+0x3c/0x90
> [ 119.141999] ? switch_fpu_return+0x5b/0xe0
> [ 119.143023] ? do_syscall_64+0x204/0x2f0
> [ 119.144007] ? do_syscall_64+0x204/0x2f0
> [ 119.144990] ? do_syscall_64+0x204/0x2f0
> [ 119.146022] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 119.147278] RIP: 0033:0x7f0cde0a49ee
> [ 119.148217] Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00
> 00 0f 1f 80 00 00 00 00 48 83 ec 08
> [ 119.152877] RSP: 002b:00007f0cd9e09c98 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
> [ 119.154774] RAX: ffffffffffffffda RBX: 00007f0cd9e0a6c0 RCX: 00007f0cde0a49ee
> [ 119.156526] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000029
> [ 119.158317] RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000000
> [ 119.160078] R10: 0000000000000040 R11: 0000000000000246 R12: 0000000000000405
> [ 119.161893] R13: 00007f0ccc055ce0 R14: 0000000000000001 R15: 00007f0cde8db900
> [ 119.163646] </TASK>
> [ 119.164243] Modules linked in: veth intel_rapl_msr intel_rapl_common iosf_mbi binfmt_misc kvm_intel kvm irqbypass ghash_clmulni_intel sha512_ssse3 sha1_ssse3 aesni_intel rapl
> button evdev sg efi_pstore configfs nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci qemu_fw_cfg ip_tables x_tables autofs4 sd_mod
> sr_mod cdrom ata_generic ata_piix libata virtio_net scsi_mod net_failover serio_raw failover scsi_common
> [ 119.174216] CR2: 0000000000000000
> [ 119.175068] ---[ end trace 0000000000000000 ]---
> [ 119.176224] RIP: 0010:xsk_destruct_skb+0xd0/0x180
> [ 119.177432] Code: 40 10 48 89 cf 89 28 e8 9e 7e 07 00 48 89 df 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f e9 c8 cc da ff 48 8b 7b 30 4c 8d 5b 30 <48> 8b 07 4c 8d 67 f8 4c 8d 70
> f8 49 39 fb 74 b7 48 89 5c 24 10 4c
> [ 119.182155] RSP: 0018:ffffcd5b4012cd48 EFLAGS: 00010002
> [ 119.183462] RAX: ffffcd5b40fcf000 RBX: ffff898e05dfcf00 RCX: ffff898e043cf9e8
> [ 119.185237] RDX: ffff898e048ccc80 RSI: 0000000000000246 RDI: 0000000000000000
> [ 119.187022] RBP: 0000000000000001 R08: 0000000000000000 R09: ffff898e01d21900
> [ 119.188872] R10: 0000000000000000 R11: ffff898e05dfcf30 R12: ffff898e05f95000
> [ 119.190693] R13: ffff898e043cf900 R14: ffff898e7dd32bd0 R15: 0000000000000002
> [ 119.192655] FS: 00007f0cd9e0a6c0(0000) GS:ffff898ede530000(0000) knlGS:0000000000000000
> [ 119.194681] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 119.196244] CR2: 0000000000000000 CR3: 00000000043ba003 CR4: 0000000000372ef0
> [ 119.198034] Kernel panic - not syncing: Fatal exception in interrupt
> [ 119.199761] Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 119.202403] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
>
>
> ------------------------------------------------------[cut]---------------------------------------------------------
>
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <string.h>
> #include <pthread.h>
> #include <arpa/inet.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <poll.h>
> #include <linux/if_link.h>
> #include <xdp/xsk.h>
>
> ////// gcc xskInt.c -lxdp
> ////// sudo ip link add veth1 type veth
> ////// sudo ip link set veth0 up
> ////// sudo ip link set veth1 up
> ////// sudo ./a.out
>
> void err(char*buf) {
> printf("%s\n", buf);
> _exit(1);
> }
>
>
>
>
> int main(int argc, char **argv) {
>
> int bpf_flag = XDP_FLAGS_SKB_MODE;
>
> char ifaceName[] = "veth0";
> printf("opening interface %s\n", ifaceName);
>
> #define framesNum 1024
>
> struct xsk_umem *ifaceUmem;
> struct xsk_socket *ifaceXsk;
> struct xsk_ring_prod ifaceFq;
> struct xsk_ring_cons ifaceCq;
> struct xsk_ring_cons ifaceRx;
> struct xsk_ring_prod ifaceTx;
> char *ifaceBuf;
> struct pollfd ifacePfd;
>
> posix_memalign((void**)&ifaceBuf, getpagesize(), XSK_UMEM__DEFAULT_FRAME_SIZE * 2 * framesNum);
> if (ifaceBuf == NULL) err("error allocating buffer");
>
> if (xsk_umem__create(&ifaceUmem, ifaceBuf, XSK_UMEM__DEFAULT_FRAME_SIZE * 2 * framesNum, &ifaceFq, &ifaceCq, NULL) != 0) err("error creating umem");
>
> struct xsk_socket_config cfg;
> memset(&cfg, 0, sizeof(cfg));
> cfg.rx_size = XSK_RING_CONS__DEFAULT_NUM_DESCS;
> cfg.tx_size = XSK_RING_PROD__DEFAULT_NUM_DESCS;
> cfg.xdp_flags = bpf_flag;
> if (xsk_socket__create(&ifaceXsk, ifaceName, 0, ifaceUmem, &ifaceRx, &ifaceTx, &cfg) != 0) err("error creating xsk");
>
> unsigned int i = 0;
> xsk_ring_prod__reserve(&ifaceFq, framesNum, &i);
> for (i=0; i < framesNum; i++) *xsk_ring_prod__fill_addr(&ifaceFq, i) = i * XSK_UMEM__DEFAULT_FRAME_SIZE;
> xsk_ring_prod__submit(&ifaceFq, framesNum);
>
> memset(&ifacePfd, 0, sizeof (ifacePfd));
> ifacePfd.fd = xsk_socket__fd(ifaceXsk);
> ifacePfd.events = POLLIN | POLLERR;
>
> setgid(1);
> setuid(1);
> printf("serving others\n");
>
>
> unsigned char bufD[] = {0x3a, 0x10, 0x5c, 0x53, 0xb3, 0x5c, 0x0, 0x1e, 0x11, 0x4c, 0x7e, 0x66, 0x8, 0x0, 0x45, 0x0, 0x0, 0x40, 0x0, 0x0, 0x0, 0x0, 0xff, 0x1, 0xb7, 0xa0, 0x1, 0x1,
> 0x1, 0xd, 0x1, 0x1, 0x1, 0xe, 0x8, 0x0, 0xa5, 0xfd, 0x16, 0x3b, 0x3b, 0xc7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
> int bufS = sizeof(bufD);
>
> unsigned int idx;
> idx = xsk_ring_cons__peek(&ifaceCq, 16, &idx);
> xsk_ring_cons__release(&ifaceCq, idx);
> if (xsk_ring_prod__reserve(&ifaceTx, 1, &idx) < 1) err("error getting index");
> struct xdp_desc *dsc = xsk_ring_prod__tx_desc(&ifaceTx, idx);
> dsc->addr = (framesNum + (idx % framesNum)) * XSK_UMEM__DEFAULT_FRAME_SIZE;
> dsc->options = 0;
> dsc->len = bufS;
> memcpy(ifaceBuf + dsc->addr, bufD, bufS);
> xsk_ring_prod__submit(&ifaceTx, 1);
> if (!xsk_ring_prod__needs_wakeup(&ifaceTx)) err("error waking up");
> sendto(xsk_socket__fd(ifaceXsk), NULL, 0, MSG_DONTWAIT, NULL, 0);
>
> sleep(10);
> }
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-20 6:41 ` Jason Xing
@ 2025-10-20 7:15 ` mc36
2025-10-20 8:55 ` mc36
1 sibling, 0 replies; 19+ messages in thread
From: mc36 @ 2025-10-20 7:15 UTC (permalink / raw)
To: Jason Xing
Cc: Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
hi,
On 10/20/25 08:41, Jason Xing wrote:
>> this happens 10/10 on host or in qemu-system-x86_64-kvm running 6.16.12 or 6.17.2...
>
> Thanks for the report.
>
> I'm wondering if you have time to bisect which recent commit has
> brought this problem. It looks like it never happens before 6.16?
>
no bisect done from my side yet, but i'll try to narrow this down a bit...
(i also just got the report from a packager of freertr.org and found the trigger)
all new info from my side is the decoded stack trace below, i'll do the same
for 6.17 and take a look on earlier kernels to see where it appeared first...
have a nice day,
csaba
mc36@noti:~/Downloads/linux-6.16.12/scripts$ ./decode_stacktrace.sh ../../usr/lib/debug/boot/vmlinux-6.16.12+deb14+1-amd64 < /nfs/temp/linux-xsk.txt
p4emu login: [ 119.074634] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 119.076747] #PF: supervisor read access in kernel mode
[ 119.078334] #PF: error_code(0x0000) - not-present page
[ 119.079855] PGD 0 P4D 0
[ 119.080648] Oops: Oops: 0000 [#1] SMP NOPTI
[ 119.081993] 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
[ 119.085247] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 119.088065] RIP: 0010:xsk_destruct_skb (net/xdp/xsk.c:573 net/xdp/xsk.c:613)
[ 119.089502] Code: 40 10 48 89 cf 89 28 e8 9e 7e 07 00 48 89 df 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f e9 c8 cc da ff 48 8b 7b 30 4c 8d 5b 30 <48> 8b 07 4c 8d 67 f8 4c 8d 70 f8
49 39 fb 74 b7 48 89 5c 24 10 4c
All code
========
0: 40 10 48 89 rex adc %cl,-0x77(%rax)
4: cf iret
5: 89 28 mov %ebp,(%rax)
7: e8 9e 7e 07 00 call 0x77eaa
c: 48 89 df mov %rbx,%rdi
f: 48 83 c4 18 add $0x18,%rsp
13: 5b pop %rbx
14: 5d pop %rbp
15: 41 5c pop %r12
17: 41 5d pop %r13
19: 41 5e pop %r14
1b: 41 5f pop %r15
1d: e9 c8 cc da ff jmp 0xffffffffffdaccea
22: 48 8b 7b 30 mov 0x30(%rbx),%rdi
26: 4c 8d 5b 30 lea 0x30(%rbx),%r11
2a:* 48 8b 07 mov (%rdi),%rax <-- trapping instruction
2d: 4c 8d 67 f8 lea -0x8(%rdi),%r12
31: 4c 8d 70 f8 lea -0x8(%rax),%r14
35: 49 39 fb cmp %rdi,%r11
38: 74 b7 je 0xfffffffffffffff1
3a: 48 89 5c 24 10 mov %rbx,0x10(%rsp)
3f: 4c rex.WR
Code starting with the faulting instruction
===========================================
0: 48 8b 07 mov (%rdi),%rax
3: 4c 8d 67 f8 lea -0x8(%rdi),%r12
7: 4c 8d 70 f8 lea -0x8(%rax),%r14
b: 49 39 fb cmp %rdi,%r11
e: 74 b7 je 0xffffffffffffffc7
10: 48 89 5c 24 10 mov %rbx,0x10(%rsp)
15: 4c rex.WR
[ 119.094947] RSP: 0018:ffffcd5b4012cd48 EFLAGS: 00010002
[ 119.096499] RAX: ffffcd5b40fcf000 RBX: ffff898e05dfcf00 RCX: ffff898e043cf9e8
[ 119.098612] RDX: ffff898e048ccc80 RSI: 0000000000000246 RDI: 0000000000000000
[ 119.100687] RBP: 0000000000000001 R08: 0000000000000000 R09: ffff898e01d21900
[ 119.102794] R10: 0000000000000000 R11: ffff898e05dfcf30 R12: ffff898e05f95000
[ 119.104880] R13: ffff898e043cf900 R14: ffff898e7dd32bd0 R15: 0000000000000002
[ 119.107000] FS: 00007f0cd9e0a6c0(0000) GS:ffff898ede530000(0000) knlGS:0000000000000000
[ 119.109358] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 119.111080] CR2: 0000000000000000 CR3: 00000000043ba003 CR4: 0000000000372ef0
[ 119.113175] Call Trace:
[ 119.113996] <IRQ>
[ 119.114662] ? napi_complete_done (include/linux/list.h:37 (discriminator 2) include/net/gro.h:533 (discriminator 2) include/net/gro.h:528 (discriminator 2) net/core/dev.c:6592
(discriminator 2))
[ 119.115952] ip_rcv_core (include/linux/skbuff.h:3329 net/ipv4/ip_input.c:539)
[ 119.117050] ip_rcv (net/ipv4/ip_input.c:565)
[ 119.118014] __netif_receive_skb_one_core (net/core/dev.c:5989 (discriminator 4))
[ 119.119468] process_backlog (include/linux/rcupdate.h:873 net/core/dev.c:6455)
[ 119.120617] __napi_poll (net/core/dev.c:7426)
[ 119.121685] net_rx_action (net/core/dev.c:7492 net/core/dev.c:7617)
[ 119.122850] handle_softirqs (kernel/softirq.c:579)
[ 119.124003] ? handle_edge_irq (kernel/irq/chip.c:799)
[ 119.125218] do_softirq.part.0 (kernel/softirq.c:480 (discriminator 20))
[ 119.126422] </IRQ>
[ 119.127085] <TASK>
[ 119.127753] __local_bh_enable_ip (kernel/softirq.c:482 kernel/softirq.c:407)
[ 119.128998] __dev_direct_xmit (net/core/dev.c:4786)
[ 119.130128] __xsk_generic_xmit (net/xdp/xsk.c:907)
[ 119.131184] ? __remove_hrtimer (kernel/time/hrtimer.c:1121 (discriminator 1))
[ 119.132199] ? __xsk_generic_xmit (net/xdp/xsk.c:941)
[ 119.133300] ? _raw_spin_unlock_irqrestore (arch/x86/include/asm/paravirt.h:562 arch/x86/include/asm/qspinlock.h:57 include/linux/spinlock.h:204
include/linux/spinlock_api_smp.h:150 kernel/locking/spinlock.c:194)
[ 119.134637] xsk_sendmsg (net/xdp/xsk.c:949 net/xdp/xsk.c:1003 net/xdp/xsk.c:1013)
[ 119.135580] __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2182 (discriminator 1))
[ 119.136509] __x64_sys_sendto (net/socket.c:2189 (discriminator 1) net/socket.c:2185 (discriminator 1) net/socket.c:2185 (discriminator 1))
[ 119.137493] do_syscall_64 (arch/x86/entry/syscall_64.c:66 (discriminator 1) arch/x86/entry/syscall_64.c:97 (discriminator 1))
[ 119.138452] ? __pfx_pollwake (fs/select.c:209)
[ 119.139454] ? __rseq_handle_notify_resume (kernel/rseq.c:439 (discriminator 1))
[ 119.140718] ? restore_fpregs_from_fpstate (arch/x86/kernel/fpu/xstate.h:240 arch/x86/kernel/fpu/core.c:205)
[ 119.141999] ? switch_fpu_return (arch/x86/kernel/fpu/context.h:49 (discriminator 5) arch/x86/kernel/fpu/context.h:76 (discriminator 5) arch/x86/kernel/fpu/core.c:830
(discriminator 5))
[ 119.143023] ? do_syscall_64 (arch/x86/include/asm/entry-common.h:57 arch/x86/include/asm/entry-common.h:66 include/linux/entry-common.h:332 include/linux/entry-common.h:414
include/linux/entry-common.h:449 arch/x86/entry/syscall_64.c:103)
[ 119.144007] ? do_syscall_64 (arch/x86/include/asm/entry-common.h:57 arch/x86/include/asm/entry-common.h:66 include/linux/entry-common.h:332 include/linux/entry-common.h:414
include/linux/entry-common.h:449 arch/x86/entry/syscall_64.c:103)
[ 119.144990] ? do_syscall_64 (arch/x86/include/asm/entry-common.h:57 arch/x86/include/asm/entry-common.h:66 include/linux/entry-common.h:332 include/linux/entry-common.h:414
include/linux/entry-common.h:449 arch/x86/entry/syscall_64.c:103)
[ 119.146022] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
[ 119.147278] RIP: 0033:0x7f0cde0a49ee
[ 119.148217] Code: 08 0f 85 f5 4b ff ff 49 89 fb 48 89 f0 48 89 d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00 00 00 00
0f 1f 80 00 00 00 00 48 83 ec 08
All code
========
0: 08 0f or %cl,(%rdi)
2: 85 f5 test %esi,%ebp
4: 4b ff rex.WXB (bad)
6: ff 49 89 decl -0x77(%rcx)
9: fb sti
a: 48 89 f0 mov %rsi,%rax
d: 48 89 d7 mov %rdx,%rdi
10: 48 89 ce mov %rcx,%rsi
13: 4c 89 c2 mov %r8,%rdx
16: 4d 89 ca mov %r9,%r10
19: 4c 8b 44 24 08 mov 0x8(%rsp),%r8
1e: 4c 8b 4c 24 10 mov 0x10(%rsp),%r9
23: 4c 89 5c 24 08 mov %r11,0x8(%rsp)
28: 0f 05 syscall
2a:* c3 ret <-- trapping instruction
2b: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
32: 00 00 00
35: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
3c: 48 83 ec 08 sub $0x8,%rsp
Code starting with the faulting instruction
===========================================
0: c3 ret
1: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
8: 00 00 00
b: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
12: 48 83 ec 08 sub $0x8,%rsp
[ 119.152877] RSP: 002b:00007f0cd9e09c98 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[ 119.154774] RAX: ffffffffffffffda RBX: 00007f0cd9e0a6c0 RCX: 00007f0cde0a49ee
[ 119.156526] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000029
[ 119.158317] RBP: 0000000000000005 R08: 0000000000000000 R09: 0000000000000000
[ 119.160078] R10: 0000000000000040 R11: 0000000000000246 R12: 0000000000000405
[ 119.161893] R13: 00007f0ccc055ce0 R14: 0000000000000001 R15: 00007f0cde8db900
[ 119.163646] </TASK>
[ 119.164243] Modules linked in: veth intel_rapl_msr intel_rapl_common iosf_mbi binfmt_misc kvm_intel kvm irqbypass ghash_clmulni_intel sha512_ssse3 sha1_ssse3 aesni_intel rapl
button evdev sg efi_pstore configfs nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci qemu_fw_cfg ip_tables x_tables autofs4 sd_mod
sr_mod cdrom ata_generic ata_piix libata virtio_net scsi_mod net_failover serio_raw failover scsi_common
[ 119.174216] CR2: 0000000000000000
[ 119.175068] ---[ end trace 0000000000000000 ]---
[ 119.176224] RIP: 0010:xsk_destruct_skb (net/xdp/xsk.c:573 net/xdp/xsk.c:613)
[ 119.177432] Code: 40 10 48 89 cf 89 28 e8 9e 7e 07 00 48 89 df 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f e9 c8 cc da ff 48 8b 7b 30 4c 8d 5b 30 <48> 8b 07 4c 8d 67 f8 4c 8d 70 f8
49 39 fb 74 b7 48 89 5c 24 10 4c
All code
========
0: 40 10 48 89 rex adc %cl,-0x77(%rax)
4: cf iret
5: 89 28 mov %ebp,(%rax)
7: e8 9e 7e 07 00 call 0x77eaa
c: 48 89 df mov %rbx,%rdi
f: 48 83 c4 18 add $0x18,%rsp
13: 5b pop %rbx
14: 5d pop %rbp
15: 41 5c pop %r12
17: 41 5d pop %r13
19: 41 5e pop %r14
1b: 41 5f pop %r15
1d: e9 c8 cc da ff jmp 0xffffffffffdaccea
22: 48 8b 7b 30 mov 0x30(%rbx),%rdi
26: 4c 8d 5b 30 lea 0x30(%rbx),%r11
2a:* 48 8b 07 mov (%rdi),%rax <-- trapping instruction
2d: 4c 8d 67 f8 lea -0x8(%rdi),%r12
31: 4c 8d 70 f8 lea -0x8(%rax),%r14
35: 49 39 fb cmp %rdi,%r11
38: 74 b7 je 0xfffffffffffffff1
3a: 48 89 5c 24 10 mov %rbx,0x10(%rsp)
3f: 4c rex.WR
Code starting with the faulting instruction
===========================================
0: 48 8b 07 mov (%rdi),%rax
3: 4c 8d 67 f8 lea -0x8(%rdi),%r12
7: 4c 8d 70 f8 lea -0x8(%rax),%r14
b: 49 39 fb cmp %rdi,%r11
e: 74 b7 je 0xffffffffffffffc7
10: 48 89 5c 24 10 mov %rbx,0x10(%rsp)
15: 4c rex.WR
[ 119.182155] RSP: 0018:ffffcd5b4012cd48 EFLAGS: 00010002
[ 119.183462] RAX: ffffcd5b40fcf000 RBX: ffff898e05dfcf00 RCX: ffff898e043cf9e8
[ 119.185237] RDX: ffff898e048ccc80 RSI: 0000000000000246 RDI: 0000000000000000
[ 119.187022] RBP: 0000000000000001 R08: 0000000000000000 R09: ffff898e01d21900
[ 119.188872] R10: 0000000000000000 R11: ffff898e05dfcf30 R12: ffff898e05f95000
[ 119.190693] R13: ffff898e043cf900 R14: ffff898e7dd32bd0 R15: 0000000000000002
[ 119.192655] FS: 00007f0cd9e0a6c0(0000) GS:ffff898ede530000(0000) knlGS:0000000000000000
[ 119.194681] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 119.196244] CR2: 0000000000000000 CR3: 00000000043ba003 CR4: 0000000000372ef0
[ 119.198034] Kernel panic - not syncing: Fatal exception in interrupt
[ 119.199761] Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 119.202403] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
mc36@noti:~/Downloads/linux-6.16.12/scripts$
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-20 6:41 ` Jason Xing
2025-10-20 7:15 ` mc36
@ 2025-10-20 8:55 ` mc36
2025-10-20 9:04 ` Jason Xing
1 sibling, 1 reply; 19+ messages in thread
From: mc36 @ 2025-10-20 8:55 UTC (permalink / raw)
To: Jason Xing
Cc: Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
hi,
On 10/20/25 08:41, Jason Xing wrote:
> Hi,
>
>> this happens 10/10 on host or in qemu-system-x86_64-kvm running 6.16.12 or 6.17.2...
>
> Thanks for the report.
>
> I'm wondering if you have time to bisect which recent commit has
> brought this problem. It looks like it never happens before 6.16?
>
and now confirming that 6.16.7 survives the reproducer code and 6.16.8 crashes...
below is the decoded and raw 6.17 trace... regarding the exact commit hash, i
would leave the chance for someone with much more resources than i have at hand....
have a nice day,
csaba
mc36@noti:~/Downloads/linux-6.17.2/scripts$ ./decode_stacktrace.sh ../../usr/lib/debug/boot/
System.map-6.17.2-cloud-amd64 vmlinux-6.17.2-cloud-amd64
mc36@noti:~/Downloads/linux-6.17.2/scripts$ ./decode_stacktrace.sh ../../usr/lib/debug/boot/vmlinux-6.17.2-cloud-amd64 < ../../6172.txt
p4emu login: [ 171.272491] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 171.274678] #PF: supervisor read access in kernel mode
[ 171.276216] #PF: error_code(0x0000) - not-present page
[ 171.277732] PGD 0 P4D 0
[ 171.278531] Oops: Oops: 0000 [#1] SMP NOPTI
[ 171.279806] CPU: 3 UID: 1 PID: 798 Comm: a.out Not tainted 6.17.2-cloud-amd64 #1 PREEMPT(lazy) Debian 6.17.2-1~exp1
[ 171.282885] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 171.285663] RIP: 0010:xsk_destruct_skb (net/xdp/xsk.c:577 net/xdp/xsk.c:617)
[ 171.288015] Code: 48 89 df 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f e9 1f a5 d9 ff 48 8b 43 30 4c 8d 4b 30 48 89 c7 49 39 c1 74 bf 4c 8d 60 f8 <48> 8b 00 4c 89 3c 24 4d 89 cf 48
89 5c 24 08 89 d3 48 89 74 24 10
All code
========
0: 48 89 df mov %rbx,%rdi
3: 48 83 c4 18 add $0x18,%rsp
7: 5b pop %rbx
8: 5d pop %rbp
9: 41 5c pop %r12
b: 41 5d pop %r13
d: 41 5e pop %r14
f: 41 5f pop %r15
11: e9 1f a5 d9 ff jmp 0xffffffffffd9a535
16: 48 8b 43 30 mov 0x30(%rbx),%rax
1a: 4c 8d 4b 30 lea 0x30(%rbx),%r9
1e: 48 89 c7 mov %rax,%rdi
21: 49 39 c1 cmp %rax,%r9
24: 74 bf je 0xffffffffffffffe5
26: 4c 8d 60 f8 lea -0x8(%rax),%r12
2a:* 48 8b 00 mov (%rax),%rax <-- trapping instruction
2d: 4c 89 3c 24 mov %r15,(%rsp)
31: 4d 89 cf mov %r9,%r15
34: 48 89 5c 24 08 mov %rbx,0x8(%rsp)
39: 89 d3 mov %edx,%ebx
3b: 48 89 74 24 10 mov %rsi,0x10(%rsp)
Code starting with the faulting instruction
===========================================
0: 48 8b 00 mov (%rax),%rax
3: 4c 89 3c 24 mov %r15,(%rsp)
7: 4d 89 cf mov %r9,%r15
a: 48 89 5c 24 08 mov %rbx,0x8(%rsp)
f: 89 d3 mov %edx,%ebx
11: 48 89 74 24 10 mov %rsi,0x10(%rsp)
[ 171.293459] RSP: 0018:ffffcb43c0160d48 EFLAGS: 00010086
[ 171.295023] RAX: 0000000000000000 RBX: ffff8a660484e500 RCX: 0000000000000000
[ 171.297112] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000000
[ 171.299266] RBP: 0000000000000001 R08: ffff8a66023b4780 R09: ffff8a660484e530
[ 171.301348] R10: 0000000000000000 R11: fffff1384008ed00 R12: fffffffffffffff8
[ 171.303453] R13: ffff8a667ddb2c50 R14: ffff8a6603c59400 R15: ffff8a6603c594e8
[ 171.305609] FS: 00007fd4cdcad740(0000) GS:ffff8a66c87ee000(0000) knlGS:0000000000000000
[ 171.307969] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 171.309663] CR2: 0000000000000000 CR3: 000000000593e003 CR4: 0000000000372ef0
[ 171.311756] Call Trace:
[ 171.313372] <IRQ>
[ 171.314083] ? napi_complete_done (include/linux/list.h:37 (discriminator 2) include/net/gro.h:533 (discriminator 2) include/net/gro.h:528 (discriminator 2) include/net/gro.h:540
(discriminator 2) net/core/dev.c:6593 (discriminator 2))
[ 171.315355] ip_rcv_core (include/linux/skbuff.h:3329 net/ipv4/ip_input.c:545)
[ 171.316400] ip_rcv (net/ipv4/ip_input.c:571)
[ 171.317303] __netif_receive_skb_one_core (net/core/dev.c:5991 (discriminator 6))
[ 171.318720] process_backlog (include/linux/rcupdate.h:873 net/core/dev.c:6457)
[ 171.319804] __napi_poll (net/core/dev.c:7506)
[ 171.320776] net_rx_action (net/core/dev.c:7569 net/core/dev.c:7696)
[ 171.321816] handle_softirqs (kernel/softirq.c:579)
[ 171.322885] do_softirq.part.0 (kernel/softirq.c:480 (discriminator 25))
[ 171.323949] </IRQ>
[ 171.324510] <TASK>
[ 171.325070] __local_bh_enable_ip (kernel/softirq.c:482 kernel/softirq.c:407)
[ 171.326122] __dev_direct_xmit (net/core/dev.c:4786)
[ 171.327208] __xsk_generic_xmit (net/xdp/xsk.c:912)
[ 171.328253] ? obj_cgroup_charge_account (mm/memcontrol.c:2939 (discriminator 2) mm/memcontrol.c:3071 (discriminator 2))
[ 171.329506] xsk_sendmsg (net/xdp/xsk.c:953 net/xdp/xsk.c:1007 net/xdp/xsk.c:1017)
[ 171.330424] __sys_sendto (net/socket.c:714 (discriminator 20) net/socket.c:729 (discriminator 20) net/socket.c:2228 (discriminator 20))
[ 171.331380] __x64_sys_sendto (net/socket.c:2235 (discriminator 1) net/socket.c:2231 (discriminator 1) net/socket.c:2231 (discriminator 1))
[ 171.332351] do_syscall_64 (arch/x86/entry/syscall_64.c:66 (discriminator 1) arch/x86/entry/syscall_64.c:97 (discriminator 1))
[ 171.333308] ? ttwu_queue_wakelist (kernel/sched/core.c:3988 kernel/sched/core.c:3983)
[ 171.334449] ? set_task_cpu (kernel/sched/sched.h:2168 kernel/sched/sched.h:2199 kernel/sched/core.c:3372)
[ 171.335449] ? _raw_spin_unlock_irqrestore (arch/x86/include/asm/paravirt.h:562 arch/x86/include/asm/qspinlock.h:57 include/linux/spinlock.h:204
include/linux/spinlock_api_smp.h:150 kernel/locking/spinlock.c:194)
[ 171.336685] ? try_to_wake_up (kernel/sched/core.c:4331)
[ 171.337696] ? kick_pool (kernel/workqueue.c:1285)
[ 171.338643] ? __tty_insert_flip_string_flags (drivers/tty/tty_buffer.c:318 (discriminator 25))
[ 171.339978] ? tty_insert_flip_string_and_push_buffer (drivers/tty/tty_buffer.c:565)
[ 171.341477] ? remove_wait_queue (include/linux/list.h:215 (discriminator 1) include/linux/list.h:229 (discriminator 1) include/linux/wait.h:209 (discriminator 1)
kernel/sched/wait.c:74 (discriminator 1))
[ 171.342552] ? _raw_spin_unlock_irqrestore (arch/x86/include/asm/paravirt.h:562 arch/x86/include/asm/qspinlock.h:57 include/linux/spinlock.h:204
include/linux/spinlock_api_smp.h:150 kernel/locking/spinlock.c:194)
[ 171.343788] ? n_tty_write (drivers/tty/n_tty.c:2428 (discriminator 1))
[ 171.344746] ? _raw_spin_unlock_irqrestore (arch/x86/include/asm/paravirt.h:562 arch/x86/include/asm/qspinlock.h:57 include/linux/spinlock.h:204
include/linux/spinlock_api_smp.h:150 kernel/locking/spinlock.c:194)
[ 171.345974] ? __wake_up (kernel/sched/wait.c:129 kernel/sched/wait.c:146)
[ 171.346880] ? file_tty_write.isra.0 (drivers/tty/tty_io.c:1082)
[ 171.348058] ? vfs_write (fs/read_write.c:593 fs/read_write.c:686)
[ 171.348975] ? ksys_write (fs/read_write.c:739)
[ 171.349868] ? do_syscall_64 (arch/x86/include/asm/entry-common.h:65 (discriminator 1) include/linux/irq-entry-common.h:227 (discriminator 1) include/linux/entry-common.h:175
(discriminator 1) include/linux/entry-common.h:210 (discriminator 1) arch/x86/entry/syscall_64.c:103 (discriminator 1))
[ 171.350877] ? do_user_addr_fault (arch/x86/mm/fault.c:1337)
[ 171.351993] ? exc_page_fault (arch/x86/include/asm/paravirt.h:666 arch/x86/mm/fault.c:1484 arch/x86/mm/fault.c:1532)
[ 171.353032] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
[ 171.354303] RIP: 0033:0x7fd4cdeb6687
[ 171.355252] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2
39 83 fa 08 75 de e8 23 ff ff ff
All code
========
0: 48 89 fa mov %rdi,%rdx
3: 4c 89 df mov %r11,%rdi
6: e8 58 b3 00 00 call 0xb363
b: 8b 93 08 03 00 00 mov 0x308(%rbx),%edx
11: 59 pop %rcx
12: 5e pop %rsi
13: 48 83 f8 fc cmp $0xfffffffffffffffc,%rax
17: 74 1a je 0x33
19: 5b pop %rbx
1a: c3 ret
1b: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
22: 00
23: 48 8b 44 24 10 mov 0x10(%rsp),%rax
28: 0f 05 syscall
2a:* 5b pop %rbx <-- trapping instruction
2b: c3 ret
2c: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
33: 83 e2 39 and $0x39,%edx
36: 83 fa 08 cmp $0x8,%edx
39: 75 de jne 0x19
3b: e8 23 ff ff ff call 0xffffffffffffff63
Code starting with the faulting instruction
===========================================
0: 5b pop %rbx
1: c3 ret
2: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
9: 83 e2 39 and $0x39,%edx
c: 83 fa 08 cmp $0x8,%edx
f: 75 de jne 0xffffffffffffffef
11: e8 23 ff ff ff call 0xffffffffffffff39
[ 171.359811] RSP: 002b:00007ffcfccf4800 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
[ 171.361671] RAX: ffffffffffffffda RBX: 00007fd4cdcad740 RCX: 00007fd4cdeb6687
[ 171.363457] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
[ 171.365232] RBP: 00007ffcfccf4ad0 R08: 0000000000000000 R09: 0000000000000000
[ 171.367016] R10: 0000000000000040 R11: 0000000000000202 R12: 0000000000000000
[ 171.368807] R13: 00007ffcfccf4bf8 R14: 00007fd4ce082000 R15: 00005646beb2adc8
[ 171.370582] </TASK>
[ 171.371203] Modules linked in: veth intel_rapl_msr intel_rapl_common binfmt_misc iosf_mbi kvm_intel kvm irqbypass ghash_clmulni_intel aesni_intel rapl button evdev sg efi_pstore
configfs nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci qemu_fw_cfg autofs4 sr_mod sd_mod cdrom ata_generic ata_piix libata
virtio_net scsi_mod net_failover serio_raw failover scsi_common
[ 171.380065] CR2: 0000000000000000
[ 171.380992] ---[ end trace 0000000000000000 ]---
[ 171.382231] RIP: 0010:xsk_destruct_skb (net/xdp/xsk.c:577 net/xdp/xsk.c:617)
[ 171.383454] Code: 48 89 df 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f e9 1f a5 d9 ff 48 8b 43 30 4c 8d 4b 30 48 89 c7 49 39 c1 74 bf 4c 8d 60 f8 <48> 8b 00 4c 89 3c 24 4d 89 cf 48
89 5c 24 08 89 d3 48 89 74 24 10
All code
========
0: 48 89 df mov %rbx,%rdi
3: 48 83 c4 18 add $0x18,%rsp
7: 5b pop %rbx
8: 5d pop %rbp
9: 41 5c pop %r12
b: 41 5d pop %r13
d: 41 5e pop %r14
f: 41 5f pop %r15
11: e9 1f a5 d9 ff jmp 0xffffffffffd9a535
16: 48 8b 43 30 mov 0x30(%rbx),%rax
1a: 4c 8d 4b 30 lea 0x30(%rbx),%r9
1e: 48 89 c7 mov %rax,%rdi
21: 49 39 c1 cmp %rax,%r9
24: 74 bf je 0xffffffffffffffe5
26: 4c 8d 60 f8 lea -0x8(%rax),%r12
2a:* 48 8b 00 mov (%rax),%rax <-- trapping instruction
2d: 4c 89 3c 24 mov %r15,(%rsp)
31: 4d 89 cf mov %r9,%r15
34: 48 89 5c 24 08 mov %rbx,0x8(%rsp)
39: 89 d3 mov %edx,%ebx
3b: 48 89 74 24 10 mov %rsi,0x10(%rsp)
Code starting with the faulting instruction
===========================================
0: 48 8b 00 mov (%rax),%rax
3: 4c 89 3c 24 mov %r15,(%rsp)
7: 4d 89 cf mov %r9,%r15
a: 48 89 5c 24 08 mov %rbx,0x8(%rsp)
f: 89 d3 mov %edx,%ebx
11: 48 89 74 24 10 mov %rsi,0x10(%rsp)
[ 171.388004] RSP: 0018:ffffcb43c0160d48 EFLAGS: 00010086
[ 171.389300] RAX: 0000000000000000 RBX: ffff8a660484e500 RCX: 0000000000000000
[ 171.391131] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000000
[ 171.392879] RBP: 0000000000000001 R08: ffff8a66023b4780 R09: ffff8a660484e530
[ 171.394689] R10: 0000000000000000 R11: fffff1384008ed00 R12: fffffffffffffff8
[ 171.396490] R13: ffff8a667ddb2c50 R14: ffff8a6603c59400 R15: ffff8a6603c594e8
[ 171.398252] FS: 00007fd4cdcad740(0000) GS:ffff8a66c87ee000(0000) knlGS:0000000000000000
[ 171.400259] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 171.401669] CR2: 0000000000000000 CR3: 000000000593e003 CR4: 0000000000372ef0
[ 171.403446] Kernel panic - not syncing: Fatal exception in interrupt
[ 171.405183] Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 171.407880] Rebooting in 10 seconds..
p4emu login: [ 171.272491] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ 171.274678] #PF: supervisor read access in kernel mode
[ 171.276216] #PF: error_code(0x0000) - not-present page
[ 171.277732] PGD 0 P4D 0
[ 171.278531] Oops: Oops: 0000 [#1] SMP NOPTI
[ 171.279806] CPU: 3 UID: 1 PID: 798 Comm: a.out Not tainted 6.17.2-cloud-amd64 #1 PREEMPT(lazy) Debian 6.17.2-1~exp1
[ 171.282885] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014
[ 171.285663] RIP: 0010:xsk_destruct_skb+0xd5/0x180
[ 171.288015] Code: 48 89 df 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f e9 1f a5 d9 ff 48 8b 43 30 4c 8d 4b 30 48 89 c7 49 39 c1 74 bf 4c 8d 60 f8 <48> 8b 00 4c 89 3c 24 4d 89 cf
48 89 5c 24 08 89 d3 48 89 74 24 10
[ 171.293459] RSP: 0018:ffffcb43c0160d48 EFLAGS: 00010086
[ 171.295023] RAX: 0000000000000000 RBX: ffff8a660484e500 RCX: 0000000000000000
[ 171.297112] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000000
[ 171.299266] RBP: 0000000000000001 R08: ffff8a66023b4780 R09: ffff8a660484e530
[ 171.301348] R10: 0000000000000000 R11: fffff1384008ed00 R12: fffffffffffffff8
[ 171.303453] R13: ffff8a667ddb2c50 R14: ffff8a6603c59400 R15: ffff8a6603c594e8
[ 171.305609] FS: 00007fd4cdcad740(0000) GS:ffff8a66c87ee000(0000) knlGS:0000000000000000
[ 171.307969] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 171.309663] CR2: 0000000000000000 CR3: 000000000593e003 CR4: 0000000000372ef0
[ 171.311756] Call Trace:
[ 171.313372] <IRQ>
[ 171.314083] ? napi_complete_done+0x82/0x1c0
[ 171.315355] ip_rcv_core+0x1bd/0x350
[ 171.316400] ip_rcv+0x30/0x1f0
[ 171.317303] __netif_receive_skb_one_core+0x85/0xa0
[ 171.318720] process_backlog+0x87/0x130
[ 171.319804] __napi_poll+0x2e/0x1e0
[ 171.320776] net_rx_action+0x338/0x420
[ 171.321816] handle_softirqs+0xd4/0x310
[ 171.322885] do_softirq.part.0+0x3b/0x60
[ 171.323949] </IRQ>
[ 171.324510] <TASK>
[ 171.325070] __local_bh_enable_ip+0x60/0x70
[ 171.326122] __dev_direct_xmit+0x146/0x1e0
[ 171.327208] __xsk_generic_xmit+0x4a7/0xba0
[ 171.328253] ? obj_cgroup_charge_account+0x145/0x420
[ 171.329506] xsk_sendmsg+0xe3/0x1c0
[ 171.330424] __sys_sendto+0x1f2/0x200
[ 171.331380] __x64_sys_sendto+0x24/0x30
[ 171.332351] do_syscall_64+0x82/0x2f0
[ 171.333308] ? ttwu_queue_wakelist+0x13d/0x230
[ 171.334449] ? set_task_cpu+0xc4/0x1d0
[ 171.335449] ? _raw_spin_unlock_irqrestore+0xe/0x40
[ 171.336685] ? try_to_wake_up+0x371/0x8b0
[ 171.337696] ? kick_pool+0x5f/0x180
[ 171.338643] ? __tty_insert_flip_string_flags+0x93/0x120
[ 171.339978] ? tty_insert_flip_string_and_push_buffer+0x8d/0xc0
[ 171.341477] ? remove_wait_queue+0x24/0x60
[ 171.342552] ? _raw_spin_unlock_irqrestore+0xe/0x40
[ 171.343788] ? n_tty_write+0x3e1/0x550
[ 171.344746] ? _raw_spin_unlock_irqrestore+0xe/0x40
[ 171.345974] ? __wake_up+0x44/0x60
[ 171.346880] ? file_tty_write.isra.0+0x211/0x2c0
[ 171.348058] ? vfs_write+0x25a/0x480
[ 171.348975] ? ksys_write+0x73/0xf0
[ 171.349868] ? do_syscall_64+0xbb/0x2f0
[ 171.350877] ? do_user_addr_fault+0x21a/0x690
[ 171.351993] ? exc_page_fault+0x74/0x180
[ 171.353032] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 171.354303] RIP: 0033:0x7fd4cdeb6687
[ 171.355252] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83
e2 39 83 fa 08 75 de e8 23 ff ff ff
[ 171.359811] RSP: 002b:00007ffcfccf4800 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
[ 171.361671] RAX: ffffffffffffffda RBX: 00007fd4cdcad740 RCX: 00007fd4cdeb6687
[ 171.363457] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003
[ 171.365232] RBP: 00007ffcfccf4ad0 R08: 0000000000000000 R09: 0000000000000000
[ 171.367016] R10: 0000000000000040 R11: 0000000000000202 R12: 0000000000000000
[ 171.368807] R13: 00007ffcfccf4bf8 R14: 00007fd4ce082000 R15: 00005646beb2adc8
[ 171.370582] </TASK>
[ 171.371203] Modules linked in: veth intel_rapl_msr intel_rapl_common binfmt_misc iosf_mbi kvm_intel kvm irqbypass ghash_clmulni_intel aesni_intel rapl button evdev sg efi_pstore
configfs nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci qemu_fw_cfg autofs4 sr_mod sd_mod cdrom ata_generic ata_piix libata
virtio_net scsi_mod net_failover serio_raw failover scsi_common
[ 171.380065] CR2: 0000000000000000
[ 171.380992] ---[ end trace 0000000000000000 ]---
[ 171.382231] RIP: 0010:xsk_destruct_skb+0xd5/0x180
[ 171.383454] Code: 48 89 df 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e 41 5f e9 1f a5 d9 ff 48 8b 43 30 4c 8d 4b 30 48 89 c7 49 39 c1 74 bf 4c 8d 60 f8 <48> 8b 00 4c 89 3c 24 4d 89 cf
48 89 5c 24 08 89 d3 48 89 74 24 10
[ 171.388004] RSP: 0018:ffffcb43c0160d48 EFLAGS: 00010086
[ 171.389300] RAX: 0000000000000000 RBX: ffff8a660484e500 RCX: 0000000000000000
[ 171.391131] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000000
[ 171.392879] RBP: 0000000000000001 R08: ffff8a66023b4780 R09: ffff8a660484e530
[ 171.394689] R10: 0000000000000000 R11: fffff1384008ed00 R12: fffffffffffffff8
[ 171.396490] R13: ffff8a667ddb2c50 R14: ffff8a6603c59400 R15: ffff8a6603c594e8
[ 171.398252] FS: 00007fd4cdcad740(0000) GS:ffff8a66c87ee000(0000) knlGS:0000000000000000
[ 171.400259] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 171.401669] CR2: 0000000000000000 CR3: 000000000593e003 CR4: 0000000000372ef0
[ 171.403446] Kernel panic - not syncing: Fatal exception in interrupt
[ 171.405183] Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 171.407880] Rebooting in 10 seconds..
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-20 8:55 ` mc36
@ 2025-10-20 9:04 ` Jason Xing
2025-10-20 9:18 ` mc36
2025-10-20 21:31 ` mc36
0 siblings, 2 replies; 19+ messages in thread
From: Jason Xing @ 2025-10-20 9:04 UTC (permalink / raw)
To: mc36
Cc: Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
On Mon, Oct 20, 2025 at 4:55 PM mc36 <csmate@nop.hu> wrote:
>
> hi,
>
> On 10/20/25 08:41, Jason Xing wrote:
> > Hi,
> >
> >> this happens 10/10 on host or in qemu-system-x86_64-kvm running 6.16.12 or 6.17.2...
> >
> > Thanks for the report.
> >
> > I'm wondering if you have time to bisect which recent commit has
> > brought this problem. It looks like it never happens before 6.16?
> >
>
> and now confirming that 6.16.7 survives the reproducer code and 6.16.8 crashes...
>
> below is the decoded and raw 6.17 trace... regarding the exact commit hash, i
>
> would leave the chance for someone with much more resources than i have at hand....
Thanks for working on this.
Strange thing is that I didn't manage to see the crash on 6.16.0-rc6,
6.17.0-rc3 or 6.18.0-rc1 that is the latest. I feel that your
environment is hugely different from mine.
I followed your steps you attached in your code:
////// gcc xskInt.c -lxdp
////// sudo ip link add veth1 type veth
////// sudo ip link set veth0 up
////// sudo ip link set veth1 up
////// sudo ./a.out
The version of libxdp that I use is 1.4.2, BTW.
Could you share me with your .config? I'm not sure if I missed something.
Thanks,
Jason
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-20 9:04 ` Jason Xing
@ 2025-10-20 9:18 ` mc36
2025-10-20 9:48 ` mc36
2025-10-20 21:31 ` mc36
1 sibling, 1 reply; 19+ messages in thread
From: mc36 @ 2025-10-20 9:18 UTC (permalink / raw)
To: Jason Xing
Cc: Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]
hi,
On 10/20/25 11:04, Jason Xing wrote:
>
> Thanks for working on this.
>
i also appreciate that you also working on this! :)
> Strange thing is that I didn't manage to see the crash on 6.16.0-rc6,
> 6.17.0-rc3 or 6.18.0-rc1 that is the latest. I feel that your
> environment is hugely different from mine.
>
so i managed to have the crash on 6.16.8, 6.16.9 and 6.17.2....
but 6.17.7 and below seems to be working just fine here....
> I followed your steps you attached in your code:
> ////// gcc xskInt.c -lxdp
> ////// sudo ip link add veth1 type veth
> ////// sudo ip link set veth0 up
> ////// sudo ip link set veth1 up
> ////// sudo ./a.out
exactly, thats how to trigger the crash...
>
> The version of libxdp that I use is 1.4.2, BTW.
>
c36@p4emu:~$ dpkg -l | grep xdp
ii librte-net-af-xdp25:amd64 24.11.3-2 amd64 Data Plane Development Kit (librte-net-af-xdp runtime library)
ii libxdp-dev:amd64 1.5.7-3 amd64 library and utilities for use with XDP - development files
ii libxdp1:amd64 1.5.7-3 amd64 library and utilities for use with XDP - shared library
is what i use from the debian-sid repo....
> Could you share me with your .config? I'm not sure if I missed something.
>
so i'm playing with debian sid kernels and libxdp, whereas the
first report came from fedora rawhide land to freertr....
btw i'm attaching the configs i had and hadn't success with....
have a nice day,
csaba
[-- Attachment #2: zzz.tar.gz --]
[-- Type: application/gzip, Size: 318734 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-20 9:18 ` mc36
@ 2025-10-20 9:48 ` mc36
0 siblings, 0 replies; 19+ messages in thread
From: mc36 @ 2025-10-20 9:48 UTC (permalink / raw)
To: Jason Xing
Cc: Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
hi,
On 10/20/25 11:18, mc36 wrote:
> so i managed to have the crash on 6.16.8, 6.16.9 and 6.17.2....
>
> but 6.17.7 and below seems to be working just fine here....
>
my fat fingers... 6.16.7 and below... :)
an other attachment with the versions that work and ones that crash....
br,
cs
[-- Attachment #2: zzz2.tar.gz --]
[-- Type: application/gzip, Size: 6685 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-20 9:04 ` Jason Xing
2025-10-20 9:18 ` mc36
@ 2025-10-20 21:31 ` mc36
2025-10-21 10:51 ` Fernando Fernandez Mancera
2025-10-21 11:02 ` Jason Xing
1 sibling, 2 replies; 19+ messages in thread
From: mc36 @ 2025-10-20 21:31 UTC (permalink / raw)
To: Jason Xing, alekcejk
Cc: Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
hi,
On 10/20/25 11:04, Jason Xing wrote:
>
> I followed your steps you attached in your code:
> ////// gcc xskInt.c -lxdp
> ////// sudo ip link add veth1 type veth
> ////// sudo ip link set veth0 up
> ////// sudo ip link set veth1 up
ip link set dev veth1 address 3a:10:5c:53:b3:5c
> ////// sudo ./a.out
>
that will do the trick on a recent kerlek....
its the destination mac in the c code....
ps: chaining in the original reporter from the fedora land.....
have a nice day,
cs
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-20 21:31 ` mc36
@ 2025-10-21 10:51 ` Fernando Fernandez Mancera
2025-10-21 12:25 ` Jason Xing
2025-11-08 14:49 ` Salvatore Bonaccorso
2025-10-21 11:02 ` Jason Xing
1 sibling, 2 replies; 19+ messages in thread
From: Fernando Fernandez Mancera @ 2025-10-21 10:51 UTC (permalink / raw)
To: mc36, Jason Xing, alekcejk
Cc: Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
On 10/20/25 11:31 PM, mc36 wrote:
> hi,
>
> On 10/20/25 11:04, Jason Xing wrote:
>>
>> I followed your steps you attached in your code:
>> ////// gcc xskInt.c -lxdp
>> ////// sudo ip link add veth1 type veth
>> ////// sudo ip link set veth0 up
>> ////// sudo ip link set veth1 up
>
> ip link set dev veth1 address 3a:10:5c:53:b3:5c
>
>> ////// sudo ./a.out
>>
> that will do the trick on a recent kerlek....
>
> its the destination mac in the c code....
>
> ps: chaining in the original reporter from the fedora land.....
>
>
> have a nice day,
>
> cs
>
>
hi, FWIW I have reproduced this and I bisected it, issue was introduced
at 30f241fcf52aaaef7ac16e66530faa11be78a865 - working on a patch.
Thanks,
Fernando.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-20 21:31 ` mc36
2025-10-21 10:51 ` Fernando Fernandez Mancera
@ 2025-10-21 11:02 ` Jason Xing
2025-10-21 14:47 ` Maciej Fijalkowski
1 sibling, 1 reply; 19+ messages in thread
From: Jason Xing @ 2025-10-21 11:02 UTC (permalink / raw)
To: mc36
Cc: alekcejk, Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
On Tue, Oct 21, 2025 at 5:31 AM mc36 <csmate@nop.hu> wrote:
>
> hi,
>
> On 10/20/25 11:04, Jason Xing wrote:
> >
> > I followed your steps you attached in your code:
> > ////// gcc xskInt.c -lxdp
> > ////// sudo ip link add veth1 type veth
> > ////// sudo ip link set veth0 up
> > ////// sudo ip link set veth1 up
>
> ip link set dev veth1 address 3a:10:5c:53:b3:5c
Great, it indeed helps me reproduce the issue, so I managed to see the
exact same stack. Let me dig into it more deeply.
Thanks,
Jason
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-21 10:51 ` Fernando Fernandez Mancera
@ 2025-10-21 12:25 ` Jason Xing
2025-10-21 12:59 ` mc36
2025-11-08 14:49 ` Salvatore Bonaccorso
1 sibling, 1 reply; 19+ messages in thread
From: Jason Xing @ 2025-10-21 12:25 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: mc36, alekcejk, Jonathan Lemon, Stanislav Fomichev,
Maciej Fijalkowski, Magnus Karlsson, Björn Töpel,
1118437, netdev, bpf
On Tue, Oct 21, 2025 at 6:52 PM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
>
>
> On 10/20/25 11:31 PM, mc36 wrote:
> > hi,
> >
> > On 10/20/25 11:04, Jason Xing wrote:
> >>
> >> I followed your steps you attached in your code:
> >> ////// gcc xskInt.c -lxdp
> >> ////// sudo ip link add veth1 type veth
> >> ////// sudo ip link set veth0 up
> >> ////// sudo ip link set veth1 up
> >
> > ip link set dev veth1 address 3a:10:5c:53:b3:5c
> >
> >> ////// sudo ./a.out
> >>
> > that will do the trick on a recent kerlek....
> >
> > its the destination mac in the c code....
> >
> > ps: chaining in the original reporter from the fedora land.....
> >
> >
> > have a nice day,
> >
> > cs
> >
> >
>
> hi, FWIW I have reproduced this and I bisected it, issue was introduced
> at 30f241fcf52aaaef7ac16e66530faa11be78a865 - working on a patch.
Exactly. I simply reverted it and its dependencies and didn't see any
crash then. It was newly introduced, hopefully it will not bring much
trouble. As I replied before, I will take a look tomorrow morning.
Thanks,
Jason
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-21 12:25 ` Jason Xing
@ 2025-10-21 12:59 ` mc36
2025-10-21 13:02 ` Jason Xing
0 siblings, 1 reply; 19+ messages in thread
From: mc36 @ 2025-10-21 12:59 UTC (permalink / raw)
To: Jason Xing, Fernando Fernandez Mancera
Cc: alekcejk, Jonathan Lemon, Stanislav Fomichev, Maciej Fijalkowski,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
hi,
you both are crazy good, thank you so much for both of your effort! :)
if you're in a need for some more complicated xsk tests, just let me know, freertr
have a dataplane and a socat-alike tool with an xsk based packetio for a while....
br,
cs
On 10/21/25 14:25, Jason Xing wrote:
> On Tue, Oct 21, 2025 at 6:52 PM Fernando Fernandez Mancera
> <fmancera@suse.de> wrote:
>>
>>
>>
>> On 10/20/25 11:31 PM, mc36 wrote:
>>> hi,
>>>
>>> On 10/20/25 11:04, Jason Xing wrote:
>>>>
>>>> I followed your steps you attached in your code:
>>>> ////// gcc xskInt.c -lxdp
>>>> ////// sudo ip link add veth1 type veth
>>>> ////// sudo ip link set veth0 up
>>>> ////// sudo ip link set veth1 up
>>>
>>> ip link set dev veth1 address 3a:10:5c:53:b3:5c
>>>
>>>> ////// sudo ./a.out
>>>>
>>> that will do the trick on a recent kerlek....
>>>
>>> its the destination mac in the c code....
>>>
>>> ps: chaining in the original reporter from the fedora land.....
>>>
>>>
>>> have a nice day,
>>>
>>> cs
>>>
>>>
>>
>> hi, FWIW I have reproduced this and I bisected it, issue was introduced
>> at 30f241fcf52aaaef7ac16e66530faa11be78a865 - working on a patch.
>
> Exactly. I simply reverted it and its dependencies and didn't see any
> crash then. It was newly introduced, hopefully it will not bring much
> trouble. As I replied before, I will take a look tomorrow morning.
>
> Thanks,
> Jason
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-21 12:59 ` mc36
@ 2025-10-21 13:02 ` Jason Xing
2025-10-21 13:43 ` mc36
0 siblings, 1 reply; 19+ messages in thread
From: Jason Xing @ 2025-10-21 13:02 UTC (permalink / raw)
To: mc36
Cc: Fernando Fernandez Mancera, alekcejk, Jonathan Lemon,
Stanislav Fomichev, Maciej Fijalkowski, Magnus Karlsson,
Björn Töpel, 1118437, netdev, bpf
On Tue, Oct 21, 2025 at 8:59 PM mc36 <csmate@nop.hu> wrote:
>
> hi,
>
> you both are crazy good, thank you so much for both of your effort! :)
>
>
> if you're in a need for some more complicated xsk tests, just let me know, freertr
>
> have a dataplane and a socat-alike tool with an xsk based packetio for a while....
Could you provide a link that points to what you just mentioned? I
believe more tests on veth are necessary.
Thanks,
Jason
>
> br,
>
> cs
>
> On 10/21/25 14:25, Jason Xing wrote:
> > On Tue, Oct 21, 2025 at 6:52 PM Fernando Fernandez Mancera
> > <fmancera@suse.de> wrote:
> >>
> >>
> >>
> >> On 10/20/25 11:31 PM, mc36 wrote:
> >>> hi,
> >>>
> >>> On 10/20/25 11:04, Jason Xing wrote:
> >>>>
> >>>> I followed your steps you attached in your code:
> >>>> ////// gcc xskInt.c -lxdp
> >>>> ////// sudo ip link add veth1 type veth
> >>>> ////// sudo ip link set veth0 up
> >>>> ////// sudo ip link set veth1 up
> >>>
> >>> ip link set dev veth1 address 3a:10:5c:53:b3:5c
> >>>
> >>>> ////// sudo ./a.out
> >>>>
> >>> that will do the trick on a recent kerlek....
> >>>
> >>> its the destination mac in the c code....
> >>>
> >>> ps: chaining in the original reporter from the fedora land.....
> >>>
> >>>
> >>> have a nice day,
> >>>
> >>> cs
> >>>
> >>>
> >>
> >> hi, FWIW I have reproduced this and I bisected it, issue was introduced
> >> at 30f241fcf52aaaef7ac16e66530faa11be78a865 - working on a patch.
> >
> > Exactly. I simply reverted it and its dependencies and didn't see any
> > crash then. It was newly introduced, hopefully it will not bring much
> > trouble. As I replied before, I will take a look tomorrow morning.
> >
> > Thanks,
> > Jason
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-21 13:02 ` Jason Xing
@ 2025-10-21 13:43 ` mc36
0 siblings, 0 replies; 19+ messages in thread
From: mc36 @ 2025-10-21 13:43 UTC (permalink / raw)
To: Jason Xing
Cc: Fernando Fernandez Mancera, alekcejk, Jonathan Lemon,
Stanislav Fomichev, Maciej Fijalkowski, Magnus Karlsson,
Björn Töpel, 1118437, netdev, bpf
hi,
On 10/21/25 15:02, Jason Xing wrote:
>> if you're in a need for some more complicated xsk tests, just let me know, freertr
>>
>> have a dataplane and a socat-alike tool with an xsk based packetio for a while....
>
> Could you provide a link that points to what you just mentioned? I
> believe more tests on veth are necessary.
>
sure, but be warned, it's a huge rabbit-hole that you're jumping into.... :)
so the homepage is freertr.org, it provides a daily vm builds...
if you grab the qcow2, convert to raw and mount -o offset=1048576
you can update the kernel and initrd, and you need to put the xdp
bpf and elf libs as they're not part of that image... then umount it,
and after the first boot (look at the serial console!), do the following:
conf t
int eth1
vrf forwarding host
ipv4 addr 10.0.2.222 255.255.255.0
exit
ipv4 route host 0.0.0.0 0.0.0.0 10.0.2.2
end
write
test hwext path /rtr/rtr- dataplane p4xsk
reload cold
y
your xdp dataplath is activated, the vm kernel itself will be behind
a veth pair, the dataplane will play with the qemu virtio-pci and the veth,
and there will be an other veth for the dataplane-controlplane communication
full of random non-ip frames, then
ping 10.255.255.1 vrf host
ping 10.0.2.2 vrf host
will test for the fresh kernel and the outside word...
you can exercise the above with a raw socket on the original image if you do "p4raw"
instead of "p4xsk", and as we're on the bpf, it have an in-kernel forwarder called "p4xdp"....:)
the source is at https://github.com/mc36/freeRtr , the misc/native folder
contains the dataplane, and the socat-alike tools.... just ./c.sh to build them...
afterwards you can create topologies with then like
(1.1.1.1/30)ns1-----<veth1>------host-----<veth2>------ns2(1.1.1.2/30)
to cross connect 2 interfaces on the host, just run 2 processes like
xskInt.bin veth1 skb 1234 127.0.0.1 4321 127.0.0.1
pcapInt.bin veth2 4321 127.0.0.1 1234 127.0.0.1
there are other tools with uring, raw socket, mmaped raw socket
and some others that are uninterested in the current topic imho....
have a nice day,
csaba
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-21 11:02 ` Jason Xing
@ 2025-10-21 14:47 ` Maciej Fijalkowski
2025-10-21 15:09 ` Fernando Fernandez Mancera
2025-10-21 15:28 ` mc36
0 siblings, 2 replies; 19+ messages in thread
From: Maciej Fijalkowski @ 2025-10-21 14:47 UTC (permalink / raw)
To: Jason Xing
Cc: mc36, alekcejk, Jonathan Lemon, Stanislav Fomichev,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
On Tue, Oct 21, 2025 at 07:02:06PM +0800, Jason Xing wrote:
> On Tue, Oct 21, 2025 at 5:31 AM mc36 <csmate@nop.hu> wrote:
> >
> > hi,
> >
> > On 10/20/25 11:04, Jason Xing wrote:
> > >
> > > I followed your steps you attached in your code:
> > > ////// gcc xskInt.c -lxdp
> > > ////// sudo ip link add veth1 type veth
> > > ////// sudo ip link set veth0 up
> > > ////// sudo ip link set veth1 up
> >
> > ip link set dev veth1 address 3a:10:5c:53:b3:5c
>
> Great, it indeed helps me reproduce the issue, so I managed to see the
> exact same stack. Let me dig into it more deeply.
splat comes from skb_orphan() calling skb->destructor() with ::cb field
being already taken by IP layer. A hotfix would simply be moving this call
before we memset cb in ip_rcv_core():
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 273578579a6b..db30645f8c35 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -535,14 +535,14 @@ static struct sk_buff *ip_rcv_core(struct sk_buff *skb, struct net *net)
iph = ip_hdr(skb);
skb->transport_header = skb->network_header + iph->ihl*4;
- /* Remove any debris in the socket control block */
- memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
- IPCB(skb)->iif = skb->skb_iif;
-
/* Must drop socket now because of tproxy. */
if (!skb_sk_is_prefetched(skb))
skb_orphan(skb);
+ /* Remove any debris in the socket control block */
+ memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ IPCB(skb)->iif = skb->skb_iif;
+
return skb;
csum_error:
However, I do not understand why setting mac addr on one veth interface
triggers this path.
>
> Thanks,
> Jason
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-21 14:47 ` Maciej Fijalkowski
@ 2025-10-21 15:09 ` Fernando Fernandez Mancera
2025-10-21 15:28 ` mc36
1 sibling, 0 replies; 19+ messages in thread
From: Fernando Fernandez Mancera @ 2025-10-21 15:09 UTC (permalink / raw)
To: Maciej Fijalkowski, Jason Xing
Cc: mc36, alekcejk, Jonathan Lemon, Stanislav Fomichev,
Magnus Karlsson, Björn Töpel, 1118437, netdev, bpf
On 10/21/25 4:47 PM, Maciej Fijalkowski wrote:
> On Tue, Oct 21, 2025 at 07:02:06PM +0800, Jason Xing wrote:
>> On Tue, Oct 21, 2025 at 5:31 AM mc36 <csmate@nop.hu> wrote:
>>>
>>> hi,
>>>
>>> On 10/20/25 11:04, Jason Xing wrote:
>>>>
>>>> I followed your steps you attached in your code:
>>>> ////// gcc xskInt.c -lxdp
>>>> ////// sudo ip link add veth1 type veth
>>>> ////// sudo ip link set veth0 up
>>>> ////// sudo ip link set veth1 up
>>>
>>> ip link set dev veth1 address 3a:10:5c:53:b3:5c
>>
>> Great, it indeed helps me reproduce the issue, so I managed to see the
>> exact same stack. Let me dig into it more deeply.
>
> splat comes from skb_orphan() calling skb->destructor() with ::cb field
> being already taken by IP layer. A hotfix would simply be moving this call
> before we memset cb in ip_rcv_core():
>
> diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
> index 273578579a6b..db30645f8c35 100644
> --- a/net/ipv4/ip_input.c
> +++ b/net/ipv4/ip_input.c
> @@ -535,14 +535,14 @@ static struct sk_buff *ip_rcv_core(struct sk_buff *skb, struct net *net)
> iph = ip_hdr(skb);
> skb->transport_header = skb->network_header + iph->ihl*4;
>
> - /* Remove any debris in the socket control block */
> - memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
> - IPCB(skb)->iif = skb->skb_iif;
> -
> /* Must drop socket now because of tproxy. */
> if (!skb_sk_is_prefetched(skb))
> skb_orphan(skb);
>
> + /* Remove any debris in the socket control block */
> + memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
> + IPCB(skb)->iif = skb->skb_iif;
> +
> return skb;
>
> csum_error:
>
> However, I do not understand why setting mac addr on one veth interface
> triggers this path.
>
Ugh, sorry then. I just sent a patch to the list and didn't see your
email. Anyway, I believe it is safer to avoid using skb control block if
other subsystems might take control over it.
Feel free to discard my patch at:
https://lore.kernel.org/netdev/20251021150656.6704-1-fmancera@suse.de/
Thanks,
Fernando.
>>
>> Thanks,
>> Jason
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-21 14:47 ` Maciej Fijalkowski
2025-10-21 15:09 ` Fernando Fernandez Mancera
@ 2025-10-21 15:28 ` mc36
1 sibling, 0 replies; 19+ messages in thread
From: mc36 @ 2025-10-21 15:28 UTC (permalink / raw)
To: Maciej Fijalkowski, Jason Xing
Cc: alekcejk, Jonathan Lemon, Stanislav Fomichev, Magnus Karlsson,
Björn Töpel, 1118437, netdev, bpf
hi,
On 10/21/25 16:47, Maciej Fijalkowski wrote:
> However, I do not understand why setting mac addr on one veth interface
> triggers this path.
>
just my 10 cents but imho i saw a check for promisc while walking through the call
stack's small epsilon surroundings, maybe there is a for-us check somewhere earlier?
recall that we're setting the interface hw-address to the packet's destination mac...
br,
cs
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-10-21 10:51 ` Fernando Fernandez Mancera
2025-10-21 12:25 ` Jason Xing
@ 2025-11-08 14:49 ` Salvatore Bonaccorso
2025-11-09 0:10 ` Jason Xing
1 sibling, 1 reply; 19+ messages in thread
From: Salvatore Bonaccorso @ 2025-11-08 14:49 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: mc36, Jason Xing, alekcejk, Jonathan Lemon, Stanislav Fomichev,
Maciej Fijalkowski, Magnus Karlsson, Björn Töpel,
1118437, netdev, bpf
Hi,
On Tue, Oct 21, 2025 at 12:51:32PM +0200, Fernando Fernandez Mancera wrote:
>
>
> On 10/20/25 11:31 PM, mc36 wrote:
> > hi,
> >
> > On 10/20/25 11:04, Jason Xing wrote:
> > >
> > > I followed your steps you attached in your code:
> > > ////// gcc xskInt.c -lxdp
> > > ////// sudo ip link add veth1 type veth
> > > ////// sudo ip link set veth0 up
> > > ////// sudo ip link set veth1 up
> >
> > ip link set dev veth1 address 3a:10:5c:53:b3:5c
> >
> > > ////// sudo ./a.out
> > >
> > that will do the trick on a recent kerlek....
> >
> > its the destination mac in the c code....
> >
> > ps: chaining in the original reporter from the fedora land.....
> >
> >
> > have a nice day,
> >
> > cs
> >
> >
>
> hi, FWIW I have reproduced this and I bisected it, issue was introduced at
> 30f241fcf52aaaef7ac16e66530faa11be78a865 - working on a patch.
Just a qustion in particular for the stable series shipping the commit
(now only 6.17.y relevant at this point since 6.16.y is EOL): Give the
proper fix will take a bit more time to develop, would it make sense
to at least revert the offending commit in the stable series as the
issue is, unless I missunderstood the report, remotely(?) triggerable
denial of service?
Or do I miss something here?
Regards,
Salvatore
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space
2025-11-08 14:49 ` Salvatore Bonaccorso
@ 2025-11-09 0:10 ` Jason Xing
0 siblings, 0 replies; 19+ messages in thread
From: Jason Xing @ 2025-11-09 0:10 UTC (permalink / raw)
To: Salvatore Bonaccorso
Cc: Fernando Fernandez Mancera, mc36, alekcejk, Jonathan Lemon,
Stanislav Fomichev, Maciej Fijalkowski, Magnus Karlsson,
Björn Töpel, 1118437, netdev, bpf
On Sat, Nov 8, 2025 at 10:49 PM Salvatore Bonaccorso <carnil@debian.org> wrote:
>
> Hi,
>
> On Tue, Oct 21, 2025 at 12:51:32PM +0200, Fernando Fernandez Mancera wrote:
> >
> >
> > On 10/20/25 11:31 PM, mc36 wrote:
> > > hi,
> > >
> > > On 10/20/25 11:04, Jason Xing wrote:
> > > >
> > > > I followed your steps you attached in your code:
> > > > ////// gcc xskInt.c -lxdp
> > > > ////// sudo ip link add veth1 type veth
> > > > ////// sudo ip link set veth0 up
> > > > ////// sudo ip link set veth1 up
> > >
> > > ip link set dev veth1 address 3a:10:5c:53:b3:5c
> > >
> > > > ////// sudo ./a.out
> > > >
> > > that will do the trick on a recent kerlek....
> > >
> > > its the destination mac in the c code....
> > >
> > > ps: chaining in the original reporter from the fedora land.....
> > >
> > >
> > > have a nice day,
> > >
> > > cs
> > >
> > >
> >
> > hi, FWIW I have reproduced this and I bisected it, issue was introduced at
> > 30f241fcf52aaaef7ac16e66530faa11be78a865 - working on a patch.
>
> Just a qustion in particular for the stable series shipping the commit
> (now only 6.17.y relevant at this point since 6.16.y is EOL): Give the
> proper fix will take a bit more time to develop, would it make sense
> to at least revert the offending commit in the stable series as the
> issue is, unless I missunderstood the report, remotely(?) triggerable
> denial of service?
>
> Or do I miss something here?
We've been working on this already. Please find the patches at
https://lore.kernel.org/all/20251031093230.82386-1-kerneljasonxing@gmail.com/
Yes, my solution is to revert first and apply a pre-allocate array to
temporarily store the descriptors that will be published at the tx
completion phase.
If you also care about this, please feel free to review the whole
idea. As long as everyone is on board, I will send an official version
with more detailed updates. I'm still waiting for more suggestions :)
Thanks,
Jason
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2025-11-09 0:11 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-20 4:45 null pointer dereference in interrupt after receiving an ip packet on veth from xsk from user space mc36
2025-10-20 6:41 ` Jason Xing
2025-10-20 7:15 ` mc36
2025-10-20 8:55 ` mc36
2025-10-20 9:04 ` Jason Xing
2025-10-20 9:18 ` mc36
2025-10-20 9:48 ` mc36
2025-10-20 21:31 ` mc36
2025-10-21 10:51 ` Fernando Fernandez Mancera
2025-10-21 12:25 ` Jason Xing
2025-10-21 12:59 ` mc36
2025-10-21 13:02 ` Jason Xing
2025-10-21 13:43 ` mc36
2025-11-08 14:49 ` Salvatore Bonaccorso
2025-11-09 0:10 ` Jason Xing
2025-10-21 11:02 ` Jason Xing
2025-10-21 14:47 ` Maciej Fijalkowski
2025-10-21 15:09 ` Fernando Fernandez Mancera
2025-10-21 15:28 ` mc36
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).