In the Linux kernel, the following vulnerability has been resolved: ceph: bound copied dentry name length in NFS export get_name ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0, without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same unchecked way. Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS mount is re-exported over NFS. Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name().

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-146717 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    ceph: bound copied dentry name length in NFS export get_name

    ceph_get_name() copies the MDS-supplied name into the caller's     NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len)     and then writes name[rinfo->dname_len] = 0, without checking dname_len     against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply     with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies     rde->name / rde->name_len the same unchecked way.

    Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name     buffer in a client's NFS-export get_name path, a slab out-of-bounds write     reported by KASAN. Reachable when a CephFS mount is re-exported over NFS.

    Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with
    -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and
    __get_snap_name().

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

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

The CentOS Linux 8.4 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS8.4:CLSA-2026:1794319150 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Repost Receive buffers for     malformed replies rpcrdma_wc_receive() decrements the transport's Receive count for every completion     before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement     Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.
    Commit 2ae50ad68cd7 (xprtrdma: Close window between waking RPC senders and posting Receives) moved the     Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into     rpcrdma_reply_handler() so that the responder's credit grant could be parsed before reposting. The bad-     version and short-reply exits never reach that refill: they recycle the rep and return without calling     rpcrdma_post_recvs(). A remote peer can therefore drain the client's posted Receive queue by sending a     sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized     RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue     empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect. Route both     malformed-reply exits through the shared repost tail after recycling the rep, refilling against     buf->rb_credits, the most recent accepted credit grant. Neither exit updates the congestion window, so     RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would     let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the     congestion window still admits rb_credits RPCs; a burst of valid replies to those RPCs could then overrun     the posted Receives, and because the client connects with rnr_retry_count of zero, a single RNR NAK     terminates the connection. Refilling against rb_credits also restores the target that applied to malformed     replies before commit 2ae50ad68cd7 (xprtrdma: Close window between waking RPC senders and posting     Receives) when rpcrdma_post_recvs() computed it from rb_credits internally. rb_credits is at least one     from connection establishment onward, so the repost path always keeps Receives posted. (CVE-2026-72464)

  - In the Linux kernel, the following vulnerability has been resolved: sctp: check RCV_SHUTDOWN after the     sendmsg connect wait sctp_wait_for_connect() drops the socket lock while it sleeps. An out-of-the-blue     ABORT can then be processed from the socket backlog and unlink the association. If a concurrent     shutdown(fd, SHUT_RD) sets RCV_SHUTDOWN, the waiter breaks with err == 0 before checking asoc->base.dead.
    Its final sctp_association_put() can then free the association, leaving sctp_sendmsg_to_asoc() to continue     with a dangling pointer. Check RCV_SHUTDOWN along with the wait error in sctp_sendmsg_to_asoc() before     using the association again. The check only accesses the socket, so it needs no additional association     reference. Return the existing -ESRCH so that sctp_sendmsg() skips freeing a new association that may     already have been destroyed. Keep sctp_wait_for_connect() unchanged to preserve its behavior for the     connect() caller. (CVE-2026-98846)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: restrict socket queue dumps in     enqueue tracepoints tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is owned by user     context. The spinlock protects the backlog queue in this path, but it does not serialize against the     socket owner consuming or purging sk_receive_queue. KASAN reported: CPU: 14 UID: 0 PID: 1050 Comm: tipc3     Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS     1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123     print_report+0xce/0x5b0 mm/kasan/report.c:482 kasan_report+0xc6/0x100 mm/kasan/report.c:597
    __asan_report_load4_noabort+0x14/0x30 mm/kasan/report_generic.c:380 tipc_skb_dump+0x1327/0x16f0     net/tipc/trace.c:73 tipc_list_dump+0x208/0x2e0 net/tipc/trace.c:187 tipc_sk_dump+0xaf6/0xd60     net/tipc/socket.c:3996 trace_event_raw_event_tipc_sk_class+0x312/0x5a0 net/tipc/trace.h:188     tipc_sk_rcv+0xb1d/0x1d50 net/tipc/socket.c:2497 tipc_node_xmit+0x1c3/0x1440 net/tipc/node.c:1689
    __tipc_sendmsg+0x97a/0x1440 net/tipc/socket.c:1512 tipc_sendmsg+0x52/0x80 net/tipc/socket.c:1400     sock_sendmsg+0x2f6/0x3e0 net/socket.c:825 splice_to_socket+0x7f9/0x1010 fs/splice.c:884     do_splice+0xe21/0x2330 fs/splice.c:936 __do_splice+0x153/0x260 fs/splice.c:1431
    __x64_sys_splice+0x150/0x230 fs/splice.c:1616 x64_sys_call+0xeb5/0x2790 arch/x86/entry/syscall_64.c:41     do_syscall_64+0xf3/0x620 arch/x86/entry/syscall_64.c:63 entry_SYSCALL_64_after_hwframe+0x76/0x7e     arch/x86/entry/entry_64.S:130 RIP: 0033:0x71624e8aafe2 Code: 08 0f 85 71 3a ff ff 49 89 fb 48 89 f0 48 89     d7 48 89 ce 4c 89 c2 4d 89 ca 4c 8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05 <c3> 66 2e 0f 1f 84 00 00     00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 RSP: 002b:0000716157ffed68 EFLAGS: 00000246 ORIG_RAX:
    0000000000000113 RAX: ffffffffffffffda RBX: 0000716157fff6c0 RCX: 000071624e8aafe2 RDX: 000000000000005f     RSI: 0000000000000000 RDI: 0000000000000066 RBP: 0000716157ffed90 R08: 0000000000008000 R09:
    0000000000000001 R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffff00 R13: 0000000000000021     R14: 0000000000000000 R15: 00007fff89799c40 </TASK> The TIPC_DUMP_ALL tracepoints in tipc_sk_enqueue()     also dump sk_receive_queue and can therefore dereference skbs that the socket owner has already dequeued     or freed. Restrict these dumps to TIPC_DUMP_SK_BKLGQ, which matches the queue protected by the held     spinlock. Keep the change limited to the enqueue path, where the unsafe queue dump is reachable while the     socket is owned by user context. (CVE-2026-72299)

  - In the Linux kernel, the following vulnerability has been resolved: ceph: bound copied dentry name length     in NFS export get_name ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized     buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0,     without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with     dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same     unchecked way. Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a     client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS     mount is re-exported over NFS. Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with
    -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name(). (CVE-2026-89652)

  - In the Linux kernel, the following vulnerability has been resolved: nfsd: reject out-of-range nseconds in     NFSv3 SETATTR and create ops A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying     an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes     cleanly into a valid uint32, but it is not a valid timespec64: tv_nsec must be less than NSEC_PER_SEC.
    Nothing in the setattr path clamps it. notify_change() runs the time through timestamp_truncate(), which     does not reduce tv_nsec below NSEC_PER_SEC when the filesystem supports nanosecond granularity     (s_time_gran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via     inode_set_ctime_to_ts()). The un-normalized value then corrupts on-disk metadata: ext4's     ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which overflows the 32-bit extra field     and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS     with bigtime mis-stores the timestamp for the same reason. Validate the client-supplied atime/mtime in the     proc handlers and return NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL for     SETATTR and describes it as the error for a value the server 'can not store ... in its own     representation'; the client maps it to EINVAL. Checking in the proc handlers, rather than in     nfsd_setattr(), keeps the rejection in front of object creation. The create operations create the object     before nfsd_create_setattr() runs, so a late failure would leave the new object behind and turn a non-     idempotent request into a namespace change that reports failure. The check is therefore done up front, for     the create operations before the object is created. tv_nsec is a long, so the comparison casts it to     unsigned long (the same width) rather than to u32, matching timespec64_valid(). A u32 cast would truncate     on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire     nseconds was assigned to a 32-bit long. Only client-supplied times are checked: SET_TO_SERVER_TIME     requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard     simply never matches the object's ctime and yields NFS3ERR_NOT_SYNC via the existing guardtime comparison,     which is the protocol-correct outcome rather than rejecting the request. (CVE-2026-89666)

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-151297 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    ceph: bound copied dentry name length in NFS export get_name

    ceph_get_name() copies the MDS-supplied name into the caller's     NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len)     and then writes name[rinfo->dname_len] = 0, without checking dname_len     against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply     with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies     rde->name / rde->name_len the same unchecked way.

    Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name     buffer in a client's NFS-export get_name path, a slab out-of-bounds write     reported by KASAN. Reachable when a CephFS mount is re-exported over NFS.

    Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with
    -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and
    __get_snap_name().

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

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

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

    It was discovered that the io_uring subsystem in the Linux kernel did not properly handle canceled task     work when processing certain wait operations, leading to the operation being performed in the wrong task     context. A local attacker could possibly use this to cause a denial of service (system crash).
    (CVE-2026-81010)

    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:

    - ARM32 architecture;

    - ARM64 architecture;

    - MIPS architecture;

    - OpenRISC architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - S390 architecture;

    - x86 architecture;

    - Intel NPU Driver;

    - ACPI drivers;

    - Serial ATA and Parallel ATA drivers;

    - Auxiliary display drivers;

    - Ublk userspace block driver;

    - Bluetooth drivers;

    - Character device driver;

    - CPU idle management framework;

    - Hardware crypto device drivers;

    - CXL (Compute Express Link) drivers;

    - ARM SCMI message protocol;

    - GPIO subsystem;

    - GPU drivers;

    - HID subsystem;

    - HSI subsystem;

    - Hardware monitoring drivers;

    - I2C subsystem;

    - I3C subsystem;

    - IIO subsystem;

    - InfiniBand drivers;

    - Input Device core drivers;

    - On-Chip Interconnect management framework;

    - IOMMU subsystem;

    - Multiple devices driver;

    - Media drivers;

    - Fastrpc Driver;

    - Amazon Nitro Secure Module driver;

    - MMC subsystem;

    - MTD block device drivers;

    - Ethernet bonding driver;

    - Network drivers;

    - Microsoft Azure Network Adapter (MANA) driver;

    - Texas Instruments network drivers;

    - MediaTek network drivers;

    - NTB driver;

    - NVDIMM (Non-Volatile Memory Device) drivers;

    - NVME drivers;

    - NVMEM (Non Volatile Memory) drivers;

    - PCI subsystem;

    - Chrome hardware platform drivers;

    - x86 platform drivers;

    - Power supply drivers;

    - RapidIO drivers;

    - Voltage and Current Regulator drivers;

    - S/390 drivers;

    - SCSI subsystem;

    - SLIMbus drivers;

    - NVIDIA Tegra SoC drivers;

    - Realtek RTL8723BS SDIO drivers;

    - TCM subsystem;

    - Trusted Execution Environment drivers;

    - Thunderbolt and USB4 drivers;

    - TTY drivers;

    - USB Device Class drivers;

    - Faraday FOTG210 USB2 dual-role controller driver;

    - USB Gadget drivers;

    - USB Host Controller drivers;

    - Siemens ID Mouse USB driver;

    - IOWarrior USB driver;

    - LD Didactic USB driver;

    - LEGO USB Tower driver;

    - USB Serial drivers;

    - USB Type-C support driver;

    - USB Type-C Port Controller Manager driver;

    - USB Type-C Connector System Software Interface driver;

    - USB over IP driver;

    - VFIO drivers;

    - Framebuffer layer;

    - W1 Dallas's 1-wire bus driver;

    - AFS file system;

    - BTRFS file system;

    - Ceph distributed file system;

    - eCrypt file system;

    - File systems infrastructure;

    - Ext4 file system;

    - F2FS file system;

    - FUSE (File system in Userspace);

    - Network file system (NFS) server daemon;

    - NILFS2 file system;

    - NTFS3 file system;

    - OCFS2 file system;

    - OrangeFS file system;

    - SMB network file system;

    - UBI file system;

    - Drivers core;

    - Tracing infrastructure;

    - KProbes tracing;

    - Networking core;

    - Netfilter;

    - Sun RPC protocol;

    - IPv6 networking;

    - Bluetooth subsystem;

    - IPv4 networking;

    - IP tunnels definitions;

    - SCTP protocol;

    - User-space API (UAPI);

    - IPC subsystem;

    - Audit subsystem;

    - BPF subsystem;

    - DMA mapping infrastructure;

    - Kernel futex primitives;

    - Scheduler infrastructure;

    - Signal handling mechanism;

    - Memory management;

    - 6LoWPAN network protocol;

    - IEEE 802 network protocols;

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

    - Ethernet bridge;

    - CAN network layer;

    - Ceph Core library;

    - Devlink API;

    - HSR network protocol;

    - IEEE802154.4 network protocol;

    - IUCV driver;

    - MAC80211 subsystem;

    - Management Component Transport Protocol (MCTP);

    - MultiProtocol Label Switching driver;

    - Multipath TCP;

    - NetLabel subsystem;

    - Open vSwitch;

    - Packet sockets;

    - RDS protocol;

    - Network traffic control;

    - SMC sockets;

    - Network sockets;

    - VMware vSockets driver;

    - XFRM subsystem;

    - AppArmor security module;

    - Key management;

    - Landlock security;

    - Simplified Mandatory Access Control Kernel framework;

    - ALSA framework;

    - Digigram PCXHR ALSA driver;

    - Wolfson Microelectronics audio codecs;

    - USB sound devices;

    - KVM subsystem; (CVE-2024-40954, CVE-2025-38261, CVE-2025-68296, CVE-2025-68730, CVE-2025-68768,     CVE-2026-23346, CVE-2026-43219, CVE-2026-43240, CVE-2026-43311, CVE-2026-43331, CVE-2026-45930,     CVE-2026-52913, CVE-2026-52930, CVE-2026-52939, CVE-2026-52944, CVE-2026-52948, CVE-2026-52953,     CVE-2026-53080, CVE-2026-53134, CVE-2026-53135, CVE-2026-53140, CVE-2026-53144, CVE-2026-53150,     CVE-2026-53154, CVE-2026-53158, CVE-2026-53168, CVE-2026-53177, CVE-2026-53178, CVE-2026-53179,     CVE-2026-53181, CVE-2026-53190, CVE-2026-53208, CVE-2026-53210, CVE-2026-53213, CVE-2026-53214,     CVE-2026-53218, CVE-2026-53219, CVE-2026-53220, CVE-2026-53227, CVE-2026-53236, CVE-2026-53237,     CVE-2026-53238, CVE-2026-53242, CVE-2026-53245, CVE-2026-53249, CVE-2026-53251, CVE-2026-53252,     CVE-2026-53261, CVE-2026-53263, CVE-2026-53265, CVE-2026-53274, CVE-2026-53331, CVE-2026-53332,     CVE-2026-53336, CVE-2026-53337, CVE-2026-53339, CVE-2026-53343, CVE-2026-53345, CVE-2026-53347,     CVE-2026-53349, CVE-2026-53350, CVE-2026-53352, CVE-2026-53353, CVE-2026-63868, CVE-2026-63871,     CVE-2026-63876, CVE-2026-63877, CVE-2026-63882, CVE-2026-63883, CVE-2026-63890, CVE-2026-63891,     CVE-2026-63892, CVE-2026-63895, CVE-2026-63896, CVE-2026-63897, CVE-2026-63898, CVE-2026-63899,     CVE-2026-63900, CVE-2026-63901, CVE-2026-63902, CVE-2026-63903, CVE-2026-63904, CVE-2026-63905,     CVE-2026-63908, CVE-2026-63928, CVE-2026-63931, CVE-2026-63933, CVE-2026-63934, CVE-2026-63943,     CVE-2026-63949, CVE-2026-63956, CVE-2026-63957, CVE-2026-63958, CVE-2026-63959, CVE-2026-63960,     CVE-2026-63961, CVE-2026-63964, CVE-2026-63967, CVE-2026-63969, CVE-2026-63973, CVE-2026-63990,     CVE-2026-63991, CVE-2026-64001, CVE-2026-64006, CVE-2026-64012, CVE-2026-64014, CVE-2026-64078,     CVE-2026-64090, CVE-2026-64094, CVE-2026-64131, CVE-2026-64233, CVE-2026-64234, CVE-2026-64240,     CVE-2026-64305, CVE-2026-64329, CVE-2026-64330, CVE-2026-64340, CVE-2026-64341, CVE-2026-64342,     CVE-2026-64343, CVE-2026-64344, CVE-2026-64346, CVE-2026-64348, CVE-2026-64352, CVE-2026-64362,     CVE-2026-64363, CVE-2026-64365, CVE-2026-64407, CVE-2026-64421, CVE-2026-64424, CVE-2026-64433,     CVE-2026-64446, CVE-2026-64525, CVE-2026-64527, CVE-2026-64528, CVE-2026-74506, CVE-2026-80590,     CVE-2026-80591, CVE-2026-80593, CVE-2026-80598, CVE-2026-80599, CVE-2026-80600, CVE-2026-80601,     CVE-2026-80603, CVE-2026-80609, CVE-2026-80613, CVE-2026-80619, CVE-2026-80622, CVE-2026-80628,     CVE-2026-80630, CVE-2026-80631, CVE-2026-80634, CVE-2026-80635, CVE-2026-80637, CVE-2026-80644,     CVE-2026-80645, CVE-2026-80646, CVE-2026-80649, CVE-2026-80653, CVE-2026-80662, CVE-2026-80663,     CVE-2026-80664, CVE-2026-80668, CVE-2026-80677, CVE-2026-80678, CVE-2026-80680, CVE-2026-80681,     CVE-2026-80684, CVE-2026-80691, CVE-2026-80692, CVE-2026-80693, CVE-2026-80694, CVE-2026-80700,     CVE-2026-80702, CVE-2026-80706, CVE-2026-80707, CVE-2026-80709, CVE-2026-80710, CVE-2026-80714,     CVE-2026-80716, CVE-2026-80717, CVE-2026-80718, CVE-2026-80722, CVE-2026-80725, CVE-2026-80731,     CVE-2026-80732, CVE-2026-80737, CVE-2026-80738, CVE-2026-80747, CVE-2026-80752, CVE-2026-80754,     CVE-2026-80840, CVE-2026-80928, CVE-2026-80931, CVE-2026-80932, CVE-2026-80933, CVE-2026-80935,     CVE-2026-80937, CVE-2026-80944, CVE-2026-80945, CVE-2026-80947, CVE-2026-80952, CVE-2026-80967,     CVE-2026-80971, CVE-2026-80976, CVE-2026-80977, CVE-2026-80978, CVE-2026-80980, CVE-2026-80982,     CVE-2026-80987, CVE-2026-80989, CVE-2026-80990, CVE-2026-80991, CVE-2026-80992, CVE-2026-80994,     CVE-2026-81000, CVE-2026-81001, CVE-2026-81002, CVE-2026-81003, CVE-2026-81007, CVE-2026-81008,     CVE-2026-81011, CVE-2026-81012, CVE-2026-81016, CVE-2026-81017, CVE-2026-89440, CVE-2026-89441,     CVE-2026-89442, CVE-2026-89443, CVE-2026-89448, CVE-2026-89452, CVE-2026-89456, CVE-2026-89465,     CVE-2026-89466, CVE-2026-89469, CVE-2026-89470, CVE-2026-89471, CVE-2026-89472, CVE-2026-89476,     CVE-2026-89477, CVE-2026-89478, CVE-2026-89479, CVE-2026-89480, CVE-2026-89481, CVE-2026-89482,     CVE-2026-89483, CVE-2026-89485, CVE-2026-89487, CVE-2026-89488, CVE-2026-89489, CVE-2026-89492,     CVE-2026-89493, CVE-2026-89494, CVE-2026-89495, CVE-2026-89497, CVE-2026-89500, CVE-2026-89501,     CVE-2026-89502, CVE-2026-89503, CVE-2026-89504, CVE-2026-89508, CVE-2026-89510, CVE-2026-89511,     CVE-2026-89520, CVE-2026-89524, CVE-2026-89526, CVE-2026-89528, CVE-2026-89530, CVE-2026-89532,     CVE-2026-89533, CVE-2026-89536, CVE-2026-89537, CVE-2026-89538, CVE-2026-89540, CVE-2026-89541,     CVE-2026-89542, CVE-2026-89544, CVE-2026-89545, CVE-2026-89547, CVE-2026-89548, CVE-2026-89549,     CVE-2026-89550, CVE-2026-89551, CVE-2026-89553, CVE-2026-89554, CVE-2026-89555, CVE-2026-89557,     CVE-2026-89559, CVE-2026-89560, CVE-2026-89561, CVE-2026-89562, CVE-2026-89563, CVE-2026-89564,     CVE-2026-89569, CVE-2026-89573, CVE-2026-89574, CVE-2026-89579, CVE-2026-89580, CVE-2026-89583,     CVE-2026-89585, CVE-2026-89586, CVE-2026-89587, CVE-2026-89594, CVE-2026-89596, CVE-2026-89597,     CVE-2026-89599, CVE-2026-89601, CVE-2026-89605, CVE-2026-89606, CVE-2026-89607, CVE-2026-89608,     CVE-2026-89609, CVE-2026-89615, CVE-2026-89616, CVE-2026-89617, CVE-2026-89622, CVE-2026-89626,     CVE-2026-89631, CVE-2026-89633, CVE-2026-89634, CVE-2026-89636, CVE-2026-89637, CVE-2026-89638,     CVE-2026-89640, CVE-2026-89643, CVE-2026-89647, CVE-2026-89648, CVE-2026-89649, CVE-2026-89650,     CVE-2026-89652, CVE-2026-89653, CVE-2026-89654, CVE-2026-89655, CVE-2026-89656, CVE-2026-89657,     CVE-2026-89659, CVE-2026-89662, CVE-2026-89663, CVE-2026-89665, CVE-2026-89669, CVE-2026-89671,     CVE-2026-89672, CVE-2026-89674, CVE-2026-89676, CVE-2026-89680, CVE-2026-89682, CVE-2026-89684,     CVE-2026-89685, CVE-2026-89686, CVE-2026-89690, CVE-2026-89691, CVE-2026-89694, CVE-2026-89696,     CVE-2026-89697, CVE-2026-89699, CVE-2026-89702, CVE-2026-89704, CVE-2026-89705, CVE-2026-89706,     CVE-2026-89707, CVE-2026-89708, CVE-2026-89709, CVE-2026-89711, CVE-2026-89712, CVE-2026-89713,     CVE-2026-89720, CVE-2026-89723, CVE-2026-89724, CVE-2026-89725, CVE-2026-89729, CVE-2026-89731,     CVE-2026-89733, CVE-2026-89736, CVE-2026-89738, CVE-2026-89742, CVE-2026-89743, CVE-2026-89747,     CVE-2026-89750, CVE-2026-89755, CVE-2026-89761, CVE-2026-89762, CVE-2026-89763, CVE-2026-89774,     CVE-2026-89777, CVE-2026-89778, CVE-2026-89779, CVE-2026-89781, CVE-2026-89782, CVE-2026-89783,     CVE-2026-89786, CVE-2026-89788, CVE-2026-89789, CVE-2026-89792, CVE-2026-89793, CVE-2026-89795,     CVE-2026-89799, CVE-2026-89801, CVE-2026-89803, CVE-2026-89806, CVE-2026-89808, CVE-2026-89810,     CVE-2026-89811, CVE-2026-89819, CVE-2026-89823, CVE-2026-89832, CVE-2026-89838, CVE-2026-89840,     CVE-2026-89844, CVE-2026-89846, CVE-2026-89847, CVE-2026-89848, CVE-2026-89849, CVE-2026-89854,     CVE-2026-89856, CVE-2026-89857, CVE-2026-89860, CVE-2026-89861, CVE-2026-89863, CVE-2026-89870,     CVE-2026-89877, CVE-2026-89880, CVE-2026-89883, CVE-2026-89887, CVE-2026-89888, CVE-2026-89890,     CVE-2026-89893, CVE-2026-89894, CVE-2026-89897, CVE-2026-89899, CVE-2026-89902, CVE-2026-89903,     CVE-2026-89908, CVE-2026-89912, CVE-2026-89920, CVE-2026-89922, CVE-2026-89927, CVE-2026-89929,     CVE-2026-89930, CVE-2026-89932, CVE-2026-89938, CVE-2026-89951, CVE-2026-89954, CVE-2026-89957,     CVE-2026-89959, CVE-2026-89960, CVE-2026-89961, CVE-2026-89965, CVE-2026-89968, CVE-2026-89969,     CVE-2026-89970, CVE-2026-89972, CVE-2026-89973, CVE-2026-89979, CVE-2026-89988, CVE-2026-89992,     CVE-2026-89995, CVE-2026-89997, CVE-2026-89998, CVE-2026-89999, CVE-2026-90000, CVE-2026-90002,     CVE-2026-90003, CVE-2026-90007, CVE-2026-90011, CVE-2026-90013, CVE-2026-90016, CVE-2026-90017,     CVE-2026-90018, CVE-2026-90022, CVE-2026-90025, CVE-2026-90026, CVE-2026-90027, CVE-2026-90032,     CVE-2026-90036, CVE-2026-90037, CVE-2026-90041, CVE-2026-90042, CVE-2026-90044, CVE-2026-90045,     CVE-2026-90048, CVE-2026-90049, CVE-2026-90170, CVE-2026-92502, CVE-2026-93221)

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.

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.

