The AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1787305050 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount     underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops     to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel     is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which     leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped.
    Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls     l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to     l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is     possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet     have session->tunnel set. Add a check for this case. (CVE-2024-49940)

  - In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue     naming and locking Recent changes are putting more pressure on THP deferred split queues: under load     revealing long-standing races, causing list_del corruptions, Bad page states and worse (I keep BUGs in     both of those, so usually don't get to see how badly they end up without). The relevant recent changes     being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP     splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo     large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line
    __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and     return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around     safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the     folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and     if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer     has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting     folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is     unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been     unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting     the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling     folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5     (mm: thp: make deferred split shrinker memcg aware): which included a check on swapcache before adding     to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with     the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on     deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (mm: split underused THPs)     avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep     the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the     existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the     queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated):
    mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio     from the deferred list, sometimes corrupting from memcg's list, like swapout. Refcount is non-zero here,     so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be     done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course     unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged     should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The     87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of     its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (mm: thp: don't need     care deferred split queue in memcg charge move path), which argued that the existence of a PMD mapping     guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly     false. Backport to 6.11 should be straightforward. Earlier backports must take care that other
    _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can     fix cornercases. (CVE-2024-53079)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: reallocate buf lists on     upgrade IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy     selected buffer and has been emptied. It violates the requirement that most of the field should stay     stable after publish. Always reallocate it instead. (CVE-2025-21836)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add sanity checks on     rdev validity There is a possibility that ulp_irq_stop and ulp_irq_start callbacks will be called when the     device is in detached state. This can cause a crash due to NULL pointer dereference as the rdev is already     freed. (CVE-2025-21901)

  - In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: Add missing NULL     ptr check in amd_pstate_update Check if policy is NULL before dereferencing it in amd_pstate_update.
    (CVE-2025-23137)

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.

  - wifi: iwlwifi: mvm: don't send a 6E related command when not supported MCC_ALLOWED_AP_TYPE_CMD is related     to 6E support. Do not send it if the device doesn't support 6E. Apparently, the firmware is mistakenly     advertising support for this command even on AX201 which does not support 6E and then the firmware     crashes. (CVE-2026-43325)

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

The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1787305050 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount     underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops     to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel     is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which     leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped.
    Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls     l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to     l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is     possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet     have session->tunnel set. Add a check for this case. (CVE-2024-49940)

  - In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue     naming and locking Recent changes are putting more pressure on THP deferred split queues: under load     revealing long-standing races, causing list_del corruptions, Bad page states and worse (I keep BUGs in     both of those, so usually don't get to see how badly they end up without). The relevant recent changes     being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP     splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo     large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line
    __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and     return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around     safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the     folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and     if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer     has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting     folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is     unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been     unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting     the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling     folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5     (mm: thp: make deferred split shrinker memcg aware): which included a check on swapcache before adding     to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with     the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on     deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (mm: split underused THPs)     avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep     the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the     existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the     queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated):
    mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio     from the deferred list, sometimes corrupting from memcg's list, like swapout. Refcount is non-zero here,     so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be     done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course     unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged     should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The     87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of     its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (mm: thp: don't need     care deferred split queue in memcg charge move path), which argued that the existence of a PMD mapping     guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly     false. Backport to 6.11 should be straightforward. Earlier backports must take care that other
    _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can     fix cornercases. (CVE-2024-53079)

  - In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: reallocate buf lists on     upgrade IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy     selected buffer and has been emptied. It violates the requirement that most of the field should stay     stable after publish. Always reallocate it instead. (CVE-2025-21836)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add sanity checks on     rdev validity There is a possibility that ulp_irq_stop and ulp_irq_start callbacks will be called when the     device is in detached state. This can cause a crash due to NULL pointer dereference as the rdev is already     freed. (CVE-2025-21901)

  - In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: Add missing NULL     ptr check in amd_pstate_update Check if policy is NULL before dereferencing it in amd_pstate_update.
    (CVE-2025-23137)

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	Published	Updated	Severity
320429	openSUSE 16 Security Update : kernel (openSUSE-SU-2026:20912-1)	Nessus	SuSE Local Security Checks	6/11/2026	8/26/2026	medium
323086	SUSE SLED15 / SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:2482-1)	Nessus	SuSE Local Security Checks	6/26/2026	9/29/2026	high
352220	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1787305050)	Nessus	Alma Linux Local Security Checks	9/30/2026	9/30/2026	high
313327	Linux Distros Unpatched Vulnerability : CVE-2026-43325	Nessus	Misc.	5/8/2026	11/2/2026	medium
352240	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1787305050)	Nessus	Rocky Linux Local Security Checks	9/30/2026	9/30/2026	high

Detections

Analytics

Plugins Search

medium

high

high

medium

high