In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack: fix crash due to removal of uninitialised entry A crash in conntrack was reported while trying to unlink the conntrack entry from the hash bucket list: [exception RIP: __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack] #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack] #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack] [..] The nf_conn struct is marked as allocated from slab but appears to be in a partially initialised state: ct hlist pointer is garbage; looks like the ct hash value (hence crash). ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected ct->timeout is 30000 (=30s), which is unexpected. Everything else looks like normal udp conntrack entry. If we ignore ct->status and pretend its 0, the entry matches those that are newly allocated but not yet inserted into the hash: - ct hlist pointers are overloaded and store/cache the raw tuple hash - ct->timeout matches the relative time expected for a new udp flow rather than the absolute 'jiffies' value. If it were not for the presence of IPS_CONFIRMED, __nf_conntrack_find_get() would have skipped the entry. Theory is that we did hit following race: cpu x cpu y cpu z found entry E found entry E E is expired <preemption> nf_ct_delete() return E to rcu slab init_conntrack E is re-inited, ct->status set to 0 reply tuplehash hnnode.pprev stores hash value. cpu y found E right before it was deleted on cpu x. E is now re-inited on cpu z. cpu y was preempted before checking for expiry and/or confirm bit. ->refcnt set to 1 E now owned by skb ->timeout set to 30000 If cpu y were to resume now, it would observe E as expired but would skip E due to missing CONFIRMED bit. nf_conntrack_confirm gets called sets: ct->status |= CONFIRMED This is wrong: E is not yet added to hashtable. cpu y resumes, it observes E as expired but CONFIRMED: <resumes> nf_ct_expired() -> yes (ct->timeout is 30s) confirmed bit set. cpu y will try to delete E from the hashtable: nf_ct_delete() -> set DYING bit __nf_ct_delete_from_lists Even this scenario doesn't guarantee a crash: cpu z still holds the table bucket lock(s) so y blocks: wait for spinlock held by z CONFIRMED is set but there is no guarantee ct will be added to hash: "chaintoolong" or "clash resolution" logic both skip the insert step. reply hnnode.pprev still stores the hash value. unlocks spinlock return NF_DROP <unblocks, then crashes on hlist_nulls_del_rcu pprev> In case CPU z does insert the entry into the hashtable, cpu y will unlink E again right away but no crash occurs. Without 'cpu y' race, 'garbage' hlist is of no consequence: ct refcnt remains at 1, eventually skb will be free'd and E gets destroyed via: nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy. To resolve this, move the IPS_CONFIRMED assignment after the table insertion but before the unlock. Pablo points out that the confirm-bit-store could be reordered to happen before hlist add resp. the timeout fixup, so switch to set_bit and before_atomic memory barrier to prevent this. It doesn't matter if other CPUs can observe a newly inserted entry right before the CONFIRMED bit was set: Such event cannot be distinguished from above "E is the old incarnation" case: the entry will be skipped. Also change nf_ct_should_gc() to first check the confirmed bit. The gc sequence is: 1. Check if entry has expired, if not skip to next entry 2. Obtain a reference to the expired entry. 3. Call nf_ct_should_gc() to double-check step 1. nf_ct_should_gc() is thus called only for entries that already failed an expiry check. After this patch, once the confirmed bit check pas ---truncated---

debian_linux dsa-5975: Debian dsa-5975 : ata-modules-6.12.38+deb13-armmp-di - security update

