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

  - In the Linux kernel, the following vulnerability has been resolved: kunit: Fix potential null dereference     in kunit_device_driver_test() kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL     check may lead to NULL dereference. Add a NULL check for test_state. (CVE-2024-56773)

  - In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: fix partial SETREGSET     for NT_ARM_FPMR Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable, and a SETREGSET     call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written     back to target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from the kernel stack. The     read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. Fix     this by initializing the temporary value before copying the regset from userspace, as for other regsets     (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing     contents of FPMR will be retained. Before this patch: | # ./fpmr-test | Attempting to write     NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read     NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d     | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | |     Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr =     0xffff800083963d50 After this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr =     0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr |     GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to     write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read     NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d     (CVE-2024-57878)

  - In the Linux kernel, the following vulnerability has been resolved: mptcp: fix 'scheduling while atomic'     in mptcp_pm_nl_append_new_local_addr If multiple connection requests attempt to create an implicit mptcp     endpoint in parallel, more than one caller may end up in mptcp_pm_nl_append_new_local_addr because none     found the address in local_addr_list during their call to mptcp_pm_nl_get_local_id. In this case, the     concurrent new_local_addr calls may delete the address entry created by the previous caller. These deletes     use synchronize_rcu, but this is not permitted in some of the contexts where this function may be called.
    During packet recv, the caller may be in a rcu read critical section and have preemption disabled. An     example stack: BUG: scheduling while atomic: swapper/2/0/0x00000302 Call Trace: <IRQ> dump_stack_lvl     (lib/dump_stack.c:117 (discriminator 1)) dump_stack (lib/dump_stack.c:124) __schedule_bug     (kernel/sched/core.c:5943) schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33     kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207     kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84     kernel/sched/core.c:6804 kernel/sched/core.c:6818) schedule_timeout (kernel/time/timer.c:2160)     wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116     kernel/sched/completion.c:127 kernel/sched/completion.c:148) __wait_rcu_gp (include/linux/rcupdate.h:311     kernel/rcu/update.c:444) synchronize_rcu (kernel/rcu/tree.c:3609) mptcp_pm_nl_append_new_local_addr     (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id     (net/mptcp/pm_netlink.c:1164) mptcp_pm_get_local_id (net/mptcp/pm.c:420) subflow_check_req     (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflow_v4_route_req (net/mptcp/subflow.c:305)     tcp_conn_request (net/ipv4/tcp_input.c:7216) subflow_v4_conn_request (net/mptcp/subflow.c:651)     tcp_rcv_state_process (net/ipv4/tcp_input.c:6709) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934) tcp_v4_rcv     (net/ipv4/tcp_ipv4.c:2334) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))     ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver     (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)     ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580) ip_sublist_rcv     (net/ipv4/ip_input.c:640) ip_list_rcv (net/ipv4/ip_input.c:675) __netif_receive_skb_list_core     (net/core/dev.c:5583 net/core/dev.c:5631) netif_receive_skb_list_internal (net/core/dev.c:5685     net/core/dev.c:5774) napi_complete_done (include/linux/list.h:37 include/net/gro.h:449     include/net/gro.h:444 net/core/dev.c:6114) igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
    __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787) handle_softirqs     (kernel/softirq.c:553) __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)     irq_exit_rcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ>     This problem seems particularly prevalent if the user advertises an endpoint that has a different external     vs internal address. In the case where the external address is advertised and multiple connections already     exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the     first local_addr_list entries which have the internal address instead. Fix by skipping the replacement of     an existing implicit local address if called via mptcp_pm_nl_get_local_id. (CVE-2025-21938)

  - In the Linux kernel, the following vulnerability has been resolved: devlink: fix xa_alloc_cyclic() error     handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will     cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking     if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
    (CVE-2025-22017)

  - In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path     of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence     and then return. The code is waiting on m->fence which could be the local fence but this is only stable     under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit     762b7e95362170b3e13a8704f38d5e47eca4ba74) (CVE-2025-37869)

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.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1789898700 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: ceph: fix possible deadlock when     holding Fwb to get inline_data 1, mount with wsync. 2, create a file with O_RDWR, and the request was sent     to mds.0: ceph_atomic_open()--> ceph_mdsc_do_request(openc) finish_open(file, dentry, ceph_open)-->     ceph_open()--> ceph_init_file()--> ceph_init_file_info()--> ceph_uninline_data()--> { ... if     (inline_version == 1 || /* initial version, no data */ inline_version == CEPH_INLINE_NONE) goto     out_unlock; ... } The inline_version will be 1, which is the initial version for the new create file. And     here the ci->i_inline_version will keep with 1, it's buggy. 3, buffer write to the file immediately:
    ceph_write_iter()--> ceph_get_caps(file, need=Fw, want=Fb, ...); generic_perform_write()-->     a_ops->write_begin()--> ceph_write_begin()--> netfs_write_begin()--> netfs_begin_read()-->     netfs_rreq_submit_slice()--> netfs_read_from_server()--> rreq->netfs_ops->issue_read()-->     ceph_netfs_issue_read()--> { ... if (ci->i_inline_version != CEPH_INLINE_NONE &&     ceph_netfs_issue_op_inline(subreq)) return; ... } ceph_put_cap_refs(ci, Fwb); The     ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to mds.1. 4, then the mds.1 will request the     rd lock for CInode::filelock from the auth mds.0, the mds.0 will do the CInode::filelock state transation     from excl --> sync, but it need to revoke the Fxwb caps back from the clients. While the kernel client has     aleady held the Fwb caps and waiting for the getattr(Fsr). It's deadlock! URL:
    https://tracker.ceph.com/issues/55377 (CVE-2022-49296)

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Fix reading strings from     synthetic events The follow commands caused a crash: # cd /sys/kernel/tracing # echo 's:open char file[]'     > dynamic_events # echo 'hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)' >     events/syscalls/sys_enter_openat/trigger' # echo 1 > events/synthetic/open/enable BOOM! The problem is     that the synthetic event field char file[] will read the value given to it as a string without any     memory checks to make sure the address is valid. The above example will pass in the user space address and     the sythetic event code will happily call strlen() on it and then strscpy() where either one will cause an     oops when accessing user space addresses. Use the helper functions from trace_kprobe and trace_eprobe that     can read strings safely (and actually succeed when the address is from user space and the memory is mapped     in). Now the above can show: packagekitd-1721 [000] ...2. 104.597170: open:
    file=/usr/lib/rpm/fileattrs/cmake.attr in:imjournal-978 [006] ...2. 104.599642: open:
    file=/var/lib/rsyslog/imjournal.state.tmp packagekitd-1721 [000] ...2. 104.626308: open:
    file=/usr/lib/rpm/fileattrs/debuginfo.attr (CVE-2022-50255)

  - In the Linux kernel, the following vulnerability has been resolved: hwrng: core - Fix page fault dead lock     on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads     from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive     read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user. (CVE-2023-52615)

  - In the Linux kernel, the following vulnerability has been resolved: fscache: Use wait_on_bit() to wait for     the freeing of relinquished volume The freeing of relinquished volume will wake up the pending volume     acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in     fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these     two functions operate on different wait-queues. According to the implementation in     fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20     seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout     and the following wait_var_event() will hang forever as shown below: FS-Cache: Potential volume collision     new=00000024 old=00000022 ...... INFO: task mount:1148 blocked for more than 122 seconds. Not tainted     6.1.0-rc6+ #1 task:mount state:D stack:0 pid:1148 ppid:1 Call Trace: <TASK> __schedule+0x2f6/0xb80     schedule+0x67/0xe0 fscache_wait_on_volume_collision.cold+0x80/0x82 __fscache_acquire_volume+0x40d/0x4e0     erofs_fscache_register_volume+0x51/0xe0 [erofs] erofs_fscache_register_fs+0x19c/0x240 [erofs]     erofs_fc_fill_super+0x746/0xaf0 [erofs] vfs_get_super+0x7d/0x100 get_tree_nodev+0x16/0x20     erofs_fc_get_tree+0x20/0x30 [erofs] vfs_get_tree+0x24/0xb0 path_mount+0x2fa/0xa90 do_mount+0x7c/0xa0
    __x64_sys_mount+0x8b/0xe0 do_syscall_64+0x30/0x60 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Considering     that wake_up_bit() is more selective, so fix it by using wait_on_bit() instead of wait_var_event() to wait     for the freeing of relinquished volume. In addition because waitqueue_active() is used in wake_up_bit()     and clear_bit() doesn't imply any memory barrier, use clear_and_wake_up_bit() to add the missing memory     barrier between cursor->flags and waitqueue_active(). (CVE-2023-52982)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: fix iso_conn related     locking and validity issues sk->sk_state indicates whether iso_pi(sk)->conn is valid. Operations that     check/update sk_state and access conn should hold lock_sock, otherwise they can race. The order of taking     locks is hci_dev_lock > lock_sock > iso_conn_lock, which is how it is in connect/disconnect_cfm ->     iso_conn_del -> iso_chan_del. Fix locking in iso_connect_cis/bis and sendmsg/recvmsg to take lock_sock     around updating sk_state and conn. iso_conn_del must not occur during iso_connect_cis/bis, as it frees the     iso_conn. Hold hdev->lock longer to prevent that. This should not reintroduce the issue fixed in commit     241f51931c35 (Bluetooth: ISO: Avoid circular locking dependency), since the we acquire locks in order.
    We retain the fix in iso_sock_connect to release lock_sock before iso_connect_* acquires hdev->lock.
    Similarly for commit 6a5ad251b7cd (Bluetooth: ISO: Fix possible circular locking dependency). We retain     the fix in iso_conn_ready to not acquire iso_conn_lock before lock_sock. iso_conn_add shall return     iso_conn with valid hcon. Make it so also when reusing an old CIS connection waiting for disconnect     timeout (see __iso_sock_close where conn->hcon is set to NULL). Trace with iso_conn_del after iso_chan_add     in iso_connect_cis: =============================================================== iso_sock_create:771:
    sock 00000000be9b69b7 iso_sock_init:693: sk 000000004dff667e iso_sock_bind:827: sk 000000004dff667e     70:1a:b8:98:ff:a2 type 1 iso_sock_setsockopt:1289: sk 000000004dff667e iso_sock_setsockopt:1289: sk     000000004dff667e iso_sock_setsockopt:1289: sk 000000004dff667e iso_sock_connect:875: sk 000000004dff667e     iso_connect_cis:353: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da hci_get_route:1199: 70:1a:b8:98:ff:a2 ->     28:3d:c2:4a:7e:da hci_conn_add:1005: hci0 dst 28:3d:c2:4a:7e:da iso_conn_add:140: hcon 000000007b65d182     conn 00000000daf8625e __iso_chan_add:214: conn 00000000daf8625e iso_connect_cfm:1700: hcon     000000007b65d182 bdaddr 28:3d:c2:4a:7e:da status 12 iso_conn_del:187: hcon 000000007b65d182 conn     00000000daf8625e, err 16 iso_sock_clear_timer:117: sock 000000004dff667e state 3 <Note: sk_state is     BT_BOUND (3), so iso_connect_cis is still running at this point> iso_chan_del:153: sk 000000004dff667e,     conn 00000000daf8625e, err 16 hci_conn_del:1151: hci0 hcon 000000007b65d182 handle 65535     hci_conn_unlink:1102: hci0: hcon 000000007b65d182 hci_chan_list_flush:2780: hcon 000000007b65d182     iso_sock_getsockopt:1376: sk 000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk     000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e     iso_sock_getsockopt:1376: sk 000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk     000000004dff667e iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e iso_sock_shutdown:1434:
    sock 00000000be9b69b7, sk 000000004dff667e, how 1 __iso_sock_close:632: sk 000000004dff667e state 5 socket     00000000be9b69b7 <Note: sk_state is BT_CONNECT (5), even though iso_chan_del sets BT_CLOSED (6). Only     iso_connect_cis sets it to BT_CONNECT, so it must be that iso_chan_del occurred between iso_chan_add and     end of iso_connect_cis.> BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD     8000000006467067 P4D 8000000006467067 PUD 3f5f067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name:
    QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 RIP: 0010:__iso_sock_close     (net/bluetooth/iso.c:664) bluetooth =============================================================== Trace     with iso_conn_del before iso_chan_add in iso_connect_cis:
    =============================================================== iso_connect_cis:356: 70:1a:b8:98:ff:a2 ->     28:3d:c2:4a:7e:da ... iso_conn_add:140: hcon 0000000093bc551f conn 00000000768ae504 hci_dev_put:1487: hci0     orig refcnt 21 hci_event_packet:7607: hci0: e ---truncated--- (CVE-2023-54164)

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 remote Debian 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4788 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4788-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     September 19, 2026                            https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux-6.12     Version        : 6.12.107-1~deb12u1     CVE ID         : CVE-2025-38525 CVE-2025-40054 CVE-2025-40074 CVE-2026-43197                      CVE-2026-53092 CVE-2026-64017 CVE-2026-64216 CVE-2026-64581                      CVE-2026-64586 CVE-2026-68082 CVE-2026-68118 CVE-2026-68132                      CVE-2026-68138 CVE-2026-68159 CVE-2026-68166 CVE-2026-68169                      CVE-2026-68198 CVE-2026-68253 CVE-2026-68254 CVE-2026-68264                      CVE-2026-68266 CVE-2026-68267 CVE-2026-68273 CVE-2026-68276                      CVE-2026-68322 CVE-2026-68367 CVE-2026-68431 CVE-2026-68451                      CVE-2026-68452 CVE-2026-68480 CVE-2026-72111 CVE-2026-74440                      CVE-2026-74441 CVE-2026-74442 CVE-2026-74443 CVE-2026-74444                      CVE-2026-74445 CVE-2026-74446 CVE-2026-74447 CVE-2026-74448                      CVE-2026-74450 CVE-2026-74451 CVE-2026-74452 CVE-2026-74453                      CVE-2026-74454 CVE-2026-74455 CVE-2026-74456 CVE-2026-74457                      CVE-2026-74458 CVE-2026-74459 CVE-2026-74460 CVE-2026-74461                      CVE-2026-74463 CVE-2026-74464 CVE-2026-74465 CVE-2026-74467                      CVE-2026-74468 CVE-2026-74469 CVE-2026-74470 CVE-2026-74471                      CVE-2026-74472 CVE-2026-74473 CVE-2026-74474 CVE-2026-74475                      CVE-2026-74476 CVE-2026-74478 CVE-2026-74479 CVE-2026-74480                      CVE-2026-74481 CVE-2026-74482 CVE-2026-74483 CVE-2026-74484                      CVE-2026-74485 CVE-2026-74487 CVE-2026-74488 CVE-2026-74490                      CVE-2026-74492 CVE-2026-74493 CVE-2026-74494 CVE-2026-74495                      CVE-2026-74497 CVE-2026-74498 CVE-2026-74499 CVE-2026-74500                      CVE-2026-74501 CVE-2026-74502 CVE-2026-74503 CVE-2026-74504                      CVE-2026-74505 CVE-2026-74507 CVE-2026-74508 CVE-2026-74509                      CVE-2026-74510 CVE-2026-74512 CVE-2026-74514 CVE-2026-74515                      CVE-2026-74516 CVE-2026-74517 CVE-2026-74518 CVE-2026-74519                      CVE-2026-74522 CVE-2026-74523 CVE-2026-74524 CVE-2026-74525                      CVE-2026-74531 CVE-2026-74532 CVE-2026-74535 CVE-2026-74536                      CVE-2026-74540 CVE-2026-74541 CVE-2026-74543 CVE-2026-74545                      CVE-2026-74546 CVE-2026-74547 CVE-2026-74548 CVE-2026-74549                      CVE-2026-74550 CVE-2026-74551 CVE-2026-74552 CVE-2026-74553                      CVE-2026-74555 CVE-2026-74556 CVE-2026-74557 CVE-2026-74563                      CVE-2026-74564 CVE-2026-74565 CVE-2026-74566 CVE-2026-74567                      CVE-2026-74569 CVE-2026-74572 CVE-2026-74574 CVE-2026-74575                      CVE-2026-74576 CVE-2026-74577 CVE-2026-74579 CVE-2026-74580                      CVE-2026-74581 CVE-2026-74582 CVE-2026-74583 CVE-2026-74585                      CVE-2026-74586 CVE-2026-74587 CVE-2026-74588 CVE-2026-74589                      CVE-2026-74590 CVE-2026-74592 CVE-2026-74594 CVE-2026-74595                      CVE-2026-74597 CVE-2026-74598 CVE-2026-74599 CVE-2026-74601                      CVE-2026-74602 CVE-2026-74603 CVE-2026-74604 CVE-2026-74606                      CVE-2026-74607 CVE-2026-74608 CVE-2026-74609 CVE-2026-74610                      CVE-2026-74612 CVE-2026-74613 CVE-2026-74614 CVE-2026-74615                      CVE-2026-74616 CVE-2026-74618 CVE-2026-74619 CVE-2026-74620                      CVE-2026-74621 CVE-2026-74622 CVE-2026-74623 CVE-2026-74624                      CVE-2026-74625 CVE-2026-74626 CVE-2026-74628 CVE-2026-74630                      CVE-2026-74631 CVE-2026-74632 CVE-2026-74634 CVE-2026-74635                      CVE-2026-74636 CVE-2026-74637 CVE-2026-74641 CVE-2026-74644                      CVE-2026-74646 CVE-2026-74647 CVE-2026-74648 CVE-2026-74649                      CVE-2026-74650 CVE-2026-74651 CVE-2026-74653 CVE-2026-74654                      CVE-2026-74655 CVE-2026-74656 CVE-2026-74657 CVE-2026-74658                      CVE-2026-74659 CVE-2026-74660 CVE-2026-74661 CVE-2026-74662                      CVE-2026-74663 CVE-2026-74664 CVE-2026-74665 CVE-2026-74666                      CVE-2026-74667 CVE-2026-74668 CVE-2026-74669 CVE-2026-74670                      CVE-2026-74671 CVE-2026-74672 CVE-2026-74673 CVE-2026-74675                      CVE-2026-74676 CVE-2026-74677 CVE-2026-74678 CVE-2026-74679                      CVE-2026-74680 CVE-2026-74682 CVE-2026-74683 CVE-2026-74684                      CVE-2026-74685 CVE-2026-74688 CVE-2026-74689 CVE-2026-74691                      CVE-2026-74692 CVE-2026-74693 CVE-2026-74694 CVE-2026-74696                      CVE-2026-74700 CVE-2026-74701 CVE-2026-74704 CVE-2026-74705                      CVE-2026-74710 CVE-2026-74712 CVE-2026-74714 CVE-2026-74717                      CVE-2026-74718 CVE-2026-74719 CVE-2026-74720 CVE-2026-74722                      CVE-2026-74724 CVE-2026-74725 CVE-2026-74726 CVE-2026-74730                      CVE-2026-74732 CVE-2026-74736 CVE-2026-74737 CVE-2026-74739                      CVE-2026-74740 CVE-2026-74742 CVE-2026-74743 CVE-2026-74744                      CVE-2026-74746 CVE-2026-74748 CVE-2026-80522 CVE-2026-80525                      CVE-2026-80526 CVE-2026-80527 CVE-2026-80528 CVE-2026-80529                      CVE-2026-80530 CVE-2026-80531 CVE-2026-80532 CVE-2026-80533                      CVE-2026-80534 CVE-2026-80535 CVE-2026-80536 CVE-2026-80539                      CVE-2026-80540 CVE-2026-80541 CVE-2026-80547 CVE-2026-80548                      CVE-2026-80549 CVE-2026-80550 CVE-2026-80551 CVE-2026-80552                      CVE-2026-80553 CVE-2026-80554 CVE-2026-80555 CVE-2026-80556                      CVE-2026-80557 CVE-2026-80558 CVE-2026-80559 CVE-2026-80560                      CVE-2026-80561 CVE-2026-80562 CVE-2026-80563 CVE-2026-80565                      CVE-2026-80566 CVE-2026-80567 CVE-2026-80568 CVE-2026-80569                      CVE-2026-80570 CVE-2026-80572 CVE-2026-80573 CVE-2026-80574                      CVE-2026-80575 CVE-2026-80576 CVE-2026-80577 CVE-2026-80578                      CVE-2026-80583 CVE-2026-80584 CVE-2026-80585 CVE-2026-80586                      CVE-2026-80587 CVE-2026-80589 CVE-2026-80590 CVE-2026-80678                      CVE-2026-80679 CVE-2026-80680 CVE-2026-80681 CVE-2026-80684                      CVE-2026-80686 CVE-2026-80689 CVE-2026-80691 CVE-2026-80694                      CVE-2026-80695 CVE-2026-80696 CVE-2026-80700 CVE-2026-80702                      CVE-2026-80703 CVE-2026-80704 CVE-2026-80706 CVE-2026-80707                      CVE-2026-80708 CVE-2026-80709 CVE-2026-80710 CVE-2026-80711                      CVE-2026-80714 CVE-2026-80715 CVE-2026-80716 CVE-2026-80717                      CVE-2026-80718 CVE-2026-80722 CVE-2026-80723 CVE-2026-80725                      CVE-2026-80726 CVE-2026-80727 CVE-2026-80728 CVE-2026-80730                      CVE-2026-80731 CVE-2026-80732 CVE-2026-80733 CVE-2026-80736                      CVE-2026-80737 CVE-2026-80739 CVE-2026-80742 CVE-2026-80743                      CVE-2026-80744 CVE-2026-80749 CVE-2026-80752 CVE-2026-80754                      CVE-2026-80756 CVE-2026-80757 CVE-2026-80759 CVE-2026-80763                      CVE-2026-80764 CVE-2026-80765 CVE-2026-80767 CVE-2026-80770                      CVE-2026-80771 CVE-2026-80772 CVE-2026-80779 CVE-2026-80781                      CVE-2026-80782 CVE-2026-80784 CVE-2026-80788 CVE-2026-80789                      CVE-2026-80790 CVE-2026-80791 CVE-2026-80792 CVE-2026-80793                      CVE-2026-80794 CVE-2026-80795 CVE-2026-80797 CVE-2026-80798                      CVE-2026-80799 CVE-2026-80800 CVE-2026-80801 CVE-2026-80802                      CVE-2026-80803 CVE-2026-80805 CVE-2026-80808 CVE-2026-80809                      CVE-2026-80812 CVE-2026-80814 CVE-2026-80815 CVE-2026-80819                      CVE-2026-80820 CVE-2026-80823 CVE-2026-80887 CVE-2026-80888                      CVE-2026-80889 CVE-2026-80890 CVE-2026-80891 CVE-2026-80892                      CVE-2026-80893 CVE-2026-80894 CVE-2026-80901 CVE-2026-80902                      CVE-2026-80903 CVE-2026-80904 CVE-2026-80906 CVE-2026-80907                      CVE-2026-80908 CVE-2026-80909 CVE-2026-80910 CVE-2026-80911                      CVE-2026-80912 CVE-2026-80913 CVE-2026-80915 CVE-2026-80916                      CVE-2026-80917 CVE-2026-80918     Debian Bug     : 1142912 1143545

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

    For Debian 12 bookworm, these problems have been fixed in version     6.12.107-1~deb12u1.  This update additionally includes many more bug     fixes from stable updates 6.12.102-6.12.107, and adds drivers for     Alcor card readers.

    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 remote Debian 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4777 advisory.

    - -------------------------------------------------------------------------     Debian LTS Advisory DLA-4777-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                 Salvatore Bonaccorso     September 08, 2026                            https://wiki.debian.org/LTS
    - -------------------------------------------------------------------------

    Package        : linux     Version        : 6.1.187-1     CVE ID         : CVE-2023-53706 CVE-2023-54141 CVE-2023-54263 CVE-2024-38620                      CVE-2024-46754 CVE-2024-58094 CVE-2024-58095 CVE-2025-22104                      CVE-2025-38117 CVE-2025-38203 CVE-2025-38206 CVE-2025-38237                      CVE-2025-38616 CVE-2025-39833 CVE-2025-39901 CVE-2025-39925                      CVE-2025-40054 CVE-2025-40064 CVE-2025-40102 CVE-2025-40139                      CVE-2025-40168 CVE-2025-40206 CVE-2025-40307 CVE-2025-68794                      CVE-2026-23394 CVE-2026-31419 CVE-2026-43491 CVE-2026-45963                      CVE-2026-46111 CVE-2026-46158 CVE-2026-46170 CVE-2026-46266                      CVE-2026-53089 CVE-2026-53090 CVE-2026-53361 CVE-2026-64082                      CVE-2026-64139 CVE-2026-64192 CVE-2026-64270 CVE-2026-64272                      CVE-2026-64280 CVE-2026-64294 CVE-2026-64434 CVE-2026-64507                      CVE-2026-64508 CVE-2026-64542 CVE-2026-64543 CVE-2026-64561                      CVE-2026-64562 CVE-2026-64563 CVE-2026-64564 CVE-2026-64565                      CVE-2026-64567 CVE-2026-64569 CVE-2026-64571 CVE-2026-64572                      CVE-2026-64573 CVE-2026-64576 CVE-2026-64577 CVE-2026-64578                      CVE-2026-64579 CVE-2026-64580 CVE-2026-64581 CVE-2026-64582                      CVE-2026-64583 CVE-2026-64584 CVE-2026-64586 CVE-2026-64590                      CVE-2026-68082 CVE-2026-68093 CVE-2026-68096 CVE-2026-68099                      CVE-2026-68100 CVE-2026-68104 CVE-2026-68106 CVE-2026-68108                      CVE-2026-68111 CVE-2026-68115 CVE-2026-68117 CVE-2026-68121                      CVE-2026-68123 CVE-2026-68124 CVE-2026-68125 CVE-2026-68127                      CVE-2026-68129 CVE-2026-68130 CVE-2026-68131 CVE-2026-68132                      CVE-2026-68135 CVE-2026-68136 CVE-2026-68137 CVE-2026-68138                      CVE-2026-68140 CVE-2026-68141 CVE-2026-68142 CVE-2026-68143                      CVE-2026-68144 CVE-2026-68146 CVE-2026-68147 CVE-2026-68148                      CVE-2026-68151 CVE-2026-68153 CVE-2026-68154 CVE-2026-68155                      CVE-2026-68156 CVE-2026-68157 CVE-2026-68158 CVE-2026-68159                      CVE-2026-68160 CVE-2026-68162 CVE-2026-68164 CVE-2026-68165                      CVE-2026-68169 CVE-2026-68175 CVE-2026-68176 CVE-2026-68180                      CVE-2026-68181 CVE-2026-68182 CVE-2026-68183 CVE-2026-68184                      CVE-2026-68186 CVE-2026-68187 CVE-2026-68188 CVE-2026-68189                      CVE-2026-68190 CVE-2026-68192 CVE-2026-68194 CVE-2026-68195                      CVE-2026-68196 CVE-2026-68197 CVE-2026-68198 CVE-2026-68199                      CVE-2026-68202 CVE-2026-68204 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-68222 CVE-2026-68223 CVE-2026-68226                      CVE-2026-68227 CVE-2026-68229 CVE-2026-68231 CVE-2026-68234                      CVE-2026-68243 CVE-2026-68244 CVE-2026-68246 CVE-2026-68248                      CVE-2026-68249 CVE-2026-68250 CVE-2026-68251 CVE-2026-68253                      CVE-2026-68254 CVE-2026-68255 CVE-2026-68259 CVE-2026-68269                      CVE-2026-68277 CVE-2026-68278 CVE-2026-68279 CVE-2026-68280                      CVE-2026-68284 CVE-2026-68294 CVE-2026-68297 CVE-2026-68299                      CVE-2026-68300 CVE-2026-68301 CVE-2026-68302 CVE-2026-68304                      CVE-2026-68309 CVE-2026-68310 CVE-2026-68313 CVE-2026-68315                      CVE-2026-68320 CVE-2026-68322 CVE-2026-68324 CVE-2026-68325                      CVE-2026-68326 CVE-2026-68327 CVE-2026-68328 CVE-2026-68331                      CVE-2026-68333 CVE-2026-68335 CVE-2026-68336 CVE-2026-68338                      CVE-2026-68340 CVE-2026-68343 CVE-2026-68344 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-68359                      CVE-2026-68360 CVE-2026-68361 CVE-2026-68362 CVE-2026-68363                      CVE-2026-68365 CVE-2026-68366 CVE-2026-68367 CVE-2026-68368                      CVE-2026-68369 CVE-2026-68370 CVE-2026-68371 CVE-2026-68373                      CVE-2026-68376 CVE-2026-68377 CVE-2026-68386 CVE-2026-68388                      CVE-2026-68395 CVE-2026-68397 CVE-2026-68398 CVE-2026-68402                      CVE-2026-68403 CVE-2026-68405 CVE-2026-68406 CVE-2026-68407                      CVE-2026-68410 CVE-2026-68411 CVE-2026-68413 CVE-2026-68414                      CVE-2026-68417 CVE-2026-68422 CVE-2026-68425 CVE-2026-68427                      CVE-2026-68428 CVE-2026-68430 CVE-2026-68431 CVE-2026-68432                      CVE-2026-68433 CVE-2026-68434 CVE-2026-68444 CVE-2026-68446                      CVE-2026-68450 CVE-2026-68451 CVE-2026-68452 CVE-2026-68476                      CVE-2026-68480 CVE-2026-72012 CVE-2026-72015 CVE-2026-72017                      CVE-2026-72023 CVE-2026-72030 CVE-2026-72035 CVE-2026-72040                      CVE-2026-72041 CVE-2026-72045 CVE-2026-72051 CVE-2026-72057                      CVE-2026-72062 CVE-2026-72063 CVE-2026-72065 CVE-2026-72069                      CVE-2026-72070 CVE-2026-72077 CVE-2026-72096 CVE-2026-72099                      CVE-2026-72110 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-72142                      CVE-2026-72146 CVE-2026-72157 CVE-2026-72170 CVE-2026-72172                      CVE-2026-72191 CVE-2026-72216 CVE-2026-72236 CVE-2026-72237                      CVE-2026-72242 CVE-2026-72252 CVE-2026-72253 CVE-2026-72260                      CVE-2026-72262 CVE-2026-72299 CVE-2026-72305 CVE-2026-72308                      CVE-2026-72323 CVE-2026-72392 CVE-2026-74436 CVE-2026-74441                      CVE-2026-74443 CVE-2026-74444 CVE-2026-74446 CVE-2026-74450                      CVE-2026-74453 CVE-2026-74454 CVE-2026-74455 CVE-2026-74456                      CVE-2026-74457 CVE-2026-74458 CVE-2026-74459 CVE-2026-74460                      CVE-2026-74461 CVE-2026-74463 CVE-2026-74464 CVE-2026-74465                      CVE-2026-74467 CVE-2026-74468 CVE-2026-74469 CVE-2026-74470                      CVE-2026-74471 CVE-2026-74472 CVE-2026-74473 CVE-2026-74475                      CVE-2026-74476 CVE-2026-74478 CVE-2026-74479 CVE-2026-74480                      CVE-2026-74481 CVE-2026-74482 CVE-2026-74485 CVE-2026-74487                      CVE-2026-74488 CVE-2026-74490 CVE-2026-74492 CVE-2026-74493                      CVE-2026-74494 CVE-2026-74495 CVE-2026-74497 CVE-2026-74498                      CVE-2026-74499 CVE-2026-74505 CVE-2026-74507 CVE-2026-74508                      CVE-2026-74509 CVE-2026-74510 CVE-2026-74512 CVE-2026-74514                      CVE-2026-74515 CVE-2026-74516 CVE-2026-74518 CVE-2026-74519                      CVE-2026-74522 CVE-2026-74523 CVE-2026-74525 CVE-2026-74540                      CVE-2026-74546 CVE-2026-74547 CVE-2026-74548 CVE-2026-74549                      CVE-2026-74550 CVE-2026-74551 CVE-2026-74552 CVE-2026-74553                      CVE-2026-74555 CVE-2026-74556 CVE-2026-74557 CVE-2026-74563                      CVE-2026-74564 CVE-2026-74566 CVE-2026-74567 CVE-2026-74569                      CVE-2026-74575 CVE-2026-74577 CVE-2026-74579 CVE-2026-74580                      CVE-2026-74581 CVE-2026-74582 CVE-2026-74583 CVE-2026-74585                      CVE-2026-74586 CVE-2026-74587 CVE-2026-74588 CVE-2026-74589                      CVE-2026-74594 CVE-2026-74595 CVE-2026-74597 CVE-2026-74598                      CVE-2026-74601 CVE-2026-74603 CVE-2026-74604 CVE-2026-74607                      CVE-2026-74608 CVE-2026-74609 CVE-2026-74612 CVE-2026-74613                      CVE-2026-74614 CVE-2026-74615 CVE-2026-74616 CVE-2026-74620                      CVE-2026-74621 CVE-2026-74622 CVE-2026-74623 CVE-2026-74624                      CVE-2026-74625 CVE-2026-74626 CVE-2026-74628 CVE-2026-74630                      CVE-2026-74631 CVE-2026-74632 CVE-2026-74635 CVE-2026-74636                      CVE-2026-74637 CVE-2026-74641 CVE-2026-74647 CVE-2026-74648                      CVE-2026-74649 CVE-2026-74650 CVE-2026-74651 CVE-2026-74654                      CVE-2026-74656 CVE-2026-74657 CVE-2026-74658 CVE-2026-74659                      CVE-2026-74660 CVE-2026-74662 CVE-2026-74663 CVE-2026-74664                      CVE-2026-74666 CVE-2026-74667 CVE-2026-74668 CVE-2026-74669                      CVE-2026-74671 CVE-2026-74672 CVE-2026-74673 CVE-2026-74675                      CVE-2026-74676 CVE-2026-74678 CVE-2026-74679 CVE-2026-74680                      CVE-2026-74682 CVE-2026-74683 CVE-2026-74688 CVE-2026-74689                      CVE-2026-74691 CVE-2026-74692 CVE-2026-74693 CVE-2026-74694                      CVE-2026-74696 CVE-2026-74697 CVE-2026-74701 CVE-2026-74704                      CVE-2026-74705 CVE-2026-74714 CVE-2026-74717 CVE-2026-74719                      CVE-2026-74720 CVE-2026-74722 CVE-2026-74724 CVE-2026-74726                      CVE-2026-74730 CVE-2026-74737 CVE-2026-74739 CVE-2026-74743                      CVE-2026-74744 CVE-2026-74746 CVE-2026-74748 CVE-2026-80527                      CVE-2026-80528 CVE-2026-80529 CVE-2026-80534 CVE-2026-80536                      CVE-2026-80539 CVE-2026-80540 CVE-2026-80541 CVE-2026-80547                      CVE-2026-80548 CVE-2026-80549 CVE-2026-80550 CVE-2026-80552                      CVE-2026-80553 CVE-2026-80555 CVE-2026-80557 CVE-2026-80558                      CVE-2026-80559 CVE-2026-80560 CVE-2026-80561 CVE-2026-80562                      CVE-2026-80565 CVE-2026-80567 CVE-2026-80568 CVE-2026-80569                      CVE-2026-80570 CVE-2026-80572 CVE-2026-80573 CVE-2026-80574                      CVE-2026-80583 CVE-2026-80584 CVE-2026-80586 CVE-2026-80589                      CVE-2026-80590 CVE-2026-80678 CVE-2026-80679 CVE-2026-80680                      CVE-2026-80681 CVE-2026-80684 CVE-2026-80686 CVE-2026-80706                      CVE-2026-80707 CVE-2026-80708 CVE-2026-80709 CVE-2026-80714                      CVE-2026-80715 CVE-2026-80716 CVE-2026-80717 CVE-2026-80718                      CVE-2026-80722 CVE-2026-80725 CVE-2026-80726 CVE-2026-80730                      CVE-2026-80731 CVE-2026-80732 CVE-2026-80733 CVE-2026-80737                      CVE-2026-80742 CVE-2026-80743 CVE-2026-80744 CVE-2026-80752                      CVE-2026-80754 CVE-2026-80756 CVE-2026-80757 CVE-2026-80762                      CVE-2026-80763 CVE-2026-80764 CVE-2026-80765 CVE-2026-80766                      CVE-2026-80767 CVE-2026-80768 CVE-2026-80770 CVE-2026-80772                      CVE-2026-80781 CVE-2026-80782 CVE-2026-80783 CVE-2026-80784                      CVE-2026-80788 CVE-2026-80789 CVE-2026-80790 CVE-2026-80791                      CVE-2026-80792 CVE-2026-80793 CVE-2026-80794 CVE-2026-80795                      CVE-2026-80796 CVE-2026-80797 CVE-2026-80798 CVE-2026-80799                      CVE-2026-80800 CVE-2026-80801 CVE-2026-80802 CVE-2026-80803                      CVE-2026-80805 CVE-2026-80806 CVE-2026-80807 CVE-2026-80808                      CVE-2026-80809 CVE-2026-80812 CVE-2026-80814 CVE-2026-80819                      CVE-2026-80823 CVE-2026-80824 CVE-2026-80826 CVE-2026-80827                      CVE-2026-80828 CVE-2026-80829 CVE-2026-80830 CVE-2026-80831                      CVE-2026-80832 CVE-2026-80840 CVE-2026-80842 CVE-2026-80843                      CVE-2026-80844 CVE-2026-80846 CVE-2026-80848 CVE-2026-80852                      CVE-2026-80854 CVE-2026-80855 CVE-2026-80856 CVE-2026-80863                      CVE-2026-80888 CVE-2026-80890 CVE-2026-80891 CVE-2026-80892                      CVE-2026-80893 CVE-2026-80901 CVE-2026-80902 CVE-2026-80904                      CVE-2026-80906 CVE-2026-80908 CVE-2026-80909 CVE-2026-80910                      CVE-2026-80913

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

    For Debian 12 bookworm, these problems have been fixed in version     6.1.187-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 LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS

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 CentOS Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS-STREAM8:CLSA-2026:1792239979 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: kyber: fix out of bounds access when     preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to
    ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the     corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls     to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx.
    This works accidentally most of the time, but it can cause us to read garbage if the second ctx came     from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This     manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-     bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int     [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40
    __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480     do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100     submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0     btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440
    __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0     extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0     writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660     wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240     ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge()     instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch.
    (CVE-2021-46984)

  - A use-after-free flaw was found in the Linux kernel's SGI GRU driver in the way the first     gru_file_unlocked_ioctl function is called by the user, where a fail pass occurs in the     gru_check_chiplet_assignment function. This flaw allows a local user to crash or potentially escalate     their privileges on the system. (CVE-2022-3424)

  - In the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Fix alignment problem     in bpf_prog_test_run_skb() We got a syzkaller problem because of aarch64 alignment fault if KFENCE     enabled. When the size from user bpf program is an odd number, like 399, 407, etc, it will cause the     struct skb_shared_info's unaligned access. As seen below: BUG: KFENCE: use-after-free read in
    __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213):
    __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add     arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270     [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0     net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect     net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420     bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]     bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594     bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]
    __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196,     size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc     include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline]     bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c     net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf     kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381
    __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381 To fix the problem, we adjust @size so that (@size +     @hearoom) is a multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info is aligned to a     cache line. (CVE-2022-49840)

  - In the Linux kernel, the following vulnerability has been resolved: usbnet: Fix linkwatch use-after-free     on disconnect usbnet uses the work usbnet_deferred_kevent() to perform tasks which may sleep. On     disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to
    ->disconnect() by historic commit [PATCH] USB: usbnet, prevent exotic rtnl deadlock:
    https://git.kernel.org/tglx/history/c/0f138bbfd83c The change was made because back then, the kernel's     workqueue implementation did not allow waiting for a single work. One had to wait for completion of *all*     work by calling flush_scheduled_work(), and that could deadlock when waiting for usbnet_deferred_kevent()     with rtnl_mutex held in ->ndo_stop(). The commit solved one problem but created another: It causes a use-     after-free in USB Ethernet drivers aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c and smsc75xx.c: * If     the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in     their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent(). *     usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls     netif_carrier_{on,off}(). * That in turn schedules the work linkwatch_event(). Because     usbnet_deferred_kevent() is awaited after unregister_netdev(), netif_carrier_{on,off}() may operate on an     unregistered netdev and linkwatch_event() may run after free_netdev(), causing a use-after-free. In 2010,     usbnet was changed to only wait for a single instance of usbnet_deferred_kevent() instead of *all* work by     commit 23f333a2bfaf (drivers/net: don't use flush_scheduled_work()). Unfortunately the commit neglected     to move the wait back to ->ndo_stop(). Rectify that omission at long last. (CVE-2022-50220)

  - In the Linux kernel, the following vulnerability has been resolved: cifs: fix oops during encryption When     running xfstests against Azure the following oops occurred on an arm64 system Unable to handle kernel     write to read-only memory at virtual address ffff0001221cf000 Mem abort info: ESR = 0x9600004f EC = 0x25:
    DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault     Data abort info: ISV = 0, ISS = 0x0000004f CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs,     pgdp=00000000294f3000 [ffff0001221cf000] pgd=18000001ffff8003, p4d=18000001ffff8003, pud=18000001ff82e003,     pmd=18000001ff71d003, pte=00600001221cf787 Internal error: Oops: 9600004f [#1] PREEMPT SMP ... pstate:
    80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) pc : __memcpy+0x40/0x230 lr :
    scatterwalk_copychunks+0xe0/0x200 sp : ffff800014e92de0 x29: ffff800014e92de0 x28: ffff000114f9de80 x27:
    0000000000000008 x26: 0000000000000008 x25: ffff800014e92e78 x24: 0000000000000008 x23: 0000000000000001     x22: 0000040000000000 x21: ffff000000000000 x20: 0000000000000001 x19: ffff0001037c4488 x18:
    0000000000000014 x17: 235e1c0d6efa9661 x16: a435f9576b6edd6c x15: 0000000000000058 x14: 0000000000000001     x13: 0000000000000008 x12: ffff000114f2e590 x11: ffffffffffffffff x10: 0000040000000000 x9 :
    ffff8000105c3580 x8 : 2e9413b10000001a x7 : 534b4410fb86b005 x6 : 534b4410fb86b005 x5 : ffff0001221cf008     x4 : ffff0001037c4490 x3 : 0000000000000001 x2 : 0000000000000008 x1 : ffff0001037c4488 x0 :
    ffff0001221cf000 Call trace: __memcpy+0x40/0x230 scatterwalk_map_and_copy+0x98/0x100     crypto_ccm_encrypt+0x150/0x180 crypto_aead_encrypt+0x2c/0x40 crypt_message+0x750/0x880     smb3_init_transform_rq+0x298/0x340 smb_send_rqst.part.11+0xd8/0x180 smb_send_rqst+0x3c/0x100     compound_send_recv+0x534/0xbc0 smb2_query_info_compound+0x32c/0x440 smb2_set_ea+0x438/0x4c0     cifs_xattr_set+0x5d4/0x7c0 This is because in scatterwalk_copychunks(), we attempted to write to a buffer     (@sign) that was allocated in the stack (vmalloc area) by crypt_message() and thus accessing its remaining     8 (x2) bytes ended up crossing a page boundary. To simply fix it, we could just pass @sign kmalloc'd from     crypt_message() and then we're done. Luckily, we don't seem to pass any other vmalloc'd buffers in     smb_rqst::rq_iov... Instead, let's map the correct pages and offsets from vmalloc buffers as well in     cifs_sg_set_buf() and then avoiding such oopses. (CVE-2022-50341)

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: xfs: don't swallow dquot recovery     verification errors xlog_recover_dquot_commit_pass2() validates the recovered dquot with     xfs_dqblk_verify() and, on failure, sets error = -EFSCORRUPTED and jumps to out_release. But out_release     unconditionally returns 0, so the corruption error is discarded: the caller xlog_recover_items_pass2()     sees success, log recovery proceeds as if the dquot were valid, and the corrupt quota buffer can be     written back to disk. (CVE-2026-80529)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
351016	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3139)	Nessus	Amazon Linux Local Security Checks	2026/9/29	2026/10/8	critical
364682	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1791800936)	Nessus	Rocky Linux Local Security Checks	2026/10/12	2026/10/13	high
360912	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1789898700)	Nessus	Alma Linux Local Security Checks	2026/10/1	2026/10/1	high
375124	Photon OS 5.0: Linux PHSA-2026-5.0-91-0982	Nessus	PhotonOS Local Security Checks	2026/11/2	2026/11/2	critical
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	2026/10/8	2026/10/8	high
348574	Debian dla-4788 : ata-modules-6.12.100+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	2026/9/21	2026/9/21	medium
375000	Photon OS 5.0: Linux PHSA-2026-5.0-92-0982	Nessus	PhotonOS Local Security Checks	2026/11/2	2026/11/2	critical
350138	openSUSE 16: cluster-md-kmp-64kb / cluster-md-kmp-azure / cluster-md-kmp-default / etc (openSUSE-SU-2026:21910-1)	Nessus	SuSE Local Security Checks	2026/9/25	2026/9/28	high
343851	Debian dla-4777 : ata-modules-6.1.0-52-armmp-di - security update	Nessus	Debian Local Security Checks	2026/9/8	2026/9/8	high
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	2026/11/5	2026/11/5	high
345814	Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2026-2143)	Nessus	Amazon Linux Local Security Checks	2026/9/14	2026/9/25	medium
366781	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1792239979)	Nessus	CentOS Local Security Checks	2026/10/17	2026/10/27	high
340737	Linux Distros Unpatched Vulnerability : CVE-2026-80529	Nessus	Misc.	2026/8/26	2026/11/11	high

检测

插件搜索

critical

high

high

critical

high

medium

critical

high

high

high

medium

high

high