ACK: [SRU][F/N][PATCH 0/1] CVE-2024-56614

[Agathe Porte]

2025-02-06 17:30 CET, Massimiliano Pellizzer:
> [Impact]
> 
> In the xsk_map_delete_elem function an unsigned integer
> (map->max_entries) is compared with a user-controlled signed integer
> (k). Due to implicit type conversion, a large unsigned value for
> map->max_entries can bypass the intended bounds check:
> 
> 	if (k >= map->max_entries)
> 		return -EINVAL;
> 
> This allows k to hold a negative value (between -2147483648 and -2),
> which is then used as an array index in m->xsk_map[k], which results
> in an out-of-bounds access.
> 
> 	spin_lock_bh(&m->lock);
> 	map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry
> 	old_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write
> 	if (old_xs)
> 		xsk_map_sock_delete(old_xs, map_entry);
> 	spin_unlock_bh(&m->lock);
> 
> The xchg operation can then be used to cause an out-of-bounds write.
> Moreover, the invalid map_entry passed to xsk_map_sock_delete can lead
> to further memory corruption.
> 
> Fix this by simply changing key type from int to u32.
> 
> [Fix]
> 
> Oracular: Fixed via upstream stable updates (LP: #2096827)
> Noble: Clean cherry pick from mainline
> Jammy: Fixed via upstream stable updates (LP: #2095283)
> Focal: Backported from mainline
> 
> [Test Case]
> 
> Compile tested only.
> 
> [Where problems could occur]
> 
> A regression here is unlikely due to the very limited scope of the
> patch.
> 
> Maciej Fijalkowski (1):
>   xsk: fix OOB map writes when deleting elements
> 
>  kernel/bpf/xskmap.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Agathe Porte <agathe.porte at canonical.com>