The remote Redhat Enterprise Linux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2025:15005 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    * kernel: udp: Fix memory accounting leak. (CVE-2025-22058)

    * kernel: net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too (CVE-2025-37823)

    * kernel: ext4: only dirty folios when data journaling regular files (CVE-2025-38220)

    * kernel: RDMA/iwcm: Fix use-after-free of work objects after cm_id destruction (CVE-2025-38211)

    * kernel: tipc: Fix use-after-free in tipc_conn_close() (CVE-2025-38464)

    * kernel: vsock: Fix transport_* TOCTOU (CVE-2025-38461)

    * kernel: netfilter: nf_conntrack: fix crash due to removal of uninitialised entry (CVE-2025-38472)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

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

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.

  - netfilter: nf_conntrack: fix crash due to removal of uninitialised entry A crash in conntrack was reported     while trying to unlink the conntrack entry from the hash bucket list: [exception RIP:
    __nf_ct_delete_from_lists+172] [..] #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack]     #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack] #9 [ff539b5a2b043ae0]
    __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack] [..] The nf_conn struct is marked as allocated     from slab but appears to be in a partially initialised state: ct hlist pointer is garbage; looks like the     ct hash value (hence crash). ct->status is equal to IPS_CONFIRMED|IPS_DYING, which is expected ct->timeout     is 30000 (=30s), which is unexpected. Everything else looks like normal udp conntrack entry. If we ignore     ct->status and pretend its 0, the entry matches those that are newly allocated but not yet inserted into     the hash: - ct hlist pointers are overloaded and store/cache the raw tuple hash - ct->timeout matches the     relative time expected for a new udp flow rather than the absolute 'jiffies' value. If it were not for the     presence of IPS_CONFIRMED, __nf_conntrack_find_get() would have skipped the entry. Theory is that we did     hit following race: cpu x cpu y cpu z found entry E found entry E E is expired <preemption> nf_ct_delete()     return E to rcu slab init_conntrack E is re-inited, ct->status set to 0 reply tuplehash hnnode.pprev     stores hash value. cpu y found E right before it was deleted on cpu x. E is now re-inited on cpu z. cpu y     was preempted before checking for expiry and/or confirm bit. ->refcnt set to 1 E now owned by skb
    ->timeout set to 30000 If cpu y were to resume now, it would observe E as expired but would skip E due to     missing CONFIRMED bit. nf_conntrack_confirm gets called sets: ct->status |= CONFIRMED This is wrong: E is     not yet added to hashtable. cpu y resumes, it observes E as expired but CONFIRMED: <resumes>     nf_ct_expired() -> yes (ct->timeout is 30s) confirmed bit set. cpu y will try to delete E from the     hashtable: nf_ct_delete() -> set DYING bit __nf_ct_delete_from_lists Even this scenario doesn't guarantee     a crash: cpu z still holds the table bucket lock(s) so y blocks: wait for spinlock held by z CONFIRMED is     set but there is no guarantee ct will be added to hash: chaintoolong or clash resolution logic both     skip the insert step. reply hnnode.pprev still stores the hash value. unlocks spinlock return NF_DROP     <unblocks, then crashes on hlist_nulls_del_rcu pprev> In case CPU z does insert the entry into the     hashtable, cpu y will unlink E again right away but no crash occurs. Without 'cpu y' race, 'garbage' hlist     is of no consequence: ct refcnt remains at 1, eventually skb will be free'd and E gets destroyed via:
    nf_conntrack_put -> nf_conntrack_destroy -> nf_ct_destroy. To resolve this, move the IPS_CONFIRMED     assignment after the table insertion but before the unlock. Pablo points out that the confirm-bit-store     could be reordered to happen before hlist add resp. the timeout fixup, so switch to set_bit and     before_atomic memory barrier to prevent this. It doesn't matter if other CPUs can observe a newly inserted     entry right before the CONFIRMED bit was set: Such event cannot be distinguished from above E is the old     incarnation case: the entry will be skipped. Also change nf_ct_should_gc() to first check the confirmed     bit. The gc sequence is: 1. Check if entry has expired, if not skip to next entry 2. Obtain a reference to     the expired entry. 3. Call nf_ct_should_gc() to double-check step 1. nf_ct_should_gc() is thus called only     for entries that already failed an expiry check. After this patch, once the confirmed bit check pas
    ---truncated--- (CVE-2025-38472)

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

The remote Debian 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-5973 advisory.

    - -------------------------------------------------------------------------     Debian Security Advisory DSA-5973-1                   security@debian.org     https://www.debian.org/security/                     Salvatore Bonaccorso     August 12, 2025                       https://www.debian.org/security/faq
    - -------------------------------------------------------------------------

    Package        : linux     CVE ID         : CVE-2024-36350 CVE-2024-36357 CVE-2024-36913 CVE-2024-41013                      CVE-2024-56758 CVE-2024-57883 CVE-2025-21816 CVE-2025-22119                      CVE-2025-27558 CVE-2025-37958 CVE-2025-38000 CVE-2025-38001                      CVE-2025-38003 CVE-2025-38004 CVE-2025-38031 CVE-2025-38034                      CVE-2025-38035 CVE-2025-38037 CVE-2025-38040 CVE-2025-38043                      CVE-2025-38044 CVE-2025-38048 CVE-2025-38051 CVE-2025-38052                      CVE-2025-38058 CVE-2025-38061 CVE-2025-38062 CVE-2025-38063                      CVE-2025-38065 CVE-2025-38066 CVE-2025-38067 CVE-2025-38068                      CVE-2025-38071 CVE-2025-38072 CVE-2025-38074 CVE-2025-38075                      CVE-2025-38077 CVE-2025-38078 CVE-2025-38079 CVE-2025-38083                      CVE-2025-38084 CVE-2025-38085 CVE-2025-38086 CVE-2025-38088                      CVE-2025-38090 CVE-2025-38097 CVE-2025-38100 CVE-2025-38102                      CVE-2025-38103 CVE-2025-38107 CVE-2025-38108 CVE-2025-38111                      CVE-2025-38112 CVE-2025-38113 CVE-2025-38115 CVE-2025-38118                      CVE-2025-38119 CVE-2025-38120 CVE-2025-38122 CVE-2025-38124                      CVE-2025-38126 CVE-2025-38131 CVE-2025-38135 CVE-2025-38136                      CVE-2025-38138 CVE-2025-38142 CVE-2025-38143 CVE-2025-38145                      CVE-2025-38146 CVE-2025-38147 CVE-2025-38148 CVE-2025-38151                      CVE-2025-38153 CVE-2025-38154 CVE-2025-38157 CVE-2025-38158                      CVE-2025-38159 CVE-2025-38160 CVE-2025-38161 CVE-2025-38163                      CVE-2025-38165 CVE-2025-38166 CVE-2025-38167 CVE-2025-38170                      CVE-2025-38173 CVE-2025-38174 CVE-2025-38180 CVE-2025-38181                      CVE-2025-38183 CVE-2025-38184 CVE-2025-38185 CVE-2025-38190                      CVE-2025-38191 CVE-2025-38193 CVE-2025-38194 CVE-2025-38197                      CVE-2025-38198 CVE-2025-38200 CVE-2025-38202 CVE-2025-38211                      CVE-2025-38212 CVE-2025-38214 CVE-2025-38215 CVE-2025-38218                      CVE-2025-38219 CVE-2025-38222 CVE-2025-38225 CVE-2025-38226                      CVE-2025-38227 CVE-2025-38229 CVE-2025-38230 CVE-2025-38231                      CVE-2025-38236 CVE-2025-38239 CVE-2025-38245 CVE-2025-38249                      CVE-2025-38251 CVE-2025-38257 CVE-2025-38259 CVE-2025-38260                      CVE-2025-38262 CVE-2025-38263 CVE-2025-38273 CVE-2025-38275                      CVE-2025-38277 CVE-2025-38280 CVE-2025-38282 CVE-2025-38285                      CVE-2025-38286 CVE-2025-38293 CVE-2025-38298 CVE-2025-38300                      CVE-2025-38304 CVE-2025-38305 CVE-2025-38310 CVE-2025-38312                      CVE-2025-38313 CVE-2025-38319 CVE-2025-38320 CVE-2025-38323                      CVE-2025-38324 CVE-2025-38326 CVE-2025-38328 CVE-2025-38331                      CVE-2025-38332 CVE-2025-38334 CVE-2025-38336 CVE-2025-38337                      CVE-2025-38342 CVE-2025-38344 CVE-2025-38345 CVE-2025-38346                      CVE-2025-38348 CVE-2025-38350 CVE-2025-38352 CVE-2025-38354                      CVE-2025-38362 CVE-2025-38363 CVE-2025-38364 CVE-2025-38365                      CVE-2025-38371 CVE-2025-38375 CVE-2025-38377 CVE-2025-38380                      CVE-2025-38382 CVE-2025-38384 CVE-2025-38385 CVE-2025-38386                      CVE-2025-38387 CVE-2025-38389 CVE-2025-38391 CVE-2025-38393                      CVE-2025-38395 CVE-2025-38396 CVE-2025-38399 CVE-2025-38400                      CVE-2025-38401 CVE-2025-38403 CVE-2025-38404 CVE-2025-38406                      CVE-2025-38409 CVE-2025-38410 CVE-2025-38412 CVE-2025-38415                      CVE-2025-38416 CVE-2025-38418 CVE-2025-38419 CVE-2025-38420                      CVE-2025-38422 CVE-2025-38424 CVE-2025-38425 CVE-2025-38428                      CVE-2025-38430 CVE-2025-38437 CVE-2025-38439 CVE-2025-38441                      CVE-2025-38443 CVE-2025-38444 CVE-2025-38445 CVE-2025-38448                      CVE-2025-38451 CVE-2025-38455 CVE-2025-38456 CVE-2025-38457                      CVE-2025-38458 CVE-2025-38459 CVE-2025-38460 CVE-2025-38461                      CVE-2025-38462 CVE-2025-38464 CVE-2025-38465 CVE-2025-38466                      CVE-2025-38467 CVE-2025-38468 CVE-2025-38470 CVE-2025-38471                      CVE-2025-38472 CVE-2025-38473 CVE-2025-38474 CVE-2025-38476                      CVE-2025-38477 CVE-2025-38478 CVE-2025-38480 CVE-2025-38481                      CVE-2025-38482 CVE-2025-38483 CVE-2025-38485 CVE-2025-38487                      CVE-2025-38488 CVE-2025-38494 CVE-2025-38495 CVE-2025-38497                      CVE-2025-38498 CVE-2025-38499

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For the oldstable distribution (bookworm), these problems have been fixed     in version 6.1.147-1.

    We recommend that you upgrade your linux packages.

    For the detailed security status of linux please refer to its security     tracker page at:
    https://security-tracker.debian.org/tracker/linux

    Further information about Debian Security Advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://www.debian.org/security/

    Mailing list: debian-security-announce@lists.debian.org

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

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

ID	Name	Product	Family	Severity
260457	RHEL 10 : kernel (RHSA-2025:15005)	Nessus	Red Hat Local Security Checks	high
252275	Photon OS 5.0: Linux PHSA-2025-5.0-0575	Nessus	PhotonOS Local Security Checks	high
251301	Linux Distros Unpatched Vulnerability : CVE-2025-38472	Nessus	Misc.	medium
249177	Debian dsa-5973 : affs-modules-6.1.0-37-4kc-malta-di - security update	Nessus	Debian Local Security Checks	medium

Detections

Analytics

CVE-2025-38472

high

Tenable Plugins

Coming Soon

high

high

medium

medium