The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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 checking UDP functionality while using     pasta(1) to connect the container's network namespace, which leads us to a reproducer with the lookup     error resulting in an ICMP packet on a tap device: LOCAL_ADDR=$(ip -j -4 addr show|jq -rM '.[] |     .addr_info[0] | select(.scope == global).local') while :; do ./pasta --config-net -p pasta.pcap -u 1337     socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in     UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out done Once this fails: tmp.in tmp.out differ:
    char 8193, line 29 we can finally have a look at what's going on: $ tshark -r pasta.pcap 1 0.000000 :: ?     ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234     60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806     88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42     Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42     88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192     8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926     88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP     8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12     0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0 On the third datagram received, the network     namespace of the container initiates an ARP lookup to deliver the ICMP message. In another variant of this     reproducer, starting the client with: strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof     OPEN:tmp.out,create,tru ---truncated--- (CVE-2024-57974)

Note that Nessus relies on the presence of the package as reported by the vendor.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2024-57974

medium Nessus Plugin ID 231842

Version 1.10

Version 1.9

Version 1.8

Version 1.7

Version 1.5

Version 1.4

Version 1.3

Version 1.1

Version 1.10 Dec 4, 2025, 9:12 AM Detection (updated detection logic) Plugin Feed: 202512040912
Version 1.9 Nov 24, 2025, 10:08 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202511242208
Version 1.8 Oct 29, 2025, 3:03 AM Detection (updated detection logic) Plugin Feed: 202510290303
Version 1.7 Oct 28, 2025, 5:56 PM CVSS metrics ("CVSSv3 score" set to 4.7) CVSS metrics ("CVSSv3 vector" set to "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H") CVSS temporal metrics ("CVSSv2 temporal vector" set to "CVSS2#E:U/RL:U/RC:C") CVSS temporal metrics ("CVSSv3 temporal vector" set to "CVSS:3.0/E:U/RL:U/RC:C") CVSSv3 severity (based on None, severity decreased from "High" to "Medium") Detection (updated detection logic) Plugin Feed: 202510281756
Version 1.5 Sep 14, 2025, 2:50 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202509141450
Version 1.4 Sep 6, 2025, 2:03 AM CVSS metrics ("Cvssv4 score" set to 0.0) CVSSv2 severity (based on None, severity decreased from "High" to "Low") Detection (updated detection logic) Plugin metadata Plugin Feed: 202509060203
Version 1.3 Aug 27, 2025, 8:29 AM CVSS metrics ("Cvssv4 score" set to 0.0) CVSSv2 severity (based on None, severity decreased from "High" to "Low") Detection (updated detection logic) Plugin metadata Plugin Feed: 202508270829
Version 1.1 Mar 6, 2025, 5:02 PM New Plugin Feed: 202503061702