In the Linux kernel, the following vulnerability has been resolved: 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]

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: 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)

The remote Ubuntu 24.04 LTS / 26.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-8816-1 advisory.

    Several security issues were discovered in the Linux kernel. An attacker could possibly use these to     compromise the system. This update corrects flaws in the following subsystems:

    - ARM64 architecture;

    - S390 architecture;

    - x86 architecture;

    - DRBD Distributed Replicated Block Device drivers;

    - InfiniBand drivers;

    - IOMMU subsystem;

    - Multiple devices driver;

    - Network drivers;

    - Microsoft Azure Network Adapter (MANA) driver;

    - NVME drivers;

    - TCM subsystem;

    - Virtio Host (VHOST) subsystem;

    - Xen hypervisor drivers;

    - AFS file system;

    - File systems infrastructure;

    - Network file systems library;

    - Network file system (NFS) client;

    - NTFS3 file system;

    - OCFS2 file system;

    - OrangeFS file system;

    - SMB network file system;

    - IPv4 networking;

    - Sun RPC protocol;

    - IPv6 networking;

    - IP tunnels definitions;

    - Netfilter;

    - TCP network protocol;

    - Locking primitives;

    - 9P file system network protocol;

    - B.A.T.M.A.N. meshing protocol;

    - Networking core;

    - IFE protocol;

    - RxRPC session sockets;

    - Network traffic control;

    - SCTP protocol;

    - SMC sockets;

    - TIPC protocol;

    - XFRM subsystem; (CVE-2026-64530, CVE-2026-64534, CVE-2026-64535, CVE-2026-64541, CVE-2026-64551,     CVE-2026-68083, CVE-2026-68457, CVE-2026-68476, CVE-2026-68477, CVE-2026-72014, CVE-2026-72020,     CVE-2026-72033, CVE-2026-72041, CVE-2026-72046, CVE-2026-72064, CVE-2026-72065, CVE-2026-72069,     CVE-2026-72083, CVE-2026-72084, CVE-2026-72085, CVE-2026-72098, CVE-2026-72129, CVE-2026-72130,     CVE-2026-72137, CVE-2026-72139, CVE-2026-72191, CVE-2026-72192, CVE-2026-72194, CVE-2026-72217,     CVE-2026-72220, CVE-2026-72221, CVE-2026-72222, CVE-2026-72226, CVE-2026-72234, CVE-2026-72248,     CVE-2026-72249, CVE-2026-72251, CVE-2026-72277, CVE-2026-72278, CVE-2026-72279, CVE-2026-72287,     CVE-2026-72288, CVE-2026-72289, CVE-2026-72296, CVE-2026-72299, CVE-2026-72317, CVE-2026-72318,     CVE-2026-72319, CVE-2026-72320, CVE-2026-72322, CVE-2026-72323, CVE-2026-72329, CVE-2026-72339,     CVE-2026-72348, CVE-2026-72351, CVE-2026-72355, CVE-2026-72366, CVE-2026-72381, CVE-2026-72393,     CVE-2026-72398, CVE-2026-72399, CVE-2026-72412, CVE-2026-72417, CVE-2026-72422, CVE-2026-72429,     CVE-2026-72436, CVE-2026-72442, CVE-2026-72451, CVE-2026-72463, CVE-2026-72466, CVE-2026-72472,     CVE-2026-72473, CVE-2026-72477, CVE-2026-72491, CVE-2026-72493, CVE-2026-72494, CVE-2026-72495,     CVE-2026-72496, CVE-2026-72501, CVE-2026-74255, CVE-2026-74267, CVE-2026-74268, CVE-2026-74269,     CVE-2026-74287, CVE-2026-74310, CVE-2026-74345, CVE-2026-74350, CVE-2026-74361, CVE-2026-74376,     CVE-2026-74384, CVE-2026-74394, CVE-2026-74398, CVE-2026-74401, CVE-2026-74406, CVE-2026-74427,     CVE-2026-74428, CVE-2026-74433, CVE-2026-74434, CVE-2026-74436, CVE-2026-74439, CVE-2026-80665)

Tenable has extracted the preceding description block directly from the Ubuntu security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

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

  - In the Linux kernel, the following vulnerability has been resolved: 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.

An update of the linux package has been released.

ID	Name	Product	Family	Type	Severity
470112	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.21	Tenable Cloud Security	Google COS Security Checks	Local	critical
470112	Google: sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.21	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	critical
350177	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8816-1)	Nessus	Ubuntu Local Security Checks	Local	critical
341880	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-2071)	Nessus	Amazon Linux Local Security Checks	Local	high
337427	Linux Distros Unpatched Vulnerability : CVE-2026-72139	Nessus	Misc.	Local	critical
334784	Photon OS 5.0: Linux PHSA-2026-5.0-92-0952	Nessus	PhotonOS Local Security Checks	Local	high

Detections

Analytics

CVE-2026-72139

critical

Tenable Plugins

critical

critical

critical

high

critical

high