It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-3183 advisory.

    In the Linux kernel, the following vulnerability has been resolved:

    smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2 (CVE-2026-89637)

    In the Linux kernel, the following vulnerability has been resolved:

    ceph: bound copied dentry name length in NFS export get_name

    ceph_get_name() copies the MDS-supplied name into the caller'sNAME_MAX-sized buffer with memcpy(name,     rinfo->dname, rinfo->dname_len)and then writes name[rinfo->dname_len] = 0, without checking     dname_lenagainst NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME replywith dname_len >     NAME_MAX overflows the buffer. __get_snap_name() copiesrde->name / rde->name_len the same unchecked way.

    Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX namebuffer in a client's NFS-export     get_name path, a slab out-of-bounds writereported by KASAN. Reachable when a CephFS mount is re-exported     over NFS.

    Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with-ENAMETOOLONG before the copy, and     use it in both ceph_get_name() and__get_snap_name(). (CVE-2026-89652)

    In the Linux kernel, the following vulnerability has been resolved:

    bpf: Reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max (CVE-2026-93125)

    In the Linux kernel, the following vulnerability has been resolved:

    ipv6: sr: restore network header before routing and forwarding (CVE-2026-98096)

    In the Linux kernel, the following vulnerability has been resolved:

    writeback: bound cleanup_offline_cgwb() rescans by rotating scanned inodes (CVE-2026-98538)

    In the Linux kernel, the following vulnerability has been resolved:

    nitro_enclaves: fix use-after-free on SLOT_ALLOC failure (CVE-2026-98775)

Tenable has extracted the preceding description block directly from the tested product 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.

  - ceph: bound copied dentry name length in NFS export get_name ceph_get_name() copies the MDS-supplied name     into the caller's NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes     name[rinfo->dname_len] = 0, without checking dname_len against NAME_MAX. A malicious or buggy MDS that     returns a LOOKUPNAME reply with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies     rde->name / rde->name_len the same unchecked way. Impact: a malicious or compromised Ceph MDS overflows     the NAME_MAX name buffer in a client's NFS-export get_name path, a slab out-of-bounds write reported by     KASAN. Reachable when a CephFS mount is re-exported over NFS. Add ceph_export_copy_name(), which rejects     lengths above NAME_MAX with -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and
    __get_snap_name(). (CVE-2026-89652)

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

ID	Name	Product	Family	Type	Severity
381428	Unity Linux 20.1050a / 20.1060a / 20.1070a Security Update: kernel (UTSA-2026-146717)	Nessus	Unity Linux Local Security Checks	Local	critical
379876	Amazon Linux 2 : kernel (ALASKERNEL-5.15-2026-121)	Nessus	Amazon Linux Local Security Checks	Local	critical
378425	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1794319150)	Nessus	CentOS Local Security Checks	Local	high
378311	Unity Linux 20.1050e / 20.1060e / 20.1070e Security Update: kernel (UTSA-2026-151297)	Nessus	Unity Linux Local Security Checks	Local	critical
377600	Ubuntu 24.04 LTS : Linux kernel (NVIDIA Tegra) vulnerabilities (USN-9002-1)	Nessus	Ubuntu Local Security Checks	Local	high
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	Local	high
375048	Photon OS 5.0: Linux PHSA-2026-5.0-92-0999	Nessus	PhotonOS Local Security Checks	Local	high
375011	Photon OS 5.0: Linux PHSA-2026-5.0-91-0999	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
366741	Amazon Linux 2 : kernel (ALASKERNEL-5.10-2026-135)	Nessus	Amazon Linux Local Security Checks	Local	medium
365283	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3187)	Nessus	Amazon Linux Local Security Checks	Local	medium
365279	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3196)	Nessus	Amazon Linux Local Security Checks	Local	medium
365240	Amazon Linux 2023 : bpftool, kernel, kernel-devel (ALAS2023-2026-3183)	Nessus	Amazon Linux Local Security Checks	Local	critical
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	Local	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
345126	Linux Distros Unpatched Vulnerability : CVE-2026-89652	Nessus	Misc.	Local	critical

Detections

Analytics

CVE-2026-89652

critical

Tenable Plugins

critical

critical

high

critical

high

high

high

high

high

medium

medium

medium

critical

high

high

high

critical