An update of the linux package has been released.

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

  - tcp: defer md5sig_info kfree past RCU grace period in tcp_connect The md5+ao reconciliation in     tcp_connect() (net/ipv4/tcp_output.c) has two symmetric branches: if (needs_md5) { tcp_ao_destroy_sock(sk,     false); } else if (needs_ao) { tcp_clear_md5_list(sk); kfree(rcu_replace_pointer(tp->md5sig_info, NULL,     ...)); } Both branches free a per-socket auth-info object while the socket is in TCP_SYN_SENT and is     already on the inet ehash (inserted by inet_hash_connect() in tcp_v4_connect()). Both branches are     reachable by softirq RX-path readers that load the corresponding info pointer via implicit RCU before     bh_lock_sock_nested() is taken. The needs_md5 branch is fixed in the prior patch by re-introducing the     call_rcu() free in tcp_ao_destroy_sock(): the equivalent per-key loop runs inside tcp_ao_info_free_rcu(),     the RCU callback, so by the time it frees each tcp_ao_key all softirq readers that captured the container     have already completed rcu_read_unlock(). The needs_ao branch is not symmetric in the same way. The     container free can be deferred via kfree_rcu(md5sig, rcu) -- struct tcp_md5sig_info already has the     required rcu member (include/net/tcp.h:1999-2002), and the rest of the tree already does this in the     tcp_md5sig_info_add() rollback paths (net/ipv4/tcp_ipv4.c:1410, 1436). But the per-key teardown is done by     tcp_clear_md5_list() in process context BEFORE the container's RCU grace period: it walks &md5sig->head     and frees each tcp_md5sig_key with bare hlist_del + kfree. A concurrent softirq reader in
    __tcp_md5_do_lookup() / __tcp_md5_do_lookup_exact() (tcp_ipv4.c:1253, 1298) walks the same list via     hlist_for_each_entry_rcu() and races with that bare kfree on the keys themselves -- a per-key slab use-     after-free of the same class as the TCP-AO bug, on the same race window. Fix this in two halves: 1.
    Convert the bare kfree() in tcp_connect() to kfree_rcu() so the md5sig_info container joins the rest of     the md5sig lifecycle. The local-variable lift is mechanical and required because kfree_rcu() is a macro     that expects an lvalue. 2. Make tcp_clear_md5_list() RCU-safe by replacing hlist_del + kfree(key) with     hlist_del_rcu + kfree_rcu(key, rcu). struct tcp_md5sig_key already carries the rcu member     (include/net/tcp.h:1995) and tcp_md5_do_del() (net/ipv4/tcp_ipv4.c:1456) already uses kfree_rcu, so this     restores the lifecycle invariant the rest of the file follows rather than introducing a one-off. The other     caller of tcp_clear_md5_list() is tcp_md5_destruct_sock() (net/ipv4/tcp.c:412), which runs from the sock     destructor when the socket is already unhashed and unreachable; the extra grace period there is     unnecessary but harmless. Making the helper unconditionally RCU-safe is the cleaner contract. The needs_ao     branch is not reachable by the userns reproducer used to demonstrate the AO-side splat (the repro installs     both keys but ends up in the needs_md5 branch because the connect peer matches the MD5 key, not the AO     key); however the symmetric race exists and a maintainer touching this code should not have to think about     which branch escapes RCU and which one does not. [also credits to Qihang, who found that this races with     tcp-diag] (CVE-2026-72139)

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

ID	Name	Product	Family	Published	Updated	Severity
334784	Photon OS 5.0: Linux PHSA-2026-5.0-92-0952	Nessus	PhotonOS Local Security Checks	8/12/2026	9/7/2026	high
341880	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-2071)	Nessus	Amazon Linux Local Security Checks	8/31/2026	9/10/2026	high
337427	Linux Distros Unpatched Vulnerability : CVE-2026-72139	Nessus	Misc.	8/18/2026	8/28/2026	critical

Detections

Analytics

Plugins Search

high

high

critical