cbcvebase.
CVE-2024-57974
published 2025-02-27

CVE-2024-57974: In the Linux kernel, the following vulnerability has been resolved: udp: Deal with race between UDP socket address change and rehash If a UDP socket changes…

PriorityP419medium4.7CVSS 3.1
AVLACHPRLUINSUCNINAH
EPSS
0.14%
4.1th percentile
In the Linux kernel, the following vulnerability has been resolved: udp: Deal with race between UDP socket address change and rehash If a UDP socket changes its local address while it's receiving datagrams, as a result of connect(), there is a period during which a lookup operation might fail to find it, after the address is changed but before the secondary hash (port and address) and the four-tuple hash (local and remote ports and addresses) are updated. Secondary hash chains were introduced by commit 30fff9231fad ("udp: bind() optimisation") and, as a result, a rehash operation became needed to make a bound socket reachable again after a connect(). This operation was introduced by commit 719f835853a9 ("udp: add rehash on connect()") which isn't however a complete fix: the socket will be found once the rehashing completes, but not while it's pending. This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a client sending datagrams to it. After the server receives the first datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to the address of the sender, in order to set up a directed flow. Now, if the client, running on a different CPU thread, happens to send a (subsequent) datagram while the server's socket changes its address, but is not rehashed yet, this will result in a failed lookup and a port unreachable error delivered to the client, as apparent from the following reproducer: LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null wait done where the client will eventually get ECONNREFUSED on a write() (typically the second or third one of a given iteration): 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused This issue was first observed as a seldom failure in Podman's tests checkin

Affected

23 ranges
VendorProductVersion rangeFixed in
debianlinux< linux 6.12.13-1 (forky)linux 6.12.13-1 (forky)
linuxlinux
linuxlinux>= 30fff9231fad757c061285e347b33c5149c2c2e4 < 4f8344fce91c5766d368edb0ad80142eacd805c74f8344fce91c5766d368edb0ad80142eacd805c7
linuxlinux>= 30fff9231fad757c061285e347b33c5149c2c2e4 < d65d3bf309b2649d27b24efd0d8784da2d81f2a6d65d3bf309b2649d27b24efd0d8784da2d81f2a6
linuxlinux>= 30fff9231fad757c061285e347b33c5149c2c2e4 < a502ea6fa94b1f7be72a24bcf9e3f5f6b7e6e90ca502ea6fa94b1f7be72a24bcf9e3f5f6b7e6e90c
linuxlinux_kernel>= 0 < 6.12.13-16.12.13-1
linuxlinux_kernel>= 0 < 6.12.13-16.12.13-1
linuxlinux_kernel>= 0 < 6.8.0-64.676.8.0-64.67
linuxlinux_kernel>= 2.6.33 < 6.12.136.12.13
linuxlinux_kernel>= 6.13 < 6.13.26.13.2
msrcazl3_kernel_6.6.104.2-4_on_azure_linux_3.0
msrcazl3_kernel_6.6.112.1-2_on_azure_linux_3.0
msrcazl3_kernel_6.6.117.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.119.3-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.119.3-3_on_azure_linux_3.0
msrcazl3_kernel_6.6.121.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.126.1-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.130.1-3_on_azure_linux_3.0
msrcazl3_kernel_6.6.96.2-1_on_azure_linux_3.0
msrcazl3_kernel_6.6.96.2-2_on_azure_linux_3.0
msrccbl2_kernel_5.15.186.1-1_on_cbl_mariner_2.0
msrccbl2_kernel_5.15.200.1-1_on_cbl_mariner_2.0
msrccbl2_kernel_5.15.202.1-1_on_cbl_mariner_2.0

CVSS provenance

nvdv3.14.7MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
osv7.8HIGH
vendor_ubuntu7.8HIGH
vendor_debian4.7MEDIUM
vendor_msrc4.7MEDIUM
vendor_redhat4.7MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.