Re: [syzbot] [net?] memory leak in build_skb

[Eric Dumazet]

Le ven. 30 oct. 2026 à 04:34, syzbot
<syzbot+a3f21220cbbb6e14ee2e@xxxxxxxxxxxxxxxxxxxxxxxxx> a écrit :
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:    65ba8f34ec88 Merge tag 'xtensa-20261027' of https://github..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1592353e580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=fbf447a1375a1948
> dashboard link: https://syzkaller.appspot.com/bug?extid=a3f21220cbbb6e14ee2e
> compiler:       gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=142ee469580000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/b4e738ce5f2b/disk-65ba8f34.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/1de9d1ecbbb6/vmlinux-65ba8f34.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/8a3d79b65181/bzImage-65ba8f34.xz
>
> AI-generated root cause summary:
> In IPsec IP-TFS (XFRM_MODE_IPTFS) processing, when inner packets (including the
> reused outer skb) are parsed and added to a temporary local 'sublist' during
> __input_process_payload(), any error encountering invalid header data or
> truncated payload jumps to 'done:'. At 'done:', packets on 'sublist' are neither
> delivered nor freed, and the reused outer skb is neither placed in 'defer' nor
> freed by kfree_skb(), permanently leaking the sk_buff and its attached sec_path
> extension.
>
> full analysis:  https://syzkaller.appspot.com/x/ai_root_cause?x=a3f21220cbbb6e14ee2e
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+a3f21220cbbb6e14ee2e@xxxxxxxxxxxxxxxxxxxxxxxxx
>
> 2026/10/28 09:56:01 executed programs: 5
> BUG: memory leak
> unreferenced object 0xffff888104c73c00 (size 240):
>   comm "syz.0.17", pid 5970, jiffies 4294947974
>   hex dump (first 32 bytes):
>     90 38 1f 02 00 c9 ff ff 90 38 1f 02 00 c9 ff ff  .8.......8......
>     00 00 6a 24 81 88 ff ff 00 00 00 00 00 00 00 00  ..j$............
>   backtrace (crc 84fdfeb5):
>     kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
>     slab_post_alloc_hook mm/slub.c:4733 [inline]
>     slab_alloc_node mm/slub.c:5033 [inline]
>     kmem_cache_alloc_noprof+0x35b/0x3e0 mm/slub.c:5047
>     __build_skb net/core/skbuff.c:495 [inline]
>     build_skb+0x25/0x120 net/core/skbuff.c:511
>     __tun_build_skb drivers/net/tun.c:1631 [inline]
>     tun_build_skb+0x489/0x770 drivers/net/tun.c:1726
>     tun_get_user+0xd2e/0x2040 drivers/net/tun.c:1860
>     tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:2100
>     new_sync_write fs/read_write.c:595 [inline]
>     vfs_write+0x3ae/0x720 fs/read_write.c:687
>     ksys_write+0xa5/0x170 fs/read_write.c:739
>     do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
>     do_syscall_64+0xe9/0x530 arch/x86/entry/syscall_64.c:84
>     entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> BUG: memory leak
> unreferenced object 0xffff888104d139c0 (size 192):
>   comm "syz.0.17", pid 5970, jiffies 4294947974
>   hex dump (first 32 bytes):
>     01 00 00 00 00 02 00 00 00 00 0b 00 00 00 00 00  ................
>     80 9f 7b 24 81 88 ff ff 00 00 00 00 00 00 00 00  ..{$............
>   backtrace (crc 420634a7):
>     kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
>     slab_post_alloc_hook mm/slub.c:4733 [inline]
>     slab_alloc_node mm/slub.c:5033 [inline]
>     kmem_cache_alloc_noprof+0x35b/0x3e0 mm/slub.c:5047
>     __skb_ext_alloc+0x1a/0x50 net/core/skbuff.c:7246
>     skb_ext_add+0x1a6/0x280 net/core/skbuff.c:7350
>     secpath_set+0x7c/0xc0 net/xfrm/xfrm_input.c:127
>     xfrm_input+0x381/0x28a0 net/xfrm/xfrm_input.c:571
>     vti_input+0xf4/0x160 net/ipv4/ip_vti.c:69
>     xfrm4_esp_rcv+0x46/0xb0 net/ipv4/xfrm4_protocol.c:104
>     ip_protocol_deliver_rcu+0x259/0x260 net/ipv4/ip_input.c:207
>     ip_local_deliver_finish+0x115/0x1e0 net/ipv4/ip_input.c:241
>     NF_HOOK include/linux/netfilter.h:325 [inline]
>     NF_HOOK include/linux/netfilter.h:319 [inline]
>     ip_local_deliver+0x97/0x140 net/ipv4/ip_input.c:262
>     dst_input include/net/dst.h:481 [inline]
>     ip_rcv_finish net/ipv4/ip_input.c:492 [inline]
>     NF_HOOK include/linux/netfilter.h:325 [inline]
>     NF_HOOK include/linux/netfilter.h:319 [inline]
>     ip_rcv+0x212/0x230 net/ipv4/ip_input.c:612
>     __netif_receive_skb_one_core+0xce/0x100 net/core/dev.c:6405
>     __netif_receive_skb+0x1d/0x80 net/core/dev.c:6518
>     netif_receive_skb_internal net/core/dev.c:6604 [inline]
>     netif_receive_skb+0x49/0x200 net/core/dev.c:6663
>     tun_rx_batched drivers/net/tun.c:1575 [inline]
>     tun_get_user+0x1ccc/0x2040 drivers/net/tun.c:2053
>     tun_chr_write_iter+0x71/0x120 drivers/net/tun.c:2100
>
> connection error: failed to recv *flatrpc.ExecutorMessageRawT: EOF
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@xxxxxxxxxxxxxxxx.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
>
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup

#syz test

diff --git a/net/xfrm/xfrm_iptfs.c b/net/xfrm/xfrm_iptfs.c
index 103cf7c5dbfb..0313a43aa8a9 100644
--- a/net/xfrm/xfrm_iptfs.c
+++ b/net/xfrm/xfrm_iptfs.c
@@ -1182,6 +1182,7 @@ static bool __input_process_payload(struct
xfrm_state *x, u32 data,
                /* this should not happen from the above code */
                XFRM_INC_STATS(net, LINUX_MIB_XFRMINIPTFSERROR);

+done:
        if (first_skb && first_iplen && !defer && !first_skb_partial) {
                /* first_skb is queued b/c !defer and not partial */
                if (pskb_trim(first_skb, first_iplen)) {
@@ -1198,7 +1199,7 @@ static bool __input_process_payload(struct
xfrm_state *x, u32 data,
                if (xfrm_input(skb, 0, 0, -2))
                        kfree_skb(skb);
        }
-done:
+
        skb = skbseq->root_skb;
        skb_abort_seq_read(skbseq);