Message-ID: <CAJLDUOc6BFzUw0VE+TahCFVE7MZSvZNVao4JaenHXbg8BVKYqQ@mail.gmail.com>
Date: Sat, 9 Aug 2025 12:10:07 +0800
From: yes PANG <pangyes608@...il.com>
To: steffen.klassert@...unet.com, 
	"herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>, davem@...emloft.net, kuba@...nel.org, 
	"edumazet@...gle.com" <edumazet@...gle.com>, "pabeni@...hat.com" <pabeni@...hat.com>, horms@...nel.org, 
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: KASAN: slab-use-after-free Read in xfrm_alloc_spi

Dear Linux maintainers and reviewers:
We are reporting a Linux kernel bug titled **KASAN: slab-use-after-free
Read in xfrm_alloc_spi**, discovered using a modified version of Syzkaller.

Linux version : 89748acdf226fd1a8775ff6fa2703f8412b286c8

The test case, kernel config and  bisection log are attached.

The bisection log shows the first introduced commit is
982bf37da09d078570650b691d9084f43805a5de
commit 94f39804d891cffe4ce17737d295f3b195bc7299
Author: Aakash Kumar S <saakashkumar@...vell.com>
Date:   Mon Jun 30 18:08:56 2025 +0530

    xfrm: Duplicate SPI Handling

    The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI
    Netlink message, which triggers the kernel function xfrm_alloc_spi().
    This function is expected to ensure uniqueness of the Security Parameter
    Index (SPI) for inbound Security Associations (SAs). However, it can
    return success even when the requested SPI is already in use, leading
    to duplicate SPIs assigned to multiple inbound SAs, differentiated
    only by their destination addresses.

    This behavior causes inconsistencies during SPI lookups for inbound
packets.
    Since the lookup may return an arbitrary SA among those with the same
SPI,
    packet processing can fail, resulting in packet drops.

    According to RFC 4301 section 4.4.2 , for inbound processing a unicast
SA
    is uniquely identified by the SPI and optionally protocol.

    Reproducing the Issue Reliably:
    To consistently reproduce the problem, restrict the available SPI range
in
    charon.conf : spi_min = 0x10000000 spi_max = 0x10000002
    This limits the system to only 2 usable SPI values.
    Next, create more than 2 Child SA. each using unique pair of src/dst
address.
    As soon as the 3rd Child SA is initiated, it will be assigned a
duplicate
    SPI, since the SPI pool is already exhausted.
    With a narrow SPI range, the issue is consistently reproducible.
    With a broader/default range, it becomes rare and unpredictable.

    Current implementation:
    xfrm_spi_hash() lookup function computes hash using daddr, proto, and
family.
    So if two SAs have the same SPI but different destination addresses,
then
    they will:
    a. Hash into different buckets
    b. Be stored in different linked lists (byspi + h)
    c. Not be seen in the same hlist_for_each_entry_rcu() iteration.
    As a result, the lookup will result in NULL and kernel allows that
Duplicate SPI

    Proposed Change:
    xfrm_state_lookup_spi_proto() does a truly global search - across all
states,
    regardless of hash bucket and matches SPI and proto.

    Signed-off-by: Aakash Kumar S <saakashkumar@...vell.com>
    Acked-by: Herbert Xu <herbert@...dor.apana.org.au>
    Signed-off-by: Steffen Klassert <steffen.klassert@...unet.com>

 net/xfrm/xfrm_state.c | 72
++++++++++++++++++++++++++++++---------------------
 1 file changed, 43 insertions(+), 29 deletions(-)

The report is (The full report is attached):
------------[ cut here ]------------
BUG: KASAN: slab-use-after-free in xfrm_state_lookup_spi_proto
net/xfrm/xfrm_state.c:1708 [inline]
BUG: KASAN: slab-use-after-free in xfrm_alloc_spi+0x671/0x1160
net/xfrm/xfrm_state.c:2589
Read of size 4 at addr ffff88801cad62c4 by task syz.1.15136/75282

CPU: 1 UID: 0 PID: 75282 Comm: syz.1.15136 Not tainted
6.16.0-g89748acdf226-dirty #2 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x226/0x350 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0x18d/0x550 mm/kasan/report.c:482
 kasan_report+0x147/0x180 mm/kasan/report.c:595
 xfrm_state_lookup_spi_proto net/xfrm/xfrm_state.c:1708 [inline]
 xfrm_alloc_spi+0x671/0x1160 net/xfrm/xfrm_state.c:2589
 xfrm_alloc_userspi+0x783/0xe50 net/xfrm/xfrm_user.c:1873
 xfrm_user_rcv_msg+0x8a5/0xbe0 net/xfrm/xfrm_user.c:3501
 netlink_rcv_skb+0x20c/0x470 net/netlink/af_netlink.c:2552
 xfrm_netlink_rcv+0x79/0x90 net/xfrm/xfrm_user.c:3523
 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
 netlink_unicast+0x891/0xa50 net/netlink/af_netlink.c:1346
 netlink_sendmsg+0x97f/0xca0 net/netlink/af_netlink.c:1896
 sock_sendmsg_nosec net/socket.c:714 [inline]
 __sock_sendmsg+0x21f/0x270 net/socket.c:729
 ____sys_sendmsg+0x52b/0x860 net/socket.c:2614
 ___sys_sendmsg+0x27b/0x310 net/socket.c:2668
 __sys_sendmsg net/socket.c:2700 [inline]
 __do_sys_sendmsg net/socket.c:2705 [inline]
 __se_sys_sendmsg net/socket.c:2703 [inline]
 __x64_sys_sendmsg+0x19e/0x270 net/socket.c:2703
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x8e/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f03563af50d
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f03572bbb78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f03565d5fa0 RCX: 00007f03563af50d
RDX: 0000000022004000 RSI: 0000200000000b40 RDI: 0000000000000003
RBP: 00007f03564350df R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f03565d5fa0 R15: 00007f03572bbd40
 </TASK>

Content of type "text/html" skipped

View attachment "repro.c" of type "text/plain" (4575 bytes)

Download attachment "report0" of type "application/octet-stream" (8636 bytes)

View attachment "kconfig.txt" of type "text/plain" (257836 bytes)

Download attachment "bisect.log" of type "application/octet-stream" (24103 bytes)

Powered by blists - more mailing lists