In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as "before(mh->seq, seq)" will stop to check for older sequence numbers that are ordered in the tail of "node->send_queue". The side effects of not having it correct ordered regarding "before(mh->seq, seq)" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.

An update of the linux package has been released.

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.

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

  - In the Linux kernel, the following vulnerability has been resolved: udf: Avoid double brelse() in     udf_rename() syzbot reported a warning like below [1]: VFS: brelse: Trying to free free buffer WARNING:
    CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace: <TASK>     invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ?     generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ?     smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ?
    __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80     blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760     deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0     task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ?     reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ?     rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0
    __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause     of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it     returns NULL. However, brelse() is called by udf_rename(), too. So, b_count on buffer_head becomes     unbalanced. This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry()     returns NULL. (CVE-2022-50755)

  - In the Linux kernel, the following vulnerability has been resolved: soc: qcom: qmi_encdec: Restrict string     length in decode The QMI TLV value for strings in a lot of qmi element info structures account for null     terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of     bounds access when the NULL character is appended in decoding. (CVE-2023-53729)

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: check CAN address family     in isotp_bind() Add missing check to block non-AF_CAN binds. Syzbot created some code which matched the     right sockaddr struct size but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family field:
    bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^ This has no funtional impact but the     userspace should be notified about the wrong address family field content. (CVE-2023-54105)

  - In the Linux kernel, the following vulnerability has been resolved: usb: rndis_host: Secure rndis_query     check against int overflow Variables off and len typed as uint32 in rndis_query function are controlled by     incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large     value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently     the response pointer will be referring to a location past the expected buffer boundaries allowing     information leakage e.g. via RNDIS_OID_802_3_PERMANENT_ADDRESS OID. (CVE-2023-54110)

  - In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: Fix shift-out-of-bounds     in spi_nor_set_erase_type spi_nor_set_erase_type() was used either to set or to mask out an erase type.
    When we used it to mask out an erase type a shift-out-of-bounds was hit: UBSAN: shift-out-of-bounds in     drivers/mtd/spi-nor/core.c:2237:24 shift exponent 4294967295 is too large for 32-bit type 'int' The     setting of the size_{shift, mask} and of the opcode are unnecessary when the erase size is zero, as     throughout the code just the erase size is considered to determine whether an erase type is supported or     not. Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF is an unused opcode. Thus     when masking out an erase type, just set the erase size to zero. This will fix the shift-out-of-bounds.
    [ta: refine changes, new commit message, fix compilation error] (CVE-2023-54295)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: udf: Avoid double brelse() in     udf_rename() syzbot reported a warning like below [1]: VFS: brelse: Trying to free free buffer WARNING:
    CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace: <TASK>     invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ?     generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ?     smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ?
    __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80     blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760     deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0     task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ?     reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ?     rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0
    __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause     of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it     returns NULL. However, brelse() is called by udf_rename(), too. So, b_count on buffer_head becomes     unbalanced. This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry()     returns NULL. (CVE-2022-50755)

  - In the Linux kernel, the following vulnerability has been resolved: soc: qcom: qmi_encdec: Restrict string     length in decode The QMI TLV value for strings in a lot of qmi element info structures account for null     terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of     bounds access when the NULL character is appended in decoding. (CVE-2023-53729)

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: check CAN address family     in isotp_bind() Add missing check to block non-AF_CAN binds. Syzbot created some code which matched the     right sockaddr struct size but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family field:
    bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^ This has no funtional impact but the     userspace should be notified about the wrong address family field content. (CVE-2023-54105)

  - In the Linux kernel, the following vulnerability has been resolved: usb: rndis_host: Secure rndis_query     check against int overflow Variables off and len typed as uint32 in rndis_query function are controlled by     incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large     value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently     the response pointer will be referring to a location past the expected buffer boundaries allowing     information leakage e.g. via RNDIS_OID_802_3_PERMANENT_ADDRESS OID. (CVE-2023-54110)

  - In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: Fix shift-out-of-bounds     in spi_nor_set_erase_type spi_nor_set_erase_type() was used either to set or to mask out an erase type.
    When we used it to mask out an erase type a shift-out-of-bounds was hit: UBSAN: shift-out-of-bounds in     drivers/mtd/spi-nor/core.c:2237:24 shift exponent 4294967295 is too large for 32-bit type 'int' The     setting of the size_{shift, mask} and of the opcode are unnecessary when the erase size is zero, as     throughout the code just the erase size is considered to determine whether an erase type is supported or     not. Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF is an unused opcode. Thus     when masking out an erase type, just set the erase size to zero. This will fix the shift-out-of-bounds.
    [ta: refine changes, new commit message, fix compilation error] (CVE-2023-54295)

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

The remote Ubuntu 24.04 LTS / 26.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-8816-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:

    - ARM64 architecture;

    - S390 architecture;

    - x86 architecture;

    - DRBD Distributed Replicated Block Device drivers;

    - InfiniBand drivers;

    - IOMMU subsystem;

    - Multiple devices driver;

    - Network drivers;

    - Microsoft Azure Network Adapter (MANA) driver;

    - NVME drivers;

    - TCM subsystem;

    - Virtio Host (VHOST) subsystem;

    - Xen hypervisor drivers;

    - AFS file system;

    - File systems infrastructure;

    - Network file systems library;

    - Network file system (NFS) client;

    - NTFS3 file system;

    - OCFS2 file system;

    - OrangeFS file system;

    - SMB network file system;

    - IPv4 networking;

    - Sun RPC protocol;

    - IPv6 networking;

    - IP tunnels definitions;

    - Netfilter;

    - TCP network protocol;

    - Locking primitives;

    - 9P file system network protocol;

    - B.A.T.M.A.N. meshing protocol;

    - Networking core;

    - IFE protocol;

    - RxRPC session sockets;

    - Network traffic control;

    - SCTP protocol;

    - SMC sockets;

    - TIPC protocol;

    - XFRM subsystem; (CVE-2026-64530, CVE-2026-64534, CVE-2026-64535, CVE-2026-64541, CVE-2026-64551,     CVE-2026-68083, CVE-2026-68457, CVE-2026-68476, CVE-2026-68477, CVE-2026-72014, CVE-2026-72020,     CVE-2026-72033, CVE-2026-72041, CVE-2026-72046, CVE-2026-72064, CVE-2026-72065, CVE-2026-72069,     CVE-2026-72083, CVE-2026-72084, CVE-2026-72085, CVE-2026-72098, CVE-2026-72129, CVE-2026-72130,     CVE-2026-72137, CVE-2026-72139, CVE-2026-72191, CVE-2026-72192, CVE-2026-72194, CVE-2026-72217,     CVE-2026-72220, CVE-2026-72221, CVE-2026-72222, CVE-2026-72226, CVE-2026-72234, CVE-2026-72248,     CVE-2026-72249, CVE-2026-72251, CVE-2026-72277, CVE-2026-72278, CVE-2026-72279, CVE-2026-72287,     CVE-2026-72288, CVE-2026-72289, CVE-2026-72296, CVE-2026-72299, CVE-2026-72317, CVE-2026-72318,     CVE-2026-72319, CVE-2026-72320, CVE-2026-72322, CVE-2026-72323, CVE-2026-72329, CVE-2026-72339,     CVE-2026-72348, CVE-2026-72351, CVE-2026-72355, CVE-2026-72366, CVE-2026-72381, CVE-2026-72393,     CVE-2026-72398, CVE-2026-72399, CVE-2026-72412, CVE-2026-72417, CVE-2026-72422, CVE-2026-72429,     CVE-2026-72436, CVE-2026-72442, CVE-2026-72451, CVE-2026-72463, CVE-2026-72466, CVE-2026-72472,     CVE-2026-72473, CVE-2026-72477, CVE-2026-72491, CVE-2026-72493, CVE-2026-72494, CVE-2026-72495,     CVE-2026-72496, CVE-2026-72501, CVE-2026-74255, CVE-2026-74267, CVE-2026-74268, CVE-2026-74269,     CVE-2026-74287, CVE-2026-74310, CVE-2026-74345, CVE-2026-74350, CVE-2026-74361, CVE-2026-74376,     CVE-2026-74384, CVE-2026-74394, CVE-2026-74398, CVE-2026-74401, CVE-2026-74406, CVE-2026-74427,     CVE-2026-74428, CVE-2026-74433, CVE-2026-74434, CVE-2026-74436, CVE-2026-74439, CVE-2026-80665)

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 Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-8781-1 advisory.

    It was discovered that some Arm processors could complete a broadcast translation lookaside buffer (TLB)     invalidation before memory writes made through the invalidated translation were globally observed. A local     attacker could possibly use this to write to memory after permission to do so had been revoked, bypassing     memory protections or escalating privileges. (CVE-2025-10263)

    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:

    - ARM64 architecture;

    - User-space API (UAPI);

    - Kernel build system;

    - ARM32 architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - S390 architecture;

    - User-Mode Linux (UML);

    - x86 architecture;

    - Cryptographic API;

    - Intel NPU Driver;

    - Compute Acceleration Framework;

    - ACPI drivers;

    - Drivers core;

    - DRBD Distributed Replicated Block Device drivers;

    - Rados block device (RBD) driver;

    - Ublk userspace block driver;

    - Compressed RAM block device driver;

    - Bluetooth drivers;

    - Hardware crypto device drivers;

    - CXL (Compute Express Link) drivers;

    - Arm Firmware Framework for ARMv8-A(FFA);

    - EFI core;

    - FPGA Framework;

    - GPU drivers;

    - HID subsystem;

    - Hardware monitoring drivers;

    - I2C subsystem;

    - I3C subsystem;

    - InfiniBand drivers;

    - Input Device core drivers;

    - Input Device (Mouse) drivers;

    - IOMMU subsystem;

    - Multiple devices driver;

    - Media drivers;

    - Fastrpc Driver;

    - Network drivers;

    - Mellanox network drivers;

    - Microsoft Azure Network Adapter (MANA) driver;

    - MediaTek network drivers;

    - NVME drivers;

    - Operating Performance Points (OPP) driver;

    - PCI subsystem;

    - PTP clock framework;

    - RPMSG subsystem;

    - SCSI subsystem;

    - SoundWire subsystem;

    - SPI subsystem;

    - Greybus lights staging drivers;

    - Media staging drivers;

    - NVIDIA Tegra embedded controller (NVEC) staging driver;

    - Realtek RTL8723BS SDIO drivers;

    - TCM subsystem;

    - Trusted Execution Environment drivers;

    - Thunderbolt and USB4 drivers;

    - TTY drivers;

    - USB Gadget drivers;

    - USB Dual Role (OTG-ready) Controller drivers;

    - USB Serial drivers;

    - vDPA drivers;

    - VFIO drivers;

    - Virtio Host (VHOST) subsystem;

    - Virtio drivers;

    - Xen hypervisor drivers;

    - 9P distributed file system;

    - AFS file system;

    - File systems infrastructure;

    - BTRFS file system;

    - Ceph distributed file system;

    - exFAT file system;

    - F2FS file system;

    - GFS2 file system;

    - HFS file system;

    - HFS+ file system;

    - JFS file system;

    - Network file systems library;

    - Network file system (NFS) client;

    - Network file system (NFS) server daemon;

    - NTFS3 file system;

    - OCFS2 file system;

    - OrangeFS file system;

    - SMB network file system;

    - BPF subsystem;

    - File system encryption (fscrypt);

    - Software nodes and device properties;

    - IPv4 networking;

    - KVM subsystem;

    - Mellanox drivers;

    - Memory management;

    - Networking core;

    - Netfilter;

    - Socket messages infrastructure;

    - MediaTek SoC drivers;

    - Sun RPC protocol;

    - Network traffic control;

    - IPv6 networking;

    - Amateur Radio drivers;

    - Bluetooth subsystem;

    - IP tunnels definitions;

    - KCM (Kernel Connection Multiplexor) sockets driver;

    - MultiProtocol Label Switching driver;

    - TCP network protocol;

    - XFRM subsystem;

    - Tracing infrastructure;

    - io_uring subsystem;

    - Control group (cgroup);

    - Perf events;

    - IRQ subsystem;

    - Locking primitives;

    - KProbes tracing;

    - 9P file system network protocol;

    - B.A.T.M.A.N. meshing protocol;

    - Ethernet bridge;

    - CAN network layer;

    - Ceph Core library;

    - Handshake API;

    - HSR network protocol;

    - IFE protocol;

    - L2TP protocol;

    - MAC80211 subsystem;

    - IEEE 802.15.4 subsystem;

    - Multipath TCP;

    - NFC subsystem;

    - Open vSwitch;

    - Phonet protocol;

    - RDS protocol;

    - RxRPC session sockets;

    - SCTP protocol;

    - SMC sockets;

    - TIPC protocol;

    - TLS protocol;

    - Unix domain sockets;

    - VMware vSockets driver;

    - Wireless networking;

    - X.25 network layer;

    - eXpress Data Path;

    - Rust bindings mechanism;

    - AppArmor security module;

    - Key management;

    - Linux Security Modules (LSM) Framework;

    - SELinux security module;

    - ALSA framework;

    - AudioScience HPI driver;

    - Intel ASoC drivers;

    - USB sound devices; (CVE-2024-14040, CVE-2024-35948, CVE-2024-41008, CVE-2024-43872, CVE-2024-44932,     CVE-2024-44964, CVE-2024-49932, CVE-2024-49940, CVE-2024-50106, CVE-2024-50217, CVE-2024-52560,     CVE-2024-53098, CVE-2024-56552, CVE-2024-56591, CVE-2024-57857, CVE-2024-58089, CVE-2024-58094,     CVE-2024-58098, CVE-2024-58100, CVE-2024-58241, CVE-2025-21687, CVE-2025-21693, CVE-2025-21984,     CVE-2025-21985, CVE-2025-22104, CVE-2025-22108, CVE-2025-22109, CVE-2025-23132, CVE-2025-37776,     CVE-2025-37876, CVE-2025-37906, CVE-2025-38064, CVE-2025-38069, CVE-2025-38187, CVE-2025-38204,     CVE-2025-38206, CVE-2025-38242, CVE-2025-38498, CVE-2025-38563, CVE-2025-38565, CVE-2025-38636,     CVE-2025-38717, CVE-2025-39677, CVE-2025-39789, CVE-2025-39859, CVE-2025-39862, CVE-2025-39896,     CVE-2025-39933, CVE-2025-39958, CVE-2025-39990, CVE-2025-40025, CVE-2025-40040, CVE-2025-40054,     CVE-2025-40064, CVE-2025-40074, CVE-2025-40075, CVE-2025-40139, CVE-2025-40158, CVE-2025-40168,     CVE-2025-40170, CVE-2025-40203, CVE-2025-40274, CVE-2025-40344, CVE-2025-40354, CVE-2025-68174,     CVE-2025-68304, CVE-2025-68360, CVE-2025-68745, CVE-2025-68822, CVE-2025-71073, CVE-2025-71074,     CVE-2025-71202, CVE-2025-71289, CVE-2026-23208, CVE-2026-23239, CVE-2026-23240, CVE-2026-23327,     CVE-2026-23393, CVE-2026-23469, CVE-2026-31420, CVE-2026-31479, CVE-2026-31486, CVE-2026-31493,     CVE-2026-31560, CVE-2026-31568, CVE-2026-31630, CVE-2026-31663, CVE-2026-31771, CVE-2026-43009,     CVE-2026-43029, CVE-2026-43042, CVE-2026-43048, CVE-2026-43101, CVE-2026-43116, CVE-2026-43126,     CVE-2026-43172, CVE-2026-43213, CVE-2026-43263, CVE-2026-43303, CVE-2026-43352, CVE-2026-43353,     CVE-2026-43464, CVE-2026-45850, CVE-2026-45894, CVE-2026-45932, CVE-2026-45944, CVE-2026-46054,     CVE-2026-46130, CVE-2026-46158, CVE-2026-46170, CVE-2026-46175, CVE-2026-46181, CVE-2026-46203,     CVE-2026-46275, CVE-2026-46315, CVE-2026-46320, CVE-2026-46324, CVE-2026-46330, CVE-2026-52908,     CVE-2026-52909, CVE-2026-52910, CVE-2026-52912, CVE-2026-52915, CVE-2026-52916, CVE-2026-52918,     CVE-2026-52919, CVE-2026-52921, CVE-2026-52922, CVE-2026-52926, CVE-2026-52934, CVE-2026-52941,     CVE-2026-52956, CVE-2026-52988, CVE-2026-52991, CVE-2026-53000, CVE-2026-53005, CVE-2026-53009,     CVE-2026-53024, CVE-2026-53025, CVE-2026-53053, CVE-2026-53070, CVE-2026-53078, CVE-2026-53089,     CVE-2026-53090, CVE-2026-53091, CVE-2026-53109, CVE-2026-53118, CVE-2026-53120, CVE-2026-53129,     CVE-2026-53131, CVE-2026-53132, CVE-2026-53133, CVE-2026-53148, CVE-2026-53159, CVE-2026-53182,     CVE-2026-53183, CVE-2026-53185, CVE-2026-53186, CVE-2026-53196, CVE-2026-53198, CVE-2026-53216,     CVE-2026-53217, CVE-2026-53221, CVE-2026-53230, CVE-2026-53232, CVE-2026-53239, CVE-2026-53250,     CVE-2026-53254, CVE-2026-53256, CVE-2026-53262, CVE-2026-53264, CVE-2026-53266, CVE-2026-53269,     CVE-2026-53270, CVE-2026-53273, CVE-2026-53275, CVE-2026-53281, CVE-2026-53284, CVE-2026-53354,     CVE-2026-53355, CVE-2026-53357, CVE-2026-53358, CVE-2026-53361, CVE-2026-53368, CVE-2026-53384,     CVE-2026-53398, CVE-2026-53399, CVE-2026-63795, CVE-2026-63796, CVE-2026-63797, CVE-2026-63800,     CVE-2026-63801, CVE-2026-63804, CVE-2026-63807, CVE-2026-63808, CVE-2026-63815, CVE-2026-63818,     CVE-2026-63825, CVE-2026-63828, CVE-2026-63829, CVE-2026-63830, CVE-2026-63831, CVE-2026-63853,     CVE-2026-63858, CVE-2026-63886, CVE-2026-63887, CVE-2026-63888, CVE-2026-63893, CVE-2026-63906,     CVE-2026-63912, CVE-2026-63914, CVE-2026-63915, CVE-2026-63916, CVE-2026-63917, CVE-2026-63919,     CVE-2026-63921, CVE-2026-63922, CVE-2026-63924, CVE-2026-63926, CVE-2026-63940, CVE-2026-63944,     CVE-2026-63945, CVE-2026-63946, CVE-2026-63947, CVE-2026-63948, CVE-2026-63952, CVE-2026-63974,     CVE-2026-63975, CVE-2026-63976, CVE-2026-63978, CVE-2026-63979, CVE-2026-63980, CVE-2026-63984,     CVE-2026-63992, CVE-2026-63993, CVE-2026-63994, CVE-2026-64000, CVE-2026-64007, CVE-2026-64010,     CVE-2026-64011, CVE-2026-64015, CVE-2026-64018, CVE-2026-64025, CVE-2026-64029, CVE-2026-64032,     CVE-2026-64033, CVE-2026-64034, CVE-2026-64039, CVE-2026-64046, CVE-2026-64047, CVE-2026-64048,     CVE-2026-64051, CVE-2026-64055, CVE-2026-64056, CVE-2026-64064, CVE-2026-64073, CVE-2026-64076,     CVE-2026-64077, CVE-2026-64082, CVE-2026-64083, CVE-2026-64084, CVE-2026-64085, CVE-2026-64086,     CVE-2026-64087, CVE-2026-64088, CVE-2026-64089, CVE-2026-64091, CVE-2026-64092, CVE-2026-64093,     CVE-2026-64096, CVE-2026-64097, CVE-2026-64098, CVE-2026-64099, CVE-2026-64102, CVE-2026-64103,     CVE-2026-64106, CVE-2026-64108, CVE-2026-64109, CVE-2026-64111, CVE-2026-64112, CVE-2026-64113,     CVE-2026-64114, CVE-2026-64115, CVE-2026-64116, CVE-2026-64117, CVE-2026-64118, CVE-2026-64121,     CVE-2026-64125, CVE-2026-64126, CVE-2026-64127, CVE-2026-64128, CVE-2026-64133, CVE-2026-64134,     CVE-2026-64135, CVE-2026-64136, CVE-2026-64137, CVE-2026-64138, CVE-2026-64144, CVE-2026-64147,     CVE-2026-64148, CVE-2026-64153, CVE-2026-64155, CVE-2026-64160, CVE-2026-64163, CVE-2026-64165,     CVE-2026-64166, CVE-2026-64168, CVE-2026-64170, CVE-2026-64173, CVE-2026-64174, CVE-2026-64177,     CVE-2026-64178, CVE-2026-64179, CVE-2026-64180, CVE-2026-64182, CVE-2026-64183, CVE-2026-64184,     CVE-2026-64185, CVE-2026-64191, CVE-2026-64206, CVE-2026-64214, CVE-2026-64217, CVE-2026-64218,     CVE-2026-64219, CVE-2026-64220, CVE-2026-64221, CVE-2026-64225, CVE-2026-64231, CVE-2026-64237,     CVE-2026-64247, CVE-2026-64249, CVE-2026-64268, CVE-2026-64269, CVE-2026-64280, CVE-2026-64303,     CVE-2026-64313, CVE-2026-64315, CVE-2026-64319, CVE-2026-64320, CVE-2026-64355, CVE-2026-64361,     CVE-2026-64364, CVE-2026-64382, CVE-2026-64383, CVE-2026-64384, CVE-2026-64385, CVE-2026-64386,     CVE-2026-64387, CVE-2026-64390, CVE-2026-64391, CVE-2026-64392, CVE-2026-64393, CVE-2026-64394,     CVE-2026-64396, CVE-2026-64397, CVE-2026-64399, CVE-2026-64400, CVE-2026-64408, CVE-2026-64438,     CVE-2026-64441, CVE-2026-64445, CVE-2026-64450, CVE-2026-64475, CVE-2026-64510, CVE-2026-64518,     CVE-2026-64523, CVE-2026-64529, CVE-2026-64530, CVE-2026-64534, CVE-2026-64535, CVE-2026-64541,     CVE-2026-64548, CVE-2026-64551, CVE-2026-64552, CVE-2026-64554, CVE-2026-64555, CVE-2026-64557,     CVE-2026-64561, CVE-2026-64562, CVE-2026-64564, CVE-2026-64586, CVE-2026-64597, CVE-2026-64598,     CVE-2026-68082, CVE-2026-68083, CVE-2026-68117, CVE-2026-68123, CVE-2026-68124, CVE-2026-68127,     CVE-2026-68136, CVE-2026-68137, CVE-2026-68138, CVE-2026-68144, CVE-2026-68147, CVE-2026-68152,     CVE-2026-68154, CVE-2026-68156, CVE-2026-68158, CVE-2026-68159, CVE-2026-68160, CVE-2026-68161,     CVE-2026-68162, CVE-2026-68198, CVE-2026-68206, CVE-2026-68209, CVE-2026-68210, CVE-2026-68213,     CVE-2026-68228, CVE-2026-68229, CVE-2026-68300, CVE-2026-68302, CVE-2026-68343, CVE-2026-68381,     CVE-2026-68388, CVE-2026-68426, CVE-2026-68431, CVE-2026-68457, CVE-2026-68461, CVE-2026-68470,     CVE-2026-68476, CVE-2026-68477, CVE-2026-72014, CVE-2026-72020, CVE-2026-72033, CVE-2026-72041,     CVE-2026-72065, CVE-2026-72069, CVE-2026-72071, CVE-2026-72083, CVE-2026-72084, CVE-2026-72085,     CVE-2026-72098, CVE-2026-72111, CVE-2026-72124, CVE-2026-72125, CVE-2026-72126, CVE-2026-72129,     CVE-2026-72130, CVE-2026-72191, CVE-2026-72192, CVE-2026-72194, CVE-2026-72200, CVE-2026-72217,     CVE-2026-72221, CVE-2026-72222, CVE-2026-72226, CVE-2026-72234, CVE-2026-72251, CVE-2026-72255,     CVE-2026-72288, CVE-2026-72289, CVE-2026-72296, CVE-2026-72299, CVE-2026-72317, CVE-2026-72318,     CVE-2026-72319, CVE-2026-72320, CVE-2026-72322, CVE-2026-72323, CVE-2026-72329, CVE-2026-72339,     CVE-2026-72348, CVE-2026-72351, CVE-2026-72380, CVE-2026-72383, CVE-2026-72398, CVE-2026-72399,     CVE-2026-72421, CVE-2026-72422, CVE-2026-72434, CVE-2026-72436, CVE-2026-72451, CVE-2026-72454,     CVE-2026-72466, CVE-2026-72472, CVE-2026-72473, CVE-2026-72487, CVE-2026-72488, CVE-2026-72489,     CVE-2026-72491, CVE-2026-72494, CVE-2026-72495, CVE-2026-72496, CVE-2026-72499, CVE-2026-74255,     CVE-2026-74264, CVE-2026-74267, CVE-2026-74268, CVE-2026-74269, CVE-2026-74279, CVE-2026-74280,     CVE-2026-74287, CVE-2026-74302, CVE-2026-74305, CVE-2026-74310, CVE-2026-74345, CVE-2026-74350,     CVE-2026-74376, CVE-2026-74384, CVE-2026-74394, CVE-2026-74398, CVE-2026-74401, CVE-2026-74405,     CVE-2026-74406, CVE-2026-74407, CVE-2026-74408, CVE-2026-74410, CVE-2026-74411, CVE-2026-74417,     CVE-2026-74427, CVE-2026-74436, CVE-2026-74439, CVE-2026-74440, CVE-2026-74473, CVE-2026-74474,     CVE-2026-74475, CVE-2026-74476, CVE-2026-74478, CVE-2026-74480, CVE-2026-74493, CVE-2026-74495,     CVE-2026-74521, CVE-2026-74538, CVE-2026-74541, CVE-2026-74556, CVE-2026-74569)

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 Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that     triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the     oldest seq number. This ordering is required by dlm_receive_ack as before(mh->seq, seq) will stop to     check for older sequence numbers that are ordered in the tail of node->send_queue. The side effects of     not having it correct ordered regarding before(mh->seq, seq) are refcounting issues and use-after free.
    I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that     uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues     anymore. (CVE-2026-74401)

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

ID	Name	Product	Family	Type	Severity
377578	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel (NVIDIA) vulnerabilities (USN-9003-1)	Nessus	Ubuntu Local Security Checks	Local	medium
375639	Photon OS 5.0: Linux PHSA-2026-5.0-91-0960	Nessus	PhotonOS Local Security Checks	Local	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	Local	high
373068	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793100968)	Nessus	Rocky Linux Local Security Checks	Local	high
373062	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793100968)	Nessus	Alma Linux Local Security Checks	Local	high
365768	Ubuntu 26.04 LTS : Linux kernel (Azure) vulnerabilities (USN-8888-1)	Nessus	Ubuntu Local Security Checks	Local	medium
365525	Ubuntu 24.04 LTS : Linux kernel (Azure) vulnerabilities (USN-8918-1)	Nessus	Ubuntu Local Security Checks	Local	medium
365522	Ubuntu 24.04 LTS : Linux kernel vulnerabilities (USN-8917-1)	Nessus	Ubuntu Local Security Checks	Local	medium
350177	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8816-1)	Nessus	Ubuntu Local Security Checks	Local	critical
348386	Ubuntu 24.04 LTS / Pro Realtime 24.04 LTS : Linux kernel (NVIDIA Tegra) vulnerabilities (USN-8781-1)	Nessus	Ubuntu Local Security Checks	Local	high
343049	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500248)	Nessus	Oracle Linux Local Security Checks	Local	high
335602	Linux Distros Unpatched Vulnerability : CVE-2026-74401	Nessus	Misc.	Local	critical
334784	Photon OS 5.0: Linux PHSA-2026-5.0-92-0952	Nessus	PhotonOS Local Security Checks	Local	high

Detections

Analytics

CVE-2026-74401

critical

Tenable Plugins

medium

high

high

high

high

medium

medium

medium

critical

high

high

critical

high