Reported by syzkaller: "KASAN: slab-use-after-free Read in xfrm_alloc_spi"

Before commit 94f39804d891 ("xfrm: Duplicate SPI Handling")
xfrm_alloc_spi would report spi=0 as unavailable.
Add this behaviour back by adding 1 to the "low" value when it is passed as 0.
Allocating xfrm_state with spi=0 leads to UAF or CPU stall.

Fixes: 94f39804d891 ("xfrm: Duplicate SPI Handling")
Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
---
This should probably be sanitized in verify_spi_info
but doing so will change the interface.

The bug is easily reploducible by issuing some iproute commands:

root@syzkaller:~# ip xfrm state allocspi mode tunnel proto esp src 192.168.1.100 dst 192.168.1.200 min 0 max 3
src 192.168.1.100 dst 192.168.1.200
        proto esp spi 0x00000001 reqid 0 mode tunnel
        replay-window 0
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
        sel src 192.168.1.100/32 dst 192.168.1.200/32
root@syzkaller:~# ip xfrm state allocspi mode tunnel proto esp src 192.168.1.100 dst 192.168.1.200 min 0 max 3
src 192.168.1.100 dst 192.168.1.200
        proto esp spi 0x00000000 reqid 0 mode tunnel
        replay-window 0
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
        sel src 192.168.1.100/32 dst 192.168.1.200/32
root@syzkaller:~# ip xfrm state allocspi mode tunnel proto esp src 192.168.1.100 dst 192.168.1.200 min 0 max 3
src 192.168.1.100 dst 192.168.1.200
        proto esp spi 0x00000003 reqid 0 mode tunnel
        replay-window 0
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
        sel src 192.168.1.100/32 dst 192.168.1.200/32
root@syzkaller:~# ip xfrm state allocspi mode tunnel proto esp src 192.168.1.100 dst 192.168.1.200 min 0 max 3
[   34.267077] rcu: INFO: rcu_preempt self-detected stall on CPU
[   34.267107] rcu:     1-....: (1 GPs behind) idle=8b84/1/0x4000000000000000 softirq=9934/9935 fqs=5250
[   34.269110] rcu:     (t=21004 jiffies g=5953 q=571 ncpus=2)
[   34.271123] CPU: 1 UID: 0 PID: 296 Comm: ip Not tainted 6.17.0-rc6-00004-ge6f19f124217-dirty #55 PREEMPT(voluntary)
[   34.271123] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-5.fc42 04/01/2014
[   34.271123] RIP: 0010:xfrm_alloc_spi+0x2d5/0xe60

 net/xfrm/xfrm_state.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 78fcbb89cf32..4414346a24d7 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2566,7 +2566,9 @@ int xfrm_alloc_spi(struct xfrm_state *x, u32 low, u32 high,
 	unsigned int h;
 	struct xfrm_state *x0;
 	int err = -ENOENT;
-	u32 range = high - low + 1;
+	if (low == 0)
+		low = 1;
+	u32 range = high + 1 - low;
 	__be32 newspi = 0;
 
 	spin_lock_bh(&x->lock);
-- 
2.51.0

On Sun, Sep 21, 2025 at 05:27:01AM +0300, Nikola Z. Ivanov wrote:
> Reported by syzkaller: "KASAN: slab-use-after-free Read in xfrm_alloc_spi"
> 
> Before commit 94f39804d891 ("xfrm: Duplicate SPI Handling")
> xfrm_alloc_spi would report spi=0 as unavailable.
> Add this behaviour back by adding 1 to the "low" value when it is passed as 0.
> Allocating xfrm_state with spi=0 leads to UAF or CPU stall.
> 
> Fixes: 94f39804d891 ("xfrm: Duplicate SPI Handling")
> Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>

This is already fixed in the ipsec tree by

commit cd8ae32e4e46 ("xfrm: xfrm_alloc_spi shouldn't use 0 as SPI")

Thanks a lot anyway!