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

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4745-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     August 18, 2026                               https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux-6.12     Version        : 6.12.101-1~deb12u1     CVE ID         : CVE-2025-40098 CVE-2026-45897 CVE-2026-45901 CVE-2026-53078                      CVE-2026-53090 CVE-2026-64205 CVE-2026-64280 CVE-2026-64290                      CVE-2026-64561 CVE-2026-64562 CVE-2026-64563 CVE-2026-64564                      CVE-2026-64565 CVE-2026-64567 CVE-2026-64568 CVE-2026-64569                      CVE-2026-64570 CVE-2026-64571 CVE-2026-64572 CVE-2026-64573                      CVE-2026-64574 CVE-2026-64576 CVE-2026-64577 CVE-2026-64578                      CVE-2026-64579 CVE-2026-64580 CVE-2026-64583 CVE-2026-64584                      CVE-2026-68093 CVE-2026-68096 CVE-2026-68097 CVE-2026-68098                      CVE-2026-68099 CVE-2026-68100 CVE-2026-68102 CVE-2026-68104                      CVE-2026-68106 CVE-2026-68107 CVE-2026-68108 CVE-2026-68110                      CVE-2026-68111 CVE-2026-68112 CVE-2026-68113 CVE-2026-68115                      CVE-2026-68116 CVE-2026-68117 CVE-2026-68119 CVE-2026-68120                      CVE-2026-68121 CVE-2026-68123 CVE-2026-68124 CVE-2026-68125                      CVE-2026-68126 CVE-2026-68127 CVE-2026-68128 CVE-2026-68129                      CVE-2026-68130 CVE-2026-68131 CVE-2026-68133 CVE-2026-68135                      CVE-2026-68136 CVE-2026-68137 CVE-2026-68139 CVE-2026-68140                      CVE-2026-68141 CVE-2026-68142 CVE-2026-68143 CVE-2026-68144                      CVE-2026-68145 CVE-2026-68146 CVE-2026-68147 CVE-2026-68148                      CVE-2026-68149 CVE-2026-68151 CVE-2026-68152 CVE-2026-68153                      CVE-2026-68154 CVE-2026-68155 CVE-2026-68156 CVE-2026-68157                      CVE-2026-68158 CVE-2026-68160 CVE-2026-68161 CVE-2026-68162                      CVE-2026-68164 CVE-2026-68165 CVE-2026-68175 CVE-2026-68176                      CVE-2026-68178 CVE-2026-68179 CVE-2026-68180 CVE-2026-68181                      CVE-2026-68182 CVE-2026-68183 CVE-2026-68184 CVE-2026-68185                      CVE-2026-68186 CVE-2026-68187 CVE-2026-68188 CVE-2026-68189                      CVE-2026-68190 CVE-2026-68192 CVE-2026-68193 CVE-2026-68194                      CVE-2026-68195 CVE-2026-68196 CVE-2026-68197 CVE-2026-68199                      CVE-2026-68200 CVE-2026-68201 CVE-2026-68202 CVE-2026-68203                      CVE-2026-68204 CVE-2026-68205 CVE-2026-68206 CVE-2026-68207                      CVE-2026-68209 CVE-2026-68210 CVE-2026-68212 CVE-2026-68213                      CVE-2026-68214 CVE-2026-68215 CVE-2026-68216 CVE-2026-68217                      CVE-2026-68218 CVE-2026-68219 CVE-2026-68220 CVE-2026-68221                      CVE-2026-68222 CVE-2026-68223 CVE-2026-68225 CVE-2026-68226                      CVE-2026-68227 CVE-2026-68228 CVE-2026-68229 CVE-2026-68231                      CVE-2026-68234 CVE-2026-68235 CVE-2026-68236 CVE-2026-68243                      CVE-2026-68244 CVE-2026-68245 CVE-2026-68246 CVE-2026-68247                      CVE-2026-68248 CVE-2026-68249 CVE-2026-68250 CVE-2026-68251                      CVE-2026-68252 CVE-2026-68255 CVE-2026-68256 CVE-2026-68257                      CVE-2026-68259 CVE-2026-68260 CVE-2026-68261 CVE-2026-68262                      CVE-2026-68263 CVE-2026-68269 CVE-2026-68271 CVE-2026-68272                      CVE-2026-68277 CVE-2026-68278 CVE-2026-68279 CVE-2026-68280                      CVE-2026-68281 CVE-2026-68284 CVE-2026-68290 CVE-2026-68293                      CVE-2026-68294 CVE-2026-68296 CVE-2026-68297 CVE-2026-68299                      CVE-2026-68300 CVE-2026-68301 CVE-2026-68302 CVE-2026-68304                      CVE-2026-68306 CVE-2026-68307 CVE-2026-68308 CVE-2026-68309                      CVE-2026-68310 CVE-2026-68311 CVE-2026-68313 CVE-2026-68314                      CVE-2026-68315 CVE-2026-68317 CVE-2026-68318 CVE-2026-68319                      CVE-2026-68320 CVE-2026-68321 CVE-2026-68324 CVE-2026-68325                      CVE-2026-68326 CVE-2026-68327 CVE-2026-68328 CVE-2026-68329                      CVE-2026-68331 CVE-2026-68333 CVE-2026-68335 CVE-2026-68336                      CVE-2026-68338 CVE-2026-68339 CVE-2026-68340 CVE-2026-68343                      CVE-2026-68344 CVE-2026-68346 CVE-2026-68348 CVE-2026-68349                      CVE-2026-68350 CVE-2026-68351 CVE-2026-68352 CVE-2026-68353                      CVE-2026-68354 CVE-2026-68355 CVE-2026-68357 CVE-2026-68358                      CVE-2026-68359 CVE-2026-68360 CVE-2026-68361 CVE-2026-68362                      CVE-2026-68363 CVE-2026-68365 CVE-2026-68366 CVE-2026-68368                      CVE-2026-68369 CVE-2026-68370 CVE-2026-68371 CVE-2026-68372                      CVE-2026-68373 CVE-2026-68374 CVE-2026-68376 CVE-2026-68377                      CVE-2026-68381 CVE-2026-68385 CVE-2026-68386 CVE-2026-68388                      CVE-2026-68389 CVE-2026-68391 CVE-2026-68392 CVE-2026-68394                      CVE-2026-68395 CVE-2026-68396 CVE-2026-68397 CVE-2026-68398                      CVE-2026-68402 CVE-2026-68403 CVE-2026-68405 CVE-2026-68406                      CVE-2026-68407 CVE-2026-68408 CVE-2026-68410 CVE-2026-68411                      CVE-2026-68413 CVE-2026-68414 CVE-2026-68416 CVE-2026-68417                      CVE-2026-68419 CVE-2026-68422 CVE-2026-68425 CVE-2026-68427                      CVE-2026-68428 CVE-2026-68429 CVE-2026-68430 CVE-2026-68432                      CVE-2026-68433 CVE-2026-68434 CVE-2026-68437 CVE-2026-68439                      CVE-2026-68442 CVE-2026-68443 CVE-2026-68444 CVE-2026-68445                      CVE-2026-68446 CVE-2026-68449 CVE-2026-68450 CVE-2026-72015                      CVE-2026-72017 CVE-2026-72023 CVE-2026-72030 CVE-2026-72032                      CVE-2026-72040 CVE-2026-72045 CVE-2026-72046 CVE-2026-72051                      CVE-2026-72062 CVE-2026-72065 CVE-2026-72069 CVE-2026-72070                      CVE-2026-72101 CVE-2026-72103 CVE-2026-72113 CVE-2026-72114                      CVE-2026-72115 CVE-2026-72116 CVE-2026-72117 CVE-2026-72118                      CVE-2026-72119 CVE-2026-72121 CVE-2026-72124 CVE-2026-72125                      CVE-2026-72130 CVE-2026-72137 CVE-2026-72142 CVE-2026-72146                      CVE-2026-72147 CVE-2026-72168 CVE-2026-72175 CVE-2026-72183                      CVE-2026-72213 CVE-2026-72244 CVE-2026-72253 CVE-2026-72254                      CVE-2026-72260 CVE-2026-72299 CVE-2026-72305 CVE-2026-72372                      CVE-2026-74436     Debian Bug     : 1143721

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.  This update additionally includes many more bug fixes from     stable update 6.12.101.

    For Debian 12 bookworm, these problems have been fixed in version     6.12.101-1~deb12u1.

    We recommend that you upgrade your linux-6.12 packages.

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

    Further information about Debian LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS     Attachment:
    signature.asc     Description: PGP signature

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.

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 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	名称	产品	系列	发布时间	最近更新时间	严重程度
365767	Ubuntu 26.04 LTS : Linux kernel vulnerabilities (USN-8887-1)	Nessus	Ubuntu Local Security Checks	2026/10/14	2026/10/14	medium
337079	Debian dla-4745 : ata-modules-6.12.100+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	2026/8/18	2026/8/18	medium
365522	Ubuntu 24.04 LTS : Linux kernel vulnerabilities (USN-8917-1)	Nessus	Ubuntu Local Security Checks	2026/10/14	2026/10/14	medium
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	2026/9/30	2026/9/30	high
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	2026/9/30	2026/9/30	high
365463	Ubuntu 26.04 LTS : Linux kernel (OEM) vulnerabilities (USN-8889-1)	Nessus	Ubuntu Local Security Checks	2026/10/13	2026/10/13	medium
347900	SUSE SLED15 / SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:4254-1)	Nessus	SuSE Local Security Checks	2026/9/18	2026/9/29	high

检测

插件搜索

medium

medium

medium

high

high

medium

high