Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - 命名空間：在 pivot_root（） 中讀取其父項之前檢查掛載 path_pivot_root（） 會讀取 new_root 和調用方根的父項，並在檢查任一掛載是否位於調用方的掛載命名空間中之前檢查它們是否已共用。只舉行namespace_sem。這對於呼叫端的掛載命名空間中的掛載來說很好。但是new_root可以是已卸載且只有檔案描述元保持作用中的掛載的檔案描述元。如果該掛載在卸載時保持貼附至其父項，則不會為其固定父項。父項的最後一個 mntput（） 單獨解除 mount_lock 下的子項，然後釋放父項：pivot_root（） close（fd），父項的最後一個 ref
    ------------ --------------------------------- ex_parent = new_mnt->mnt_parent mntput_no_expire_slowpath（）
    __umount_mnt（new_mnt） cleanup_mnt（） call_rcu（） IS_MNT_SHARED（ex_parent） 錯誤： KASAN：path_pivot_root+0xf1a/0x1840 中的 slab-use-after-free 依任務 pivot_widen/157 在 addr ffff8881047382f8 讀取大小 4 path_pivot_root+0xf1a/0x1840 __x64_sys_pivot_root+0x165/0x190 透過 chroot（） 的呼叫端 root 也是如此。檢查的兩個結果都以 EINVAL 結束，因此除了讀取本身之外什麼都不會出錯。這是同樣的事情 commit bb4609405752 （statmount：讀取 mount_lock 下未掛載的掛載的父項） 為 statmount（） 修復。在讀取其父項之前，檢查這兩個掛載是否都在呼叫端的命名空間中。無論哪種方式，每個路徑都會傳回 EINVAL。（CVE-2026-98985）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

AlmaLinux 9.2 主機已安裝的套件會受到 TuxCare ALMALINUX9.2：CLSA-2026：1793333110 公告中提及的多個弱點影響。

  - 已解決 Linux 核心中的下列弱點：dma-debug: don't call
    __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it. Trimmed-down lockdep splat: The existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}:
    _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8
    ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8
    __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 ... -> #0 (console_owner){-...}-{0:0}:
    __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc
    _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Chain exists of: console_owner --> &port_lock_key --> free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(free_entries_lock);
    lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace:
    dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated--- (CVE-2023-52516)

  - 已解決 Linux 核心中的下列弱點：USB: sisusbvga: Add endpoint checks The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver: ------------[ cut here]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 26 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU:
    1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Workqueue: usb_hub_wq hub_event RIP:
    0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18 e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff888012783a80 RSI: ffffffff816680ec RDI: fffff52000143d95 RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000 R10:
    0000000080000000 R11: 0000000000000000 R12: 0000000000000003 R13: ffff888017d33370 R14: 0000000000000003 R15: ffff888021213600 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sisusb_bulkout_msg drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline] sisusb_send_bulk_msg.constprop.0+0x904/0x1230 drivers/usb/misc/sisusbvga/sisusbvga.c:379 sisusb_send_bridge_packet drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline] sisusb_do_init_gfxdevice drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline] sisusb_init_gfxdevice+0x87b/0x4000 drivers/usb/misc/sisusbvga/sisusbvga.c:2177 sisusb_probe+0x9cd/0xbe2 drivers/usb/misc/sisusbvga/sisusbvga.c:2869 ... The problem was caused by the fact that the driver does not check whether the endpoints it uses are actually present and have the appropriate types. This can be fixed by adding a simple check of the endpoints. (CVE-2023-54213)

  - 已解決 Linux 核心中的下列弱點：net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 (act_mirred: use the backlog for nested calls to mirred ingress) hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. (CVE-2024-26740)

  - 已解決 Linux 核心中的下列弱點：mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa node doesn't have its local memory so it has no managed zones, the following oops has been observed. It's because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF:
    supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops:
    0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name:
    QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS:
    00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI:
    0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14:
    0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3:
    000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: > <TASK> > ? __die > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault > ? wakeup_kswapd > migrate_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault > exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Code: (omitted) > RSP:
    002b:00007ffeefa821a0 EFLAGS: 00010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0 > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08:
    0000000000000037 R09: 0000000000000075 > R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 > </TASK> (CVE-2024-26783)

  - 已解決 Linux 核心中的下列弱點：vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(i_ea) ---- AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ubifs_jnl_write_inode ABBA deadlock -----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate(
    ---truncated--- (CVE-2024-45003)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - namespace：在读取 pivot_root（） 中的父项前检查挂载 path_pivot_root（） 读取 new_root 和调用方根的父项并检查它们是否被共享，然后再检查任一挂载是否在调用方的挂载命名空间中。只举行namespace_sem。这对于位于调用方的挂载命名空间中的挂载没有问题。但是new_root可以是已取消挂载且只有文件描述符保持活动状态的挂载的文件描述符。如果该挂载在取消挂载时保持连接到其父项，则不会为其固定父项。父项的最后一个 mntput（） 单独解除 mount_lock 下的子项，然后释放父项：pivot_root（） close（fd），父项的最后一个 ref
    ------------ --------------------------------- ex_parent = new_mnt->mnt_parent mntput_no_expire_slowpath（）
    __umount_mnt（new_mnt） cleanup_mnt（） call_rcu（） IS_MNT_SHARED（ex_parent） 缺陷： KASAN：在 path_pivot_root+0xf1a/0x1840 中按任务 pivot_widen/157 在地址 ffff8881047382f8 读取的大小为 4 的释放后使用 path_pivot_root+0xf1a/0x1840 __x64_sys_pivot_root+0x165/0x190 同样适用于通过 chroot（） 进行的调用程序的根证书。检查的两个结果都以 EINVAL 结尾，因此除了读取本身之外不会出错。这也是一样的 commit bb4609405752（statmount：读取 mount_lock 下未挂载挂载的父项） 为 statmount（） 修复。读取父项前，检查两个挂载是否都在调用者的命名空间中。无论哪种方式，每个路径都会返回 EINVAL。（CVE-2026-98985）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

AlmaLinux 9.2 主机上存在安装的程序包，该程序包受到 TuxCare ALMALINUX9.2：CLSA-2026：1793333110公告中提及的多个漏洞的影响。

  - 已修复 Linux 内核中的下列漏洞：dma-debug: don't call
    __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it. Trimmed-down lockdep splat: The existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}:
    _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8
    ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8
    __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 ... -> #0 (console_owner){-...}-{0:0}:
    __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc
    _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Chain exists of: console_owner --> &port_lock_key --> free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(free_entries_lock);
    lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace:
    dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated--- (CVE-2023-52516)

  - 已修复 Linux 内核中的下列漏洞：USB: sisusbvga: Add endpoint checks The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver: ------------[ cut here]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 26 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU:
    1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Workqueue: usb_hub_wq hub_event RIP:
    0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18 e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff888012783a80 RSI: ffffffff816680ec RDI: fffff52000143d95 RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000 R10:
    0000000080000000 R11: 0000000000000000 R12: 0000000000000003 R13: ffff888017d33370 R14: 0000000000000003 R15: ffff888021213600 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sisusb_bulkout_msg drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline] sisusb_send_bulk_msg.constprop.0+0x904/0x1230 drivers/usb/misc/sisusbvga/sisusbvga.c:379 sisusb_send_bridge_packet drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline] sisusb_do_init_gfxdevice drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline] sisusb_init_gfxdevice+0x87b/0x4000 drivers/usb/misc/sisusbvga/sisusbvga.c:2177 sisusb_probe+0x9cd/0xbe2 drivers/usb/misc/sisusbvga/sisusbvga.c:2869 ... The problem was caused by the fact that the driver does not check whether the endpoints it uses are actually present and have the appropriate types. This can be fixed by adding a simple check of the endpoints. (CVE-2023-54213)

  - 已修复 Linux 内核中的下列漏洞：net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 (act_mirred: use the backlog for nested calls to mirred ingress) hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. (CVE-2024-26740)

  - 已修复 Linux 内核中的下列漏洞：mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa node doesn't have its local memory so it has no managed zones, the following oops has been observed. It's because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF:
    supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops:
    0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name:
    QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS:
    00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI:
    0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14:
    0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3:
    000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: > <TASK> > ? __die > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault > ? wakeup_kswapd > migrate_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault > exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Code: (omitted) > RSP:
    002b:00007ffeefa821a0 EFLAGS: 00010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0 > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08:
    0000000000000037 R09: 0000000000000075 > R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 > </TASK> (CVE-2024-26783)

  - 已修复 Linux 内核中的下列漏洞：vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(i_ea) ---- AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ubifs_jnl_write_inode ABBA deadlock -----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate(
    ---truncated--- (CVE-2024-45003)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - namespace:pivot_root() で親を読み取る前にマウントをチェックしますpath_pivot_root() は、new_root と呼び出し元の root の親を読み取り、どちらかのマウントが呼び出し元のマウント名前空間にあることをチェックする前に、それらが共有されているかどうかをチェックします。開催はnamespace_semのみです。これは、呼び出し側のマウント名前空間にあるマウントに対しては問題ありません。ただし、new_rootは、マウント解除され、ファイル記述子のみが存続しているマウントのファイル記述子である可能性があります。マウントがアンマウントされたときにそのマウントが親にアタッチされたままの場合、何も親をピン留めしません。親の最後の mntput() は、単独で mount_lock 下の子をアンフックし、その後親を解放します: pivot_root() close(fd)、親の最後の ref
    ------------ --------------------------------- ex_parent = new_mnt->mnt_parent mntput_no_expire_slowpath()
    __umount_mnt(new_mnt) cleanup_mnt() call_rcu() IS_MNT_SHARED(ex_parent) バグ: KASAN:path_pivot_root+0xf1a/0x1840 の slab-use-after-free タスク pivot_widen/157 による addr ffff8881047382f8 でのサイズ 4 の読み取り path_pivot_root+0xf1a/0x1840 __x64_sys_pivot_root+0x165/0x190 chroot() による呼び出し元の root についても同様です。チェックの結果は両方とも EINVAL で終了するため、読み取り自体以外は問題が出ません。これは同じことです コミット bb4609405752 (statmount:mount_lock の下でマウント解除されたマウントの親を読み込み)statmount() のために修正されました。親が読み取られる前に、両方のマウントが呼び出し元の名前空間にあることを確認してください。すべてのパスは、どちらの方法でも EINVAL を返します。(CVE-2026-98985)

Nessus は、ベンダーから報告されたパッケージの存在に依存していることに注意してください。

AlmaLinux 9.2 ホストには、TuxCare ALMALINUX9.2:CLSA-2026:1793333110アドバイザリに記載されている複数の脆弱性の影響を受けるパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: dma-debug: don't call
    __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it. Trimmed-down lockdep splat: The existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}:
    _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8
    ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8
    __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 ... -> #0 (console_owner){-...}-{0:0}:
    __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc
    _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Chain exists of: console_owner --> &port_lock_key --> free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(free_entries_lock);
    lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace:
    dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated--- (CVE-2023-52516)

  - Linux カーネルでは、以下の脆弱性が解決されています: USB: sisusbvga: Add endpoint checks The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver: ------------[ cut here]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 26 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU:
    1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Workqueue: usb_hub_wq hub_event RIP:
    0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18 e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff888012783a80 RSI: ffffffff816680ec RDI: fffff52000143d95 RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000 R10:
    0000000080000000 R11: 0000000000000000 R12: 0000000000000003 R13: ffff888017d33370 R14: 0000000000000003 R15: ffff888021213600 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sisusb_bulkout_msg drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline] sisusb_send_bulk_msg.constprop.0+0x904/0x1230 drivers/usb/misc/sisusbvga/sisusbvga.c:379 sisusb_send_bridge_packet drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline] sisusb_do_init_gfxdevice drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline] sisusb_init_gfxdevice+0x87b/0x4000 drivers/usb/misc/sisusbvga/sisusbvga.c:2177 sisusb_probe+0x9cd/0xbe2 drivers/usb/misc/sisusbvga/sisusbvga.c:2869 ... The problem was caused by the fact that the driver does not check whether the endpoints it uses are actually present and have the appropriate types. This can be fixed by adding a simple check of the endpoints. (CVE-2023-54213)

  - Linux カーネルでは、以下の脆弱性が解決されています: net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 (act_mirred: use the backlog for nested calls to mirred ingress) hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. (CVE-2024-26740)

  - Linux カーネルでは、以下の脆弱性が解決されています: mm/vmscan: fix a bug calling wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa node doesn't have its local memory so it has no managed zones, the following oops has been observed. It's because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF:
    supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops:
    0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name:
    QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 > RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS:
    00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI:
    0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14:
    0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3:
    000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: > <TASK> > ? __die > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault > ? wakeup_kswapd > migrate_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault > exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Code: (omitted) > RSP:
    002b:00007ffeefa821a0 EFLAGS: 00010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0 > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08:
    0000000000000037 R09: 0000000000000075 > R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 > </TASK> (CVE-2024-26783)

  - Linux カーネルでは、以下の脆弱性が解決されています: vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(i_ea) ---- AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ubifs_jnl_write_inode ABBA deadlock -----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate(
    ---truncated--- (CVE-2024-45003)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションが自己報告するバージョン番号にのみ依存していることに注意してください。

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

  - namespace: check the mounts before reading their parents in pivot_root() path_pivot_root() reads the     parents of new_root and of the caller's root and checks whether they are shared before it checks that     either mount is in the caller's mount namespace. Only namespace_sem is held. That's fine for a mount that     is in the caller's mount namespace. But new_root can be a file descriptor to a mount that has been     unmounted and that only the file descriptor keeps alive. If that mount stayed attached to its parent when     it was unmounted nothing pins the parent for it. The final mntput() of the parent unhooks the children     under mount_lock alone and frees the parent afterwards: pivot_root() close(fd), last ref on the parent
    ------------ --------------------------------- ex_parent = new_mnt->mnt_parent mntput_no_expire_slowpath()
    __umount_mnt(new_mnt) cleanup_mnt() call_rcu() IS_MNT_SHARED(ex_parent) BUG: KASAN: slab-use-after-free in     path_pivot_root+0xf1a/0x1840 Read of size 4 at addr ffff8881047382f8 by task pivot_widen/157     path_pivot_root+0xf1a/0x1840 __x64_sys_pivot_root+0x165/0x190 The same goes for the caller's root via     chroot(). Both outcomes of the check end in EINVAL so nothing but the read itself goes wrong. It's the     same thing commit bb4609405752 (statmount: read the parent of an unmounted mount under mount_lock) fixed     for statmount(). Check that both mounts are in the caller's namespace before their parents are read. Every     path returns EINVAL either way. (CVE-2026-98985)

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

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

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

    - Network file systems library;

    - Stream parser;

    - ARM64 architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - S390 architecture;

    - User-Mode Linux (UML);

    - x86 architecture;

    - Block layer subsystem;

    - Android drivers;

    - Bluetooth drivers;

    - TPM device driver;

    - DPLL subsystem;

    - EDAC drivers;

    - GPIO subsystem;

    - GPU drivers;

    - HID subsystem;

    - IIO subsystem;

    - IIO ADC drivers;

    - InfiniBand drivers;

    - Input Device (Miscellaneous) drivers;

    - Multiple devices driver;

    - MemoryStick subsystem;

    - MMC subsystem;

    - MTD block device drivers;

    - Network drivers;

    - Ethernet bonding driver;

    - Mellanox network drivers;

    - STMicroelectronics network drivers;

    - Ethernet team driver;

    - MediaTek network drivers;

    - NVME drivers;

    - Device tree and open firmware driver;

    - Power sequencing drivers;

    - Voltage and Current Regulator drivers;

    - Real Time Clock drivers;

    - SCSI subsystem;

    - Greybus lights staging drivers;

    - Trusted Execution Environment drivers;

    - Thunderbolt and USB4 drivers;

    - TTY drivers;

    - Cadence USB3 driver;

    - USB Device Class drivers;

    - USB core drivers;

    - DesignWare USB2 driver;

    - DesignWare USB3 driver;

    - USB Gadget drivers;

    - USB Serial drivers;

    - USB Mass Storage drivers;

    - USB Type-C support driver;

    - USB Type-C Port Controller Manager driver;

    - TI TPS6598x USB Power Delivery controller driver;

    - USB Type-C Connector System Software Interface driver;

    - Amazon Nitro Enclaves driver;

    - Virtual machine generation ID driver;

    - BTRFS file system;

    - File systems infrastructure;

    - SMB network file system;

    - XFS file system;

    - BPF subsystem;

    - io_uring subsystem;

    - Netfilter;

    - Namespaces infrastructure;

    - Networking core;

    - Networking subsytem;

    - Virtio network driver;

    - Bluetooth subsystem;

    - IPv4 networking;

    - Network traffic control;

    - Audit subsystem;

    - Control group (cgroup);

    - Perf events;

    - Kernel fork() syscall;

    - Kernel futex primitives;

    - KProbes tracing;

    - Kexec HandOver (KHO);

    - Kernel module support;

    - Tracing infrastructure;

    - Workqueue subsystem;

    - Memory management;

    - Ethernet bridge;

    - Devlink API;

    - IPv6 networking;

    - MAC80211 subsystem;

    - Management Component Transport Protocol (MCTP);

    - Open vSwitch;

    - Packet sockets;

    - SCTP protocol;

    - SMC sockets;

    - TIPC protocol;

    - VMware vSockets driver;

    - Wireless networking;

    - XFRM subsystem;

    - Drivers core;

    - Key management;

    - SELinux security module;

    - ALSA framework;

    - Creative Sound Blaster X-Fi driver;

    - Analog Devices audio codecs;

    - Maxim audio codecs;

    - Realtek audio codecs;

    - QCOM ASoC drivers;

    - Samsung ASoC drivers;

    - SoundWire (SDCA) ASoC drivers;

    - USB sound devices; (CVE-2026-68305, CVE-2026-72404, CVE-2026-72497, CVE-2026-74527, CVE-2026-74568,     CVE-2026-89568, CVE-2026-89764, CVE-2026-89907, CVE-2026-90144, CVE-2026-90155, CVE-2026-90162,     CVE-2026-90167, CVE-2026-90317, CVE-2026-93175, CVE-2026-98038, CVE-2026-98375, CVE-2026-98432,     CVE-2026-98655, CVE-2026-98656, CVE-2026-98657, CVE-2026-98658, CVE-2026-98659, CVE-2026-98660,     CVE-2026-98661, CVE-2026-98662, CVE-2026-98663, CVE-2026-98664, CVE-2026-98665, CVE-2026-98666,     CVE-2026-98667, CVE-2026-98668, CVE-2026-98669, CVE-2026-98670, CVE-2026-98671, CVE-2026-98672,     CVE-2026-98673, CVE-2026-98674, CVE-2026-98675, CVE-2026-98676, CVE-2026-98677, CVE-2026-98678,     CVE-2026-98679, CVE-2026-98680, CVE-2026-98681, CVE-2026-98682, CVE-2026-98683, CVE-2026-98684,     CVE-2026-98685, CVE-2026-98686, CVE-2026-98687, CVE-2026-98689, CVE-2026-98690, CVE-2026-98691,     CVE-2026-98692, CVE-2026-98693, CVE-2026-98694, CVE-2026-98695, CVE-2026-98696, CVE-2026-98697,     CVE-2026-98698, CVE-2026-98699, CVE-2026-98700, CVE-2026-98701, CVE-2026-98702, CVE-2026-98703,     CVE-2026-98704, CVE-2026-98705, CVE-2026-98706, CVE-2026-98707, CVE-2026-98708, CVE-2026-98709,     CVE-2026-98710, CVE-2026-98711, CVE-2026-98712, CVE-2026-98713, CVE-2026-98714, CVE-2026-98715,     CVE-2026-98716, CVE-2026-98717, CVE-2026-98718, CVE-2026-98719, CVE-2026-98720, CVE-2026-98721,     CVE-2026-98722, CVE-2026-98723, CVE-2026-98724, CVE-2026-98725, CVE-2026-98726, CVE-2026-98727,     CVE-2026-98728, CVE-2026-98729, CVE-2026-98730, CVE-2026-98731, CVE-2026-98732, CVE-2026-98733,     CVE-2026-98734, CVE-2026-98735, CVE-2026-98736, CVE-2026-98737, CVE-2026-98738, CVE-2026-98739,     CVE-2026-98740, CVE-2026-98741, CVE-2026-98742, CVE-2026-98743, CVE-2026-98744, CVE-2026-98745,     CVE-2026-98746, CVE-2026-98747, CVE-2026-98748, CVE-2026-98749, CVE-2026-98750, CVE-2026-98751,     CVE-2026-98752, CVE-2026-98753, CVE-2026-98754, CVE-2026-98755, CVE-2026-98756, CVE-2026-98757,     CVE-2026-98758, CVE-2026-98759, CVE-2026-98760, CVE-2026-98761, CVE-2026-98762, CVE-2026-98763,     CVE-2026-98764, CVE-2026-98765, CVE-2026-98766, CVE-2026-98767, CVE-2026-98768, CVE-2026-98769,     CVE-2026-98770, CVE-2026-98771, CVE-2026-98772, CVE-2026-98773, CVE-2026-98774, CVE-2026-98775,     CVE-2026-98776, CVE-2026-98777, CVE-2026-98778, CVE-2026-98779, CVE-2026-98780, CVE-2026-98781,     CVE-2026-98782, CVE-2026-98783, CVE-2026-98784, CVE-2026-98785, CVE-2026-98786, CVE-2026-98788,     CVE-2026-98789, CVE-2026-98790, CVE-2026-98791, CVE-2026-98792, CVE-2026-98793, CVE-2026-98794,     CVE-2026-98795, CVE-2026-98796, CVE-2026-98797, CVE-2026-98798, CVE-2026-98799, CVE-2026-98800,     CVE-2026-98801, CVE-2026-98802, CVE-2026-98803, CVE-2026-98804, CVE-2026-98805, CVE-2026-98806,     CVE-2026-98807, CVE-2026-98808, CVE-2026-98809, CVE-2026-98810, CVE-2026-98811, CVE-2026-98812,     CVE-2026-98813, CVE-2026-98814, CVE-2026-98816, CVE-2026-98817, CVE-2026-98818, CVE-2026-98819,     CVE-2026-98820, CVE-2026-98821, CVE-2026-98822, CVE-2026-98823, CVE-2026-98824, CVE-2026-98825,     CVE-2026-98826, CVE-2026-98827, CVE-2026-98828, CVE-2026-98829, CVE-2026-98830, CVE-2026-98831,     CVE-2026-98833, CVE-2026-98834, CVE-2026-98835, CVE-2026-98836, CVE-2026-98837, CVE-2026-98838,     CVE-2026-98839, CVE-2026-98840, CVE-2026-98841, CVE-2026-98842, CVE-2026-98843, CVE-2026-98844,     CVE-2026-98845, CVE-2026-98846, CVE-2026-98847, CVE-2026-98848, CVE-2026-98849, CVE-2026-98850,     CVE-2026-98851, CVE-2026-98852, CVE-2026-98853, CVE-2026-98854, CVE-2026-98855, CVE-2026-98856,     CVE-2026-98857, CVE-2026-98858, CVE-2026-98859, CVE-2026-98860, CVE-2026-98861, CVE-2026-98862,     CVE-2026-98863, CVE-2026-98931, CVE-2026-98932, CVE-2026-98933, CVE-2026-98934, CVE-2026-98935,     CVE-2026-98936, CVE-2026-98937, CVE-2026-98939, CVE-2026-98940, CVE-2026-98944, CVE-2026-98945,     CVE-2026-98946, CVE-2026-98947, CVE-2026-98948, CVE-2026-98949, CVE-2026-98950, CVE-2026-98951,     CVE-2026-98952, CVE-2026-98953, CVE-2026-98954, CVE-2026-98955, CVE-2026-98956, CVE-2026-98957,     CVE-2026-98958, CVE-2026-98959, CVE-2026-98960, CVE-2026-98961, CVE-2026-98962, CVE-2026-98963,     CVE-2026-98964, CVE-2026-98965, CVE-2026-98966, CVE-2026-98967, CVE-2026-98968, CVE-2026-98969,     CVE-2026-98970, CVE-2026-98971, CVE-2026-98972, CVE-2026-98973, CVE-2026-98974, CVE-2026-98975,     CVE-2026-98977, CVE-2026-98978, CVE-2026-98979, CVE-2026-98980, CVE-2026-98981, CVE-2026-98982,     CVE-2026-98983, CVE-2026-98984, CVE-2026-98985, CVE-2026-98986, CVE-2026-98987, CVE-2026-98988,     CVE-2026-98989, CVE-2026-98990, CVE-2026-98991, CVE-2026-98992, CVE-2026-98993, CVE-2026-98994,     CVE-2026-98995, CVE-2026-98996, CVE-2026-98997, CVE-2026-98999, CVE-2026-99000, CVE-2026-99001,     CVE-2026-99002, CVE-2026-99003, CVE-2026-99004, CVE-2026-99005, CVE-2026-99006, CVE-2026-99007,     CVE-2026-99008, CVE-2026-99009, CVE-2026-99010, CVE-2026-99011, CVE-2026-99012, CVE-2026-99013,     CVE-2026-99014, CVE-2026-99015, CVE-2026-99016, CVE-2026-99017, CVE-2026-99018, CVE-2026-99019,     CVE-2026-99020, CVE-2026-99021, CVE-2026-99022, CVE-2026-99023, CVE-2026-99024, CVE-2026-99025,     CVE-2026-99026, CVE-2026-99027, CVE-2026-99028, CVE-2026-99029, CVE-2026-99030, CVE-2026-99031,     CVE-2026-99032, CVE-2026-99033, CVE-2026-99034, CVE-2026-99035, CVE-2026-99036, CVE-2026-99037,     CVE-2026-99038, CVE-2026-99039, CVE-2026-99040, CVE-2026-99041, CVE-2026-99043, CVE-2026-99044,     CVE-2026-99045, CVE-2026-99046, CVE-2026-99047, CVE-2026-99048, CVE-2026-99049, CVE-2026-99050,     CVE-2026-99051, CVE-2026-99052, CVE-2026-99053, CVE-2026-99054, CVE-2026-99055, CVE-2026-99056,     CVE-2026-99057, CVE-2026-99058, CVE-2026-99059, CVE-2026-99060, CVE-2026-99061, CVE-2026-99062,     CVE-2026-99063, CVE-2026-99064, CVE-2026-99065, CVE-2026-99066, CVE-2026-99067, CVE-2026-99068,     CVE-2026-99069, CVE-2026-99070, CVE-2026-99071, CVE-2026-99072, CVE-2026-99073, CVE-2026-99074,     CVE-2026-99075, CVE-2026-99076, CVE-2026-99077, CVE-2026-99078, CVE-2026-99079, CVE-2026-99080,     CVE-2026-99081, CVE-2026-99088, CVE-2026-99089, CVE-2026-99090, CVE-2026-99091, CVE-2026-99092,     CVE-2026-99093, CVE-2026-99094, CVE-2026-99095, CVE-2026-99096, CVE-2026-99097, CVE-2026-99098,     CVE-2026-99099, CVE-2026-99999)

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

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

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

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4904-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     November 13, 2026                             https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux-6.12     Version        : 6.12.115-2~deb12u1     CVE ID         : CVE-2024-58074 CVE-2025-22109 CVE-2025-23132 CVE-2025-23135                      CVE-2025-37743 CVE-2025-37746 CVE-2025-37906 CVE-2025-38029                      CVE-2025-38041 CVE-2025-38042 CVE-2025-38064 CVE-2025-38132                      CVE-2025-38137 CVE-2025-38140 CVE-2025-38187 CVE-2025-38199                      CVE-2025-38207 CVE-2025-38261 CVE-2025-38284 CVE-2025-38359                      CVE-2025-38421 CVE-2025-38597 CVE-2025-38605 CVE-2025-38636                      CVE-2025-38656 CVE-2025-39677 CVE-2025-39775 CVE-2025-39789                      CVE-2025-39830 CVE-2025-39834 CVE-2025-39859 CVE-2025-39862                      CVE-2025-39910 CVE-2025-39933 CVE-2025-39958 CVE-2025-40065                      CVE-2025-40086 CVE-2025-40113 CVE-2025-40130 CVE-2025-40136                      CVE-2025-40338 CVE-2025-40355 CVE-2025-68174 CVE-2025-68193                      CVE-2025-68209 CVE-2025-68236 CVE-2025-68318 CVE-2025-68319                      CVE-2025-68353 CVE-2025-68359 CVE-2025-68360 CVE-2025-68368                      CVE-2025-68376 CVE-2025-68729 CVE-2025-68730 CVE-2025-68735                      CVE-2025-68745 CVE-2025-68755 CVE-2025-71074 CVE-2025-71141                      CVE-2025-71227 CVE-2025-71285 CVE-2025-71313 CVE-2026-23007                      CVE-2026-23017 CVE-2026-23143 CVE-2026-23208 CVE-2026-23217                      CVE-2026-23259 CVE-2026-23327 CVE-2026-23371 CVE-2026-23377                      CVE-2026-23385 CVE-2026-23472 CVE-2026-31493 CVE-2026-31526                      CVE-2026-31562 CVE-2026-31579 CVE-2026-31592 CVE-2026-31630                      CVE-2026-31771 CVE-2026-43009 CVE-2026-43022 CVE-2026-43034                      CVE-2026-43042 CVE-2026-43048 CVE-2026-43053 CVE-2026-43083                      CVE-2026-43101 CVE-2026-43118 CVE-2026-43127 CVE-2026-43172                      CVE-2026-43185 CVE-2026-43191 CVE-2026-43204 CVE-2026-43213                      CVE-2026-43234 CVE-2026-43263 CVE-2026-43272 CVE-2026-43294                      CVE-2026-43298 CVE-2026-43299 CVE-2026-43308 CVE-2026-43309                      CVE-2026-43310 CVE-2026-43311 CVE-2026-43325 CVE-2026-43337                      CVE-2026-43346 CVE-2026-43352 CVE-2026-43353 CVE-2026-43414                      CVE-2026-43443 CVE-2026-43463 CVE-2026-43464 CVE-2026-43465                      CVE-2026-43485 CVE-2026-45932 CVE-2026-45934 CVE-2026-45940                      CVE-2026-45956 CVE-2026-45961 CVE-2026-46014 CVE-2026-46032                      CVE-2026-46044 CVE-2026-46059 CVE-2026-46066 CVE-2026-46071                      CVE-2026-46130 CVE-2026-46148 CVE-2026-46171 CVE-2026-46175                      CVE-2026-46181 CVE-2026-46228 CVE-2026-46245 CVE-2026-46256                      CVE-2026-46272 CVE-2026-46302 CVE-2026-46324 CVE-2026-46325                      CVE-2026-46330 CVE-2026-52937 CVE-2026-52956 CVE-2026-52983                      CVE-2026-52991 CVE-2026-53000 CVE-2026-53009 CVE-2026-53017                      CVE-2026-53018 CVE-2026-53024 CVE-2026-53025 CVE-2026-53091                      CVE-2026-53103 CVE-2026-53104 CVE-2026-53108 CVE-2026-53109                      CVE-2026-53118 CVE-2026-53178 CVE-2026-53224 CVE-2026-53258                      CVE-2026-53277 CVE-2026-53281 CVE-2026-53284 CVE-2026-53285                      CVE-2026-53292 CVE-2026-53297 CVE-2026-53321 CVE-2026-53330                      CVE-2026-53368 CVE-2026-53377 CVE-2026-53401 CVE-2026-63811                      CVE-2026-63825 CVE-2026-63832 CVE-2026-63853 CVE-2026-63857                      CVE-2026-63859 CVE-2026-63879 CVE-2026-63979 CVE-2026-63998                      CVE-2026-63999 CVE-2026-64006 CVE-2026-64024 CVE-2026-64036                      CVE-2026-64038 CVE-2026-64060 CVE-2026-64068 CVE-2026-64076                      CVE-2026-64077 CVE-2026-64079 CVE-2026-64117 CVE-2026-64146                      CVE-2026-64154 CVE-2026-64159 CVE-2026-64190 CVE-2026-64213                      CVE-2026-64283 CVE-2026-64388 CVE-2026-64389 CVE-2026-64400                      CVE-2026-64513 CVE-2026-68081 CVE-2026-68105 CVE-2026-68211                      CVE-2026-68233 CVE-2026-68238 CVE-2026-68241 CVE-2026-68242                      CVE-2026-68258 CVE-2026-68291 CVE-2026-68295 CVE-2026-68312                      CVE-2026-68323 CVE-2026-68375 CVE-2026-68383 CVE-2026-68393                      CVE-2026-68399 CVE-2026-68400 CVE-2026-68401 CVE-2026-68404                      CVE-2026-68409 CVE-2026-68412 CVE-2026-68418 CVE-2026-68421                      CVE-2026-68426 CVE-2026-68435 CVE-2026-68436 CVE-2026-68441                      CVE-2026-68447 CVE-2026-68448 CVE-2026-68453 CVE-2026-68470                      CVE-2026-68471 CVE-2026-72009 CVE-2026-72031 CVE-2026-72073                      CVE-2026-72098 CVE-2026-72162 CVE-2026-72288 CVE-2026-72321                      CVE-2026-72329 CVE-2026-72337 CVE-2026-72341 CVE-2026-72366                      CVE-2026-72367 CVE-2026-72375 CVE-2026-72380 CVE-2026-72383                      CVE-2026-72388 CVE-2026-72397 CVE-2026-72398 CVE-2026-72404                      CVE-2026-72423 CVE-2026-72439 CVE-2026-72440 CVE-2026-72488                      CVE-2026-72493 CVE-2026-72494 CVE-2026-72495 CVE-2026-72497                      CVE-2026-72499 CVE-2026-72500 CVE-2026-72501 CVE-2026-74257                      CVE-2026-74261 CVE-2026-74264 CVE-2026-74269 CVE-2026-74272                      CVE-2026-74273 CVE-2026-74317 CVE-2026-74338 CVE-2026-74344                      CVE-2026-74350 CVE-2026-74368 CVE-2026-74373 CVE-2026-74374                      CVE-2026-74375 CVE-2026-74385 CVE-2026-74388 CVE-2026-74405                      CVE-2026-74407 CVE-2026-74449 CVE-2026-74466 CVE-2026-74506                      CVE-2026-74513 CVE-2026-74520 CVE-2026-74527 CVE-2026-74529                      CVE-2026-74530 CVE-2026-74533 CVE-2026-74537 CVE-2026-74538                      CVE-2026-74542 CVE-2026-74544 CVE-2026-74558 CVE-2026-74559                      CVE-2026-74571 CVE-2026-74600 CVE-2026-74605 CVE-2026-74611                      CVE-2026-74687 CVE-2026-74690 CVE-2026-74695 CVE-2026-74697                      CVE-2026-74711 CVE-2026-74713 CVE-2026-74715 CVE-2026-74723                      CVE-2026-74728 CVE-2026-74729 CVE-2026-74733 CVE-2026-74734                      CVE-2026-74747 CVE-2026-74752 CVE-2026-74754 CVE-2026-80581                      CVE-2026-80607 CVE-2026-80614 CVE-2026-80616 CVE-2026-80623                      CVE-2026-80628 CVE-2026-80631 CVE-2026-80634 CVE-2026-80643                      CVE-2026-80653 CVE-2026-80655 CVE-2026-80662 CVE-2026-80668                      CVE-2026-80692 CVE-2026-80693 CVE-2026-80698 CVE-2026-80705                      CVE-2026-80734 CVE-2026-80738 CVE-2026-80747 CVE-2026-80761                      CVE-2026-80786 CVE-2026-80866 CVE-2026-80884 CVE-2026-80905                      CVE-2026-80920 CVE-2026-80948 CVE-2026-89528 CVE-2026-89534                      CVE-2026-89537 CVE-2026-89601 CVE-2026-89631 CVE-2026-89642                      CVE-2026-89648 CVE-2026-89654 CVE-2026-89682 CVE-2026-89705                      CVE-2026-89709 CVE-2026-89757 CVE-2026-89788 CVE-2026-89808                      CVE-2026-89810 CVE-2026-89811 CVE-2026-89812 CVE-2026-89813                      CVE-2026-89833 CVE-2026-89906 CVE-2026-89913 CVE-2026-89920                      CVE-2026-89987 CVE-2026-90061 CVE-2026-90083 CVE-2026-90084                      CVE-2026-90086 CVE-2026-90087 CVE-2026-90093 CVE-2026-90097                      CVE-2026-90099 CVE-2026-90104 CVE-2026-90105 CVE-2026-90106                      CVE-2026-90111 CVE-2026-90116 CVE-2026-90142 CVE-2026-90144                      CVE-2026-90149 CVE-2026-90154 CVE-2026-90155 CVE-2026-90156                      CVE-2026-90161 CVE-2026-90162 CVE-2026-90167 CVE-2026-90174                      CVE-2026-90177 CVE-2026-90179 CVE-2026-90182 CVE-2026-90183                      CVE-2026-90204 CVE-2026-90205 CVE-2026-90206 CVE-2026-90208                      CVE-2026-90217 CVE-2026-90231 CVE-2026-90232 CVE-2026-90234                      CVE-2026-90240 CVE-2026-90247 CVE-2026-90256 CVE-2026-90259                      CVE-2026-90260 CVE-2026-90263 CVE-2026-90264 CVE-2026-90265                      CVE-2026-90267 CVE-2026-90273 CVE-2026-90289 CVE-2026-90300                      CVE-2026-90301 CVE-2026-90311 CVE-2026-90320 CVE-2026-90321                      CVE-2026-90324 CVE-2026-90326 CVE-2026-90328 CVE-2026-90330                      CVE-2026-90333 CVE-2026-90335 CVE-2026-90336 CVE-2026-90337                      CVE-2026-90343 CVE-2026-90345 CVE-2026-90346 CVE-2026-90347                      CVE-2026-90351 CVE-2026-90359 CVE-2026-90363 CVE-2026-90365                      CVE-2026-90367 CVE-2026-90408 CVE-2026-90409 CVE-2026-90417                      CVE-2026-90421 CVE-2026-90422 CVE-2026-90424 CVE-2026-90427                      CVE-2026-92480 CVE-2026-92482 CVE-2026-92485 CVE-2026-92503                      CVE-2026-92520 CVE-2026-93058 CVE-2026-93081 CVE-2026-93100                      CVE-2026-93104 CVE-2026-93105 CVE-2026-93116 CVE-2026-93122                      CVE-2026-93125 CVE-2026-93129 CVE-2026-93144 CVE-2026-93146                      CVE-2026-93148 CVE-2026-93168 CVE-2026-93175 CVE-2026-93176                      CVE-2026-93181 CVE-2026-93202 CVE-2026-93216 CVE-2026-93221                      CVE-2026-93230 CVE-2026-93251 CVE-2026-93260 CVE-2026-93272                      CVE-2026-93282 CVE-2026-97422 CVE-2026-97424 CVE-2026-97432                      CVE-2026-97477 CVE-2026-97478 CVE-2026-97479 CVE-2026-97480                      CVE-2026-97493 CVE-2026-97501 CVE-2026-97503 CVE-2026-97513                      CVE-2026-97515 CVE-2026-97538 CVE-2026-97554 CVE-2026-97561                      CVE-2026-97928 CVE-2026-97960 CVE-2026-97962 CVE-2026-97975                      CVE-2026-97988 CVE-2026-97989 CVE-2026-97997 CVE-2026-98003                      CVE-2026-98019 CVE-2026-98032 CVE-2026-98033 CVE-2026-98034                      CVE-2026-98038 CVE-2026-98043 CVE-2026-98044 CVE-2026-98047                      CVE-2026-98048 CVE-2026-98049 CVE-2026-98053 CVE-2026-98058                      CVE-2026-98062 CVE-2026-98067 CVE-2026-98073 CVE-2026-98079                      CVE-2026-98084 CVE-2026-98085 CVE-2026-98099 CVE-2026-98124                      CVE-2026-98131 CVE-2026-98134 CVE-2026-98147 CVE-2026-98148                      CVE-2026-98156 CVE-2026-98916 CVE-2026-98974 CVE-2026-98975                      CVE-2026-98977 CVE-2026-98981 CVE-2026-98985 CVE-2026-98993                      CVE-2026-99002 CVE-2026-99009 CVE-2026-99014 CVE-2026-99019                      CVE-2026-99027 CVE-2026-99028 CVE-2026-99041 CVE-2026-99044                      CVE-2026-99077 CVE-2026-99082 CVE-2026-99083 CVE-2026-99085                      CVE-2026-99092 CVE-2026-99098 CVE-2026-99100 CVE-2026-99103                      CVE-2026-99105 CVE-2026-99106 CVE-2026-99110 CVE-2026-99112                      CVE-2026-99113 CVE-2026-99114 CVE-2026-99115 CVE-2026-99117                      CVE-2026-99118 CVE-2026-99121 CVE-2026-99123 CVE-2026-99124                      CVE-2026-99126 CVE-2026-99127 CVE-2026-99128 CVE-2026-99130                      CVE-2026-99131 CVE-2026-99132 CVE-2026-99133 CVE-2026-99134                      CVE-2026-99135 CVE-2026-99136 CVE-2026-99138 CVE-2026-99139                      CVE-2026-99140 CVE-2026-99142 CVE-2026-99143 CVE-2026-99147                      CVE-2026-99150 CVE-2026-99152 CVE-2026-99153 CVE-2026-99154                      CVE-2026-99155 CVE-2026-99156 CVE-2026-99157 CVE-2026-99158                      CVE-2026-99159 CVE-2026-99160 CVE-2026-99161 CVE-2026-99163                      CVE-2026-99165 CVE-2026-99166 CVE-2026-99167 CVE-2026-99169                      CVE-2026-99171 CVE-2026-99173 CVE-2026-99174 CVE-2026-99175                      CVE-2026-99176 CVE-2026-99178 CVE-2026-99179 CVE-2026-99180                      CVE-2026-99181 CVE-2026-99182 CVE-2026-99187 CVE-2026-99191                      CVE-2026-99192 CVE-2026-99201 CVE-2026-99202 CVE-2026-99203                      CVE-2026-99204 CVE-2026-99206 CVE-2026-99211 CVE-2026-99212                      CVE-2026-99213 CVE-2026-99214 CVE-2026-99216 CVE-2026-99218                      CVE-2026-99219 CVE-2026-99220 CVE-2026-99221 CVE-2026-99222                      CVE-2026-99223 CVE-2026-99224 CVE-2026-99225 CVE-2026-99226                      CVE-2026-99227 CVE-2026-99228 CVE-2026-99229 CVE-2026-99230                      CVE-2026-99231 CVE-2026-99233 CVE-2026-99234 CVE-2026-99235                      CVE-2026-99236 CVE-2026-99239 CVE-2026-99244 CVE-2026-99245                      CVE-2026-99246 CVE-2026-99247 CVE-2026-99249 CVE-2026-99250                      CVE-2026-99251 CVE-2026-99254 CVE-2026-99255 CVE-2026-99256                      CVE-2026-99258 CVE-2026-99284 CVE-2026-99285 CVE-2026-100072                      CVE-2026-100074 CVE-2026-100076 CVE-2026-100077     Debian Bug     : 1112238 1151097 1151281

    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.115-2~deb12u1.  This update additionally includes many more bug     fixes from stable updates 6.12.114 and 6.12.115.

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

  - In the Linux kernel, the following vulnerability has been resolved: dma-debug: don't call
    __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk ->     serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a     reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab     free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock     scope so that we don't acquire serial console's port->lock under it. Trimmed-down lockdep splat: The     existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}:
    _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8     dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc     qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54     handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40     generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0     el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8
    ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80     qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0     vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90     register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424     platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114     driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8
    __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0     device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8     of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac     geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 ... -> #0 (console_owner){-...}-{0:0}:
    __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454     console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc
    _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4     dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm]     msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c     drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Chain exists of: console_owner --> &port_lock_key -->     free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(free_entries_lock);
    lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace:
    dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24     print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c     lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated--- (CVE-2023-52516)

  - In the Linux kernel, the following vulnerability has been resolved: USB: sisusbvga: Add endpoint checks     The syzbot fuzzer was able to provoke a WARNING from the sisusbvga driver: ------------[ cut here     ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 1 PID: 26 at     drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU:
    1 PID: 26 Comm: kworker/1:1 Not tainted 6.2.0-rc5-syzkaller-00199-g5af6ce704936 #0 Hardware name: Google     Google Compute Engine/Google Compute Engine, BIOS Google 01/12/2023 Workqueue: usb_hub_wq hub_event RIP:
    0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 6c 50 80 fb 48 8b 7c 24 18     e8 62 1a 01 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 60 b1 fa 8a e8 84 b0 be 03 <0f> 0b e9 58 f8 ff     ff e8 3e 50 80 fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc90000a1ed18 EFLAGS: 00010282 RAX:
    0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff888012783a80 RSI: ffffffff816680ec     RDI: fffff52000143d95 RBP: ffff888079020000 R08: 0000000000000005 R09: 0000000000000000 R10:
    0000000080000000 R11: 0000000000000000 R12: 0000000000000003 R13: ffff888017d33370 R14: 0000000000000003     R15: ffff888021213600 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010     DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005592753a60b0 CR3: 0000000022899000 CR4: 00000000003506e0     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6:
    00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sisusb_bulkout_msg     drivers/usb/misc/sisusbvga/sisusbvga.c:224 [inline] sisusb_send_bulk_msg.constprop.0+0x904/0x1230     drivers/usb/misc/sisusbvga/sisusbvga.c:379 sisusb_send_bridge_packet     drivers/usb/misc/sisusbvga/sisusbvga.c:567 [inline] sisusb_do_init_gfxdevice     drivers/usb/misc/sisusbvga/sisusbvga.c:2077 [inline] sisusb_init_gfxdevice+0x87b/0x4000     drivers/usb/misc/sisusbvga/sisusbvga.c:2177 sisusb_probe+0x9cd/0xbe2     drivers/usb/misc/sisusbvga/sisusbvga.c:2869 ... The problem was caused by the fact that the driver does     not check whether the endpoints it uses are actually present and have the appropriate types. This can be     fixed by adding a simple check of the endpoints. (CVE-2023-54213)

  - In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: use the backlog     for mirred ingress The test Davide added in commit ca22da2fbd69 (act_mirred: use the backlog for nested     calls to mirred ingress) hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv ->     tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that     if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which     generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks     is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress ->     ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the     backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround     does not seem to address the issue. (CVE-2024-26740)

  - In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: fix a bug calling     wakeup_kswapd() with a wrong zone index With numa balancing on, when a numa system is running where a numa     node doesn't have its local memory so it has no managed zones, the following oops has been observed. It's     because wakeup_kswapd() is called with a wrong zone index, -1. Fixed it by checking the index before     calling wakeup_kswapd(). > BUG: unable to handle page fault for address: 00000000000033f3 > #PF:
    supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops:
    0000 [#1] PREEMPT SMP NOPTI > CPU: 2 PID: 895 Comm: masim Not tainted 6.6.0-dirty #255 > Hardware name:
    QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 >     RIP: 0010:wakeup_kswapd (./linux/mm/vmscan.c:7812) > Code: (omitted) > RSP: 0000:ffffc90004257d58 EFLAGS:
    00010286 > RAX: ffffffffffffffff RBX: ffff88883fff0480 RCX: 0000000000000003 > RDX: 0000000000000000 RSI:
    0000000000000000 RDI: ffff88883fff0480 > RBP: ffffffffffffffff R08: ff0003ffffffffff R09: ffffffffffffffff     > R10: ffff888106c95540 R11: 0000000055555554 R12: 0000000000000003 > R13: 0000000000000000 R14:
    0000000000000000 R15: ffff88883fff0940 > FS: 00007fc4b8124740(0000) GS:ffff888827c00000(0000)     knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00000000000033f3 CR3:
    000000026cc08004 CR4: 0000000000770ee0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000     > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > PKRU: 55555554 > Call Trace: >     <TASK> > ? __die > ? page_fault_oops > ? __pte_offset_map_lock > ? exc_page_fault > ? asm_exc_page_fault >     ? wakeup_kswapd > migrate_misplaced_page > __handle_mm_fault > handle_mm_fault > do_user_addr_fault >     exc_page_fault > asm_exc_page_fault > RIP: 0033:0x55b897ba0808 > Code: (omitted) > RSP:
    002b:00007ffeefa821a0 EFLAGS: 00010287 > RAX: 000055b89983acd0 RBX: 00007ffeefa823f8 RCX: 000055b89983acd0     > RDX: 00007fc2f8122010 RSI: 0000000000020000 RDI: 000055b89983acd0 > RBP: 00007ffeefa821a0 R08:
    0000000000000037 R09: 0000000000000075 > R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000     > R13: 00007ffeefa82410 R14: 000055b897ba5dd8 R15: 00007fc4b8340000 > </TASK> (CVE-2024-26783)

  - In the Linux kernel, the following vulnerability has been resolved: vfs: Don't evict inode under the inode     lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable     inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try     getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by     function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode     lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru     traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode     lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting     context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is     added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 >     /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg     prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state     inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink =     0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode     ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(i_ea) ---- AA deadlock dispose_list // cannot be executed by prune_icache_sb     wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file     deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode     reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting     function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a     xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added     into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 >     /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia     prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state     inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm     file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia)     make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast
    __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode |     ubifs_jnl_delete_inode(ib)  ubifs_jnl_write_inode ABBA deadlock -----make_reservation(BASEHD)     dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock     by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate(
    ---truncated--- (CVE-2024-45003)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
371577	Linux Distros 未修補弱點：CVE-2026-98985	Nessus	Misc.	2026/10/23	2026/11/13	medium
374135	AlmaLinux 9.2 [TuxCare] 安全性更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc多個弱點（ALMALINUX9.2：CLSA-2026：1793333110）	Nessus	Alma Linux Local Security Checks	2026/10/30	2026/11/2	high
371577	Linux Distros 未修补的漏洞：CVE-2026-98985	Nessus	Misc.	2026/10/23	2026/11/13	medium
374135	AlmaLinux 9.2 [TuxCare] 安全更新：bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / 等多个漏洞（ALMALINUX9.2：CLSA-2026：1793333110）	Nessus	Alma Linux Local Security Checks	2026/10/30	2026/11/2	high
371577	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98985	Nessus	Misc.	2026/10/23	2026/11/13	medium
374135	AlmaLinux 9.2 [TuxCare] セキュリティ更新プログラム:bpftool/kernel/kernel-64k/kernel-64k-core/kernel-64k-debug/etcの複数の脆弱性(ALMALINUX9.2:CLSA-2026:1793333110)	Nessus	Alma Linux Local Security Checks	2026/10/30	2026/11/2	high
371577	Linux Distros Unpatched Vulnerability : CVE-2026-98985	Nessus	Misc.	2026/10/23	2026/11/13	medium
379844	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2026-139)	Nessus	Amazon Linux Local Security Checks	2026/11/12	2026/11/12	critical
381339	Ubuntu 26.04 LTS : Linux kernel vulnerabilities (USN-9018-1)	Nessus	Ubuntu Local Security Checks	2026/11/14	2026/11/14	critical
377900	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3402)	Nessus	Amazon Linux Local Security Checks	2026/11/9	2026/11/11	high
380301	Debian dla-4904 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	2026/11/13	2026/11/13	high
374135	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1793333110)	Nessus	Alma Linux Local Security Checks	2026/10/30	2026/11/2	high
379876	Amazon Linux 2 : kernel (ALASKERNEL-5.15-2026-121)	Nessus	Amazon Linux Local Security Checks	2026/11/12	2026/11/12	critical

偵測

搜尋 Plugin

medium

high

medium

high

medium

high

medium

critical

critical

high

high

high

critical