netdev - Re: CVE-2025-21997: xsk: fix an integer overflow in xp_create_and_assign

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <d288da56-2f5c-4839-bb0f-de98d2a6bc81@oracle.com>
Date: Thu, 22 May 2025 16:53:33 +0200
From: Vegard Nossum <vegard.nossum@...cle.com>
To: cve@...nel.org, linux-kernel@...r.kernel.org,
        linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        David Fernandez Gonzalez <david.fernandez.gonzalez@...cle.com>,
        Denis Pilipchuk <denis.pilipchuk@...cle.com>,
        Gavrilov Ilia <Ilia.Gavrilov@...otecs.ru>,
        Paolo Abeni <pabeni@...hat.com>,
        Björn Töpel <bjorn@...nel.org>,
        Magnus Karlsson <magnus.karlsson@...el.com>,
        Maciej Fijalkowski <maciej.fijalkowski@...el.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        "David S. Miller"
 <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        John Fastabend <john.fastabend@...il.com>
Subject: Re: CVE-2025-21997: xsk: fix an integer overflow in
 xp_create_and_assign_umem()


On 03/04/2025 09:17, Greg Kroah-Hartman wrote:
> Description
> ===========
> 
> In the Linux kernel, the following vulnerability has been resolved:
> 
> xsk: fix an integer overflow in xp_create_and_assign_umem()
> 
> Since the i and pool->chunk_size variables are of type 'u32',
> their product can wrap around and then be cast to 'u64'.
> This can lead to two different XDP buffers pointing to the same
> memory area.
> 
> Found by InfoTeCS on behalf of Linux Verification Center
> (linuxtesting.org) with SVACE.
> 
> The Linux kernel CVE team has assigned CVE-2025-21997 to this issue.
> 
> 
> Affected and fixed versions
> ===========================
> 
> 	Issue introduced in 5.16 with commit 94033cd8e73b8632bab7c8b7bb54caa4f5616db7 and fixed in 6.1.132 with commit 205649d642a5b376724f04f3a5b3586815e43d3b
> 	Issue introduced in 5.16 with commit 94033cd8e73b8632bab7c8b7bb54caa4f5616db7 and fixed in 6.6.85 with commit b7b4be1fa43294b50b22e812715198629806678a
> 	Issue introduced in 5.16 with commit 94033cd8e73b8632bab7c8b7bb54caa4f5616db7 and fixed in 6.12.21 with commit 130290f44bce0eead2b827302109afc3fe189ddd
> 	Issue introduced in 5.16 with commit 94033cd8e73b8632bab7c8b7bb54caa4f5616db7 and fixed in 6.13.9 with commit c7670c197b0f1a8726ad5c87bc2bf001a1fc1bbd
> 	Issue introduced in 5.16 with commit 94033cd8e73b8632bab7c8b7bb54caa4f5616db7 and fixed in 6.14 with commit 559847f56769037e5b2e0474d3dbff985b98083d

(+Cc XDP maintainers)

Hi,

We've had a look at this and we're not sure this is exploitable in any 
way. The patch is:

--- a/net/xdp/xsk_buff_pool.c
+++ b/net/xdp/xsk_buff_pool.c
@@ -105,7 +105,7 @@ struct xsk_buff_pool 
*xp_create_and_assign_umem(struct xdp_sock *xs,
  		if (pool->unaligned)
  			pool->free_heads[i] = xskb;
  		else
-			xp_init_xskb_addr(xskb, pool, i * pool->chunk_size);
+			xp_init_xskb_addr(xskb, pool, (u64)i * pool->chunk_size);
  	}

  	return pool;

The value passed by xp_create_and_assign_umem() here is an offset into a
userspace-provided buffer (the UMEM):

static inline void xp_init_xskb_addr(struct xdp_buff_xsk *xskb, struct 
xsk_buff_pool *pool,
                                      u64 addr)
{
         xskb->xdp.data_hard_start = pool->addrs + addr + pool->headroom;
}

(pool->addrs here is a vmap()ed kernel address)

Without the fix, that offset will be truncated to 32 bits, but it will
still be a valid offset into the buffer -- there is no way to go out of
bounds, for example. Moreover, since this is a buffer for the calling
process, it has no effect on anything except the process itself.

In other words, the process can shoot itself in the foot if it wants to,
but it cannot affect other processes or the kernel itself in any way
that it couldn't do already. There is no kernel undefined behavior
(use-after-free, double free, out-of-bounds memory access, etc.) as far
as we can tell.

We're not XDP experts, so we'd be interested to hear what others
(especially the maintainers) think -- it's a bug for sure, but is it
a vulnerability?

Thanks,


Vegard