* [BUG] Kernel Panic in iptfs_reassem_cont when handling large packets
@ 2026-03-01 9:49 Hao Long
2026-03-02 8:12 ` Steffen Klassert
2026-03-03 12:05 ` Fernando Fernandez Mancera
0 siblings, 2 replies; 4+ messages in thread
From: Hao Long @ 2026-03-01 9:49 UTC (permalink / raw)
To: netdev; +Cc: Steffen Klassert, Herbert Xu, David S. Miller
[-- Attachment #1.1: Type: text/plain, Size: 925 bytes --]
Hello,
Recently I set up a strongSwan tunnel in AGGFRAG mode[1] in order to see
how it fragments large packets.
Later I found out the receiver node will kernel panic when handling
large packets, I tested in different distro and both panic.
Tested environment:
- Arch Linux 6.18.13-arch1-1 strongswan-6.0.4-2
- Arch Linux 7.0.0-rc1-1-mainline strongswan-6.0.4-2
- NixOS 6.18.13 strongswan-6.0.4
Step to reproduce:
1. install strongSwan and create tunnel interface in vm1, see the
attachment init_env.sh
2. do step1 in vm2, but remember to switch local_addrs and remote_addrs,
also the ip assignment
3. run `ping -s 3333 10.0.1.2` in vm1, 10.0.1.2 is the ip from vm2
4. kernel panic in vm2
I'm not familiar in C programming and kernel developing, so sorry I can't
provide a useful root case analyze and a fix.
Regards,
Hao Long
[1] https://docs.strongswan.org/docs/latest/features/iptfs.html
[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 5841 bytes --]
[ 412.126912] ------------[ cut here ]------------
[ 412.126945] kernel BUG at net/core/skbuff.c:2651!
[ 412.126974] Oops: invalid opcode: 0000 [#1] SMP PTI
[ 412.127009] CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 7.0.0-rc1-1-mainline #1 PREEMPT(full) b84afef9bed61122840347d0d1295877239d5881
[ 412.127061] Hardware name: Vultr VC2, BIOS
[ 412.127076] RIP: 0010:skb_put+0x3c/0x40
[ 412.127122] Code: bc 00 00 00 01 77 70 48 89 c2 48 03 87 c8 00 00 00 01 f2 89 97 bc 00 00 00 39 97 c0 00 00 00 0f 82 c0 c2 14 ff e9 c4 a0 2f 00 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f
[ 412.127154] RSP: 0018:ffffcdee80120788 EFLAGS: 00010202
[ 412.127167] RAX: 000000000000056e RBX: ffff8ac7cef2c400 RCX: 0000000000000030
[ 412.127184] RDX: ffff8ac7cef94000 RSI: 0000000000000030 RDI: ffff8ac7c266a700
[ 412.127197] RBP: ffffcdee801207b0 R08: 0000000000000004 R09: 0000000000000030
[ 412.127210] R10: 0000000000000030 R11: 0000000000000030 R12: ffff8ac7c7160a00
[ 412.127222] R13: ffff8ac7c266a700 R14: ffffcdee80120978 R15: ffffcdee80120950
[ 412.127241] FS: 0000000000000000(0000) GS:ffff8ac995998000(0000) knlGS:0000000000000000
[ 412.127256] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 412.127271] CR2: 000055b8aa3f3b80 CR3: 0000000104500001 CR4: 00000000001706f0
[ 412.127288] Call Trace:
[ 412.127298] <IRQ>
[ 412.127308] iptfs_reassem_cont+0x12d/0x5f0 [xfrm_iptfs 7ea53a8d87342a9b7c66159e6b7baa8136dff23a]
[ 412.127335] iptfs_input_ordered+0x260/0x310 [xfrm_iptfs 7ea53a8d87342a9b7c66159e6b7baa8136dff23a]
[ 412.127356] iptfs_input+0x128/0x3d0 [xfrm_iptfs 7ea53a8d87342a9b7c66159e6b7baa8136dff23a]
[ 412.127373] ? esp_input+0x1f7/0x330 [esp4 f354ef309189db0d9825bb990cd4d8b0a86a0bf3]
[ 412.127399] xfrm_input+0x8d3/0x16a0
[ 412.127449] xfrm4_esp_rcv+0x38/0x80
[ 412.127473] ip_protocol_deliver_rcu+0x169/0x170
[ 412.127497] ip_local_deliver_finish+0x85/0x100
[ 412.127509] __netif_receive_skb_core.constprop.0+0xa14/0xe30
[ 412.127529] ? kmalloc_reserve+0x86/0x100
[ 412.127540] ? __alloc_skb+0xf4/0x2e0
[ 412.127551] ? napi_alloc_skb+0x35/0x270
[ 412.127568] ? page_to_skb+0x2a9/0x400 [virtio_net 07b3b182c5b7f88384b07163f6c3d83152f6c13c]
[ 412.127610] __netif_receive_skb_list_core+0x13d/0x2d0
[ 412.127628] netif_receive_skb_list_internal+0x1d5/0x310
[ 412.127645] napi_complete_done+0x7f/0x1b0
[ 412.127660] ? virtnet_rq_get_buf+0x2d/0x60 [virtio_net 07b3b182c5b7f88384b07163f6c3d83152f6c13c]
[ 412.127684] virtnet_poll+0x6de/0xdbd [virtio_net 07b3b182c5b7f88384b07163f6c3d83152f6c13c]
[ 412.127710] __napi_poll+0x30/0x200
[ 412.127723] ? skb_defer_free_flush+0x9c/0xc0
[ 412.127745] net_rx_action+0x2fd/0x390
[ 412.127761] handle_softirqs+0xe4/0x2c0
[ 412.127802] __irq_exit_rcu+0xcb/0xf0
[ 412.127817] common_interrupt+0x85/0xa0
[ 412.127848] </IRQ>
[ 412.127858] <TASK>
[ 412.127867] asm_common_interrupt+0x26/0x40
[ 412.127904] RIP: 0010:pv_native_safe_halt+0xf/0x20
[ 412.127926] Code: 20 d0 e9 c4 3c 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d c3 e9 1f 00 fb f4 <c3> cc cc cc cc 90 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90
[ 412.128324] RSP: 0018:ffffcdee800dbeb8 EFLAGS: 00000286
[ 412.128644] RAX: 0000000000000002 RBX: ffff8ac7c085b600 RCX: 4000000000000000
[ 412.128930] RDX: 00000000000b70bc RSI: ffff8ac7c085b600 RDI: 00000000000b70bc
[ 412.129210] RBP: 0000000000000002 R08: ffffcdee800dbe30 R09: ffff8ac937d21820
[ 412.129486] R10: 0000005ff80573c0 R11: 0000000000000002 R12: 0000000000000000
[ 412.129743] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 412.130001] default_idle+0x9/0x20
[ 412.130263] default_idle_call+0x2f/0x130
[ 412.130546] do_idle+0x1c7/0x210
[ 412.130891] cpu_startup_entry+0x29/0x30
[ 412.131263] start_secondary+0x119/0x150
[ 412.131600] common_startup_64+0x13e/0x141
[ 412.131859] </TASK>
[ 412.132137] Modules linked in: xfrm_iptfs seqiv geniv esp4 xfrm_interface xfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo snd_hda_codec_generic snd_hda_intel snd_hda_codec intel_rapl_msr intel_rapl_common snd_hda_core ghash_clmulni_intel snd_intel_dspcfg aesni_intel snd_intel_sdw_acpi rapl snd_hwdep i2c_i801 snd_pcm psmouse i2c_smbus i2c_mux pcspkr iTCO_wdt snd_timer intel_pmc_bxt snd soundcore vfat fat qemu_fw_cfg i6300esb joydev mousedev mac_hid cfg80211 rfkill dm_mod nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci sr_mod cdrom lpc_ich virtio_balloon virtio_net net_failover failover bochs intel_agp intel_gtt serio_raw virtio_rng
[ 412.133499] ---[ end trace 0000000000000000 ]---
[ 412.133807] RIP: 0010:skb_put+0x3c/0x40
[ 412.134092] Code: bc 00 00 00 01 77 70 48 89 c2 48 03 87 c8 00 00 00 01 f2 89 97 bc 00 00 00 39 97 c0 00 00 00 0f 82 c0 c2 14 ff e9 c4 a0 2f 00 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f
[ 412.134654] RSP: 0018:ffffcdee80120788 EFLAGS: 00010202
[ 412.134935] RAX: 000000000000056e RBX: ffff8ac7cef2c400 RCX: 0000000000000030
[ 412.135282] RDX: ffff8ac7cef94000 RSI: 0000000000000030 RDI: ffff8ac7c266a700
[ 412.135583] RBP: ffffcdee801207b0 R08: 0000000000000004 R09: 0000000000000030
[ 412.135951] R10: 0000000000000030 R11: 0000000000000030 R12: ffff8ac7c7160a00
[ 412.136389] R13: ffff8ac7c266a700 R14: ffffcdee80120978 R15: ffffcdee80120950
[ 412.136721] FS: 0000000000000000(0000) GS:ffff8ac995998000(0000) knlGS:0000000000000000
[ 412.137015] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 412.137480] CR2: 000055b8aa3f3b80 CR3: 0000000104500001 CR4: 00000000001706f0
[ 412.137825] Kernel panic - not syncing: Fatal exception in interrupt
[ 412.138095] Kernel Offset: 0x1de00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[-- Attachment #3: init_env.sh --]
[-- Type: application/x-sh, Size: 1019 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] Kernel Panic in iptfs_reassem_cont when handling large packets
2026-03-01 9:49 [BUG] Kernel Panic in iptfs_reassem_cont when handling large packets Hao Long
@ 2026-03-02 8:12 ` Steffen Klassert
2026-03-04 14:00 ` Christian Hopps
2026-03-03 12:05 ` Fernando Fernandez Mancera
1 sibling, 1 reply; 4+ messages in thread
From: Steffen Klassert @ 2026-03-02 8:12 UTC (permalink / raw)
To: Hao Long, Christian Hopps; +Cc: netdev, Herbert Xu, David S. Miller
Add Chris, the author of IPTFS, to the Cc.
On Sun, Mar 01, 2026 at 05:49:19PM +0800, Hao Long wrote:
> Hello,
>
> Recently I set up a strongSwan tunnel in AGGFRAG mode[1] in order to see
> how it fragments large packets.
>
> Later I found out the receiver node will kernel panic when handling
> large packets, I tested in different distro and both panic.
>
> Tested environment:
> - Arch Linux 6.18.13-arch1-1 strongswan-6.0.4-2
> - Arch Linux 7.0.0-rc1-1-mainline strongswan-6.0.4-2
> - NixOS 6.18.13 strongswan-6.0.4
>
> Step to reproduce:
> 1. install strongSwan and create tunnel interface in vm1, see the
> attachment init_env.sh
> 2. do step1 in vm2, but remember to switch local_addrs and remote_addrs,
> also the ip assignment
> 3. run `ping -s 3333 10.0.1.2` in vm1, 10.0.1.2 is the ip from vm2
> 4. kernel panic in vm2
>
> I'm not familiar in C programming and kernel developing, so sorry I can't
> provide a useful root case analyze and a fix.
>
> Regards,
> Hao Long
>
> [1] https://docs.strongswan.org/docs/latest/features/iptfs.html
> [ 412.126912] ------------[ cut here ]------------
> [ 412.126945] kernel BUG at net/core/skbuff.c:2651!
> [ 412.126974] Oops: invalid opcode: 0000 [#1] SMP PTI
> [ 412.127009] CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 7.0.0-rc1-1-mainline #1 PREEMPT(full) b84afef9bed61122840347d0d1295877239d5881
> [ 412.127061] Hardware name: Vultr VC2, BIOS
> [ 412.127076] RIP: 0010:skb_put+0x3c/0x40
> [ 412.127122] Code: bc 00 00 00 01 77 70 48 89 c2 48 03 87 c8 00 00 00 01 f2 89 97 bc 00 00 00 39 97 c0 00 00 00 0f 82 c0 c2 14 ff e9 c4 a0 2f 00 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f
> [ 412.127154] RSP: 0018:ffffcdee80120788 EFLAGS: 00010202
> [ 412.127167] RAX: 000000000000056e RBX: ffff8ac7cef2c400 RCX: 0000000000000030
> [ 412.127184] RDX: ffff8ac7cef94000 RSI: 0000000000000030 RDI: ffff8ac7c266a700
> [ 412.127197] RBP: ffffcdee801207b0 R08: 0000000000000004 R09: 0000000000000030
> [ 412.127210] R10: 0000000000000030 R11: 0000000000000030 R12: ffff8ac7c7160a00
> [ 412.127222] R13: ffff8ac7c266a700 R14: ffffcdee80120978 R15: ffffcdee80120950
> [ 412.127241] FS: 0000000000000000(0000) GS:ffff8ac995998000(0000) knlGS:0000000000000000
> [ 412.127256] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 412.127271] CR2: 000055b8aa3f3b80 CR3: 0000000104500001 CR4: 00000000001706f0
> [ 412.127288] Call Trace:
> [ 412.127298] <IRQ>
> [ 412.127308] iptfs_reassem_cont+0x12d/0x5f0 [xfrm_iptfs 7ea53a8d87342a9b7c66159e6b7baa8136dff23a]
> [ 412.127335] iptfs_input_ordered+0x260/0x310 [xfrm_iptfs 7ea53a8d87342a9b7c66159e6b7baa8136dff23a]
> [ 412.127356] iptfs_input+0x128/0x3d0 [xfrm_iptfs 7ea53a8d87342a9b7c66159e6b7baa8136dff23a]
> [ 412.127373] ? esp_input+0x1f7/0x330 [esp4 f354ef309189db0d9825bb990cd4d8b0a86a0bf3]
> [ 412.127399] xfrm_input+0x8d3/0x16a0
> [ 412.127449] xfrm4_esp_rcv+0x38/0x80
> [ 412.127473] ip_protocol_deliver_rcu+0x169/0x170
> [ 412.127497] ip_local_deliver_finish+0x85/0x100
> [ 412.127509] __netif_receive_skb_core.constprop.0+0xa14/0xe30
> [ 412.127529] ? kmalloc_reserve+0x86/0x100
> [ 412.127540] ? __alloc_skb+0xf4/0x2e0
> [ 412.127551] ? napi_alloc_skb+0x35/0x270
> [ 412.127568] ? page_to_skb+0x2a9/0x400 [virtio_net 07b3b182c5b7f88384b07163f6c3d83152f6c13c]
> [ 412.127610] __netif_receive_skb_list_core+0x13d/0x2d0
> [ 412.127628] netif_receive_skb_list_internal+0x1d5/0x310
> [ 412.127645] napi_complete_done+0x7f/0x1b0
> [ 412.127660] ? virtnet_rq_get_buf+0x2d/0x60 [virtio_net 07b3b182c5b7f88384b07163f6c3d83152f6c13c]
> [ 412.127684] virtnet_poll+0x6de/0xdbd [virtio_net 07b3b182c5b7f88384b07163f6c3d83152f6c13c]
> [ 412.127710] __napi_poll+0x30/0x200
> [ 412.127723] ? skb_defer_free_flush+0x9c/0xc0
> [ 412.127745] net_rx_action+0x2fd/0x390
> [ 412.127761] handle_softirqs+0xe4/0x2c0
> [ 412.127802] __irq_exit_rcu+0xcb/0xf0
> [ 412.127817] common_interrupt+0x85/0xa0
> [ 412.127848] </IRQ>
> [ 412.127858] <TASK>
> [ 412.127867] asm_common_interrupt+0x26/0x40
> [ 412.127904] RIP: 0010:pv_native_safe_halt+0xf/0x20
> [ 412.127926] Code: 20 d0 e9 c4 3c 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d c3 e9 1f 00 fb f4 <c3> cc cc cc cc 90 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90
> [ 412.128324] RSP: 0018:ffffcdee800dbeb8 EFLAGS: 00000286
> [ 412.128644] RAX: 0000000000000002 RBX: ffff8ac7c085b600 RCX: 4000000000000000
> [ 412.128930] RDX: 00000000000b70bc RSI: ffff8ac7c085b600 RDI: 00000000000b70bc
> [ 412.129210] RBP: 0000000000000002 R08: ffffcdee800dbe30 R09: ffff8ac937d21820
> [ 412.129486] R10: 0000005ff80573c0 R11: 0000000000000002 R12: 0000000000000000
> [ 412.129743] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> [ 412.130001] default_idle+0x9/0x20
> [ 412.130263] default_idle_call+0x2f/0x130
> [ 412.130546] do_idle+0x1c7/0x210
> [ 412.130891] cpu_startup_entry+0x29/0x30
> [ 412.131263] start_secondary+0x119/0x150
> [ 412.131600] common_startup_64+0x13e/0x141
> [ 412.131859] </TASK>
> [ 412.132137] Modules linked in: xfrm_iptfs seqiv geniv esp4 xfrm_interface xfrm6_tunnel tunnel4 tunnel6 xfrm_user xfrm_algo snd_hda_codec_generic snd_hda_intel snd_hda_codec intel_rapl_msr intel_rapl_common snd_hda_core ghash_clmulni_intel snd_intel_dspcfg aesni_intel snd_intel_sdw_acpi rapl snd_hwdep i2c_i801 snd_pcm psmouse i2c_smbus i2c_mux pcspkr iTCO_wdt snd_timer intel_pmc_bxt snd soundcore vfat fat qemu_fw_cfg i6300esb joydev mousedev mac_hid cfg80211 rfkill dm_mod nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci sr_mod cdrom lpc_ich virtio_balloon virtio_net net_failover failover bochs intel_agp intel_gtt serio_raw virtio_rng
> [ 412.133499] ---[ end trace 0000000000000000 ]---
> [ 412.133807] RIP: 0010:skb_put+0x3c/0x40
> [ 412.134092] Code: bc 00 00 00 01 77 70 48 89 c2 48 03 87 c8 00 00 00 01 f2 89 97 bc 00 00 00 39 97 c0 00 00 00 0f 82 c0 c2 14 ff e9 c4 a0 2f 00 <0f> 0b 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f
> [ 412.134654] RSP: 0018:ffffcdee80120788 EFLAGS: 00010202
> [ 412.134935] RAX: 000000000000056e RBX: ffff8ac7cef2c400 RCX: 0000000000000030
> [ 412.135282] RDX: ffff8ac7cef94000 RSI: 0000000000000030 RDI: ffff8ac7c266a700
> [ 412.135583] RBP: ffffcdee801207b0 R08: 0000000000000004 R09: 0000000000000030
> [ 412.135951] R10: 0000000000000030 R11: 0000000000000030 R12: ffff8ac7c7160a00
> [ 412.136389] R13: ffff8ac7c266a700 R14: ffffcdee80120978 R15: ffffcdee80120950
> [ 412.136721] FS: 0000000000000000(0000) GS:ffff8ac995998000(0000) knlGS:0000000000000000
> [ 412.137015] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 412.137480] CR2: 000055b8aa3f3b80 CR3: 0000000104500001 CR4: 00000000001706f0
> [ 412.137825] Kernel panic - not syncing: Fatal exception in interrupt
> [ 412.138095] Kernel Offset: 0x1de00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] Kernel Panic in iptfs_reassem_cont when handling large packets
2026-03-01 9:49 [BUG] Kernel Panic in iptfs_reassem_cont when handling large packets Hao Long
2026-03-02 8:12 ` Steffen Klassert
@ 2026-03-03 12:05 ` Fernando Fernandez Mancera
1 sibling, 0 replies; 4+ messages in thread
From: Fernando Fernandez Mancera @ 2026-03-03 12:05 UTC (permalink / raw)
To: Hao Long, netdev; +Cc: Steffen Klassert, Herbert Xu, David S. Miller
On 3/1/26 10:49 AM, Hao Long wrote:
> Hello,
>
> Recently I set up a strongSwan tunnel in AGGFRAG mode[1] in order to see
> how it fragments large packets.
>
> Later I found out the receiver node will kernel panic when handling
> large packets, I tested in different distro and both panic.
>
> Tested environment:
> - Arch Linux 6.18.13-arch1-1 strongswan-6.0.4-2
> - Arch Linux 7.0.0-rc1-1-mainline strongswan-6.0.4-2
> - NixOS 6.18.13 strongswan-6.0.4
>
> Step to reproduce:
> 1. install strongSwan and create tunnel interface in vm1, see the
> attachment init_env.sh
> 2. do step1 in vm2, but remember to switch local_addrs and remote_addrs,
> also the ip assignment
> 3. run `ping -s 3333 10.0.1.2` in vm1, 10.0.1.2 is the ip from vm2
> 4. kernel panic in vm2
>
I have reproduced this. I will send a patch a shortly so you can test it
in your environment too.
Thanks,
Fernando.
> I'm not familiar in C programming and kernel developing, so sorry I can't
> provide a useful root case analyze and a fix.
>
> Regards,
> Hao Long
>
> [1] https://docs.strongswan.org/docs/latest/features/iptfs.html
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] Kernel Panic in iptfs_reassem_cont when handling large packets
2026-03-02 8:12 ` Steffen Klassert
@ 2026-03-04 14:00 ` Christian Hopps
0 siblings, 0 replies; 4+ messages in thread
From: Christian Hopps @ 2026-03-04 14:00 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Hao Long, netdev, Herbert Xu, David S. Miller
Steffen Klassert <steffen.klassert@secunet.com> writes:
> Add Chris, the author of IPTFS, to the Cc.
Got it, will take a look soon.
Thanks,
Chris.
> On Sun, Mar 01, 2026 at 05:49:19PM +0800, Hao Long wrote:
>> Hello,
>>
>> Recently I set up a strongSwan tunnel in AGGFRAG mode[1] in order to see
>> how it fragments large packets.
>>
>> Later I found out the receiver node will kernel panic when handling
>> large packets, I tested in different distro and both panic.
>>
>> Tested environment:
>> - Arch Linux 6.18.13-arch1-1 strongswan-6.0.4-2
>> - Arch Linux 7.0.0-rc1-1-mainline strongswan-6.0.4-2
>> - NixOS 6.18.13 strongswan-6.0.4
>>
>> Step to reproduce:
>> 1. install strongSwan and create tunnel interface in vm1, see the
>> attachment init_env.sh
>> 2. do step1 in vm2, but remember to switch local_addrs and remote_addrs,
>> also the ip assignment
>> 3. run `ping -s 3333 10.0.1.2` in vm1, 10.0.1.2 is the ip from vm2
>> 4. kernel panic in vm2
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-03-04 14:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-01 9:49 [BUG] Kernel Panic in iptfs_reassem_cont when handling large packets Hao Long
2026-03-02 8:12 ` Steffen Klassert
2026-03-04 14:00 ` Christian Hopps
2026-03-03 12:05 ` Fernando Fernandez Mancera
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox