In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in cleanup_bearer() due to premature dst_cache_destroy() TIPC UDP media bearer teardown calls dst_cache_destroy() on its replicast caches before calling synchronize_net() to wait for concurrent RCU readers (transmitters) to finish: static void cleanup_bearer(struct work_struct *work) { ... list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) { dst_cache_destroy(&rcast->dst_cache); list_del_rcu(&rcast->list); kfree_rcu(rcast, rcu); } ... dst_cache_destroy(&ub->rcast.dst_cache); udp_tunnel_sock_release(ub->sk); synchronize_net(); ... } This is highly buggy because dst_cache_destroy() immediately frees the per-CPU cache memory (free_percpu()) and releases the cached dst entries without any synchronization. If a concurrent transmitter (e.g., tipc_udp_xmit()) is running on another CPU under RCU protection, it can call dst_cache_get() concurrently, leading to: 1. Use-After-Free on the per-CPU cache pointer itself (crash). 2. "rcuref - imbalanced put()" warning if it attempts to release a dst that was concurrently released by dst_cache_destroy(). Furthermore, calling kfree(ub) immediately after synchronize_net() without closing the socket first (or waiting after closing it) leaves a window where a concurrent receiver (tipc_udp_recv()) could start after synchronize_net(), access ub, and suffer a UAF when kfree(ub) runs. To fix this, we must defer dst_cache_destroy() and kfree(ub) until after we have ensured that no more readers can see the bearer/socket and all existing readers have finished: 1. Defer rcast entry destruction (both dst_cache_destroy() and kfree()) to an RCU callback using call_rcu_hurry(). Using call_rcu_hurry() ensures the dst entries are released quickly. 2. Release the bearer socket using udp_tunnel_sock_release() (stops new receive readers). 3. Call synchronize_net() to wait for all outstanding RCU readers (both transmit and receive) to finish. 4. Now that it is safe, call dst_cache_destroy() on the main bearer cache, and free ub. Note: 3) and 4) can be changed later in net-next to also use call_rcu_hurry() and get rid of the synchronize_net() latency.

tuxcare CENTOS8.5:CLSA-2026:1794316823: kernel: Fix of 102 CVEs (Critical)

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

  - In the Linux kernel, the following vulnerability has been resolved: virt: tdx-guest: Just leak decrypted     memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause     set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers     need to take care to handle these errors to avoid returning decrypted (shared) memory to the page     allocator, which could lead to functional or security issues. Leak the decrypted memory when     set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call     WARN_ONCE(). (CVE-2024-57793)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - zero initialize     memory allocated via sock_kmalloc Several crypto user API contexts and requests allocated with     sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the     use of uninitialized data in certain error paths or when new fields are added in the future. The ACVP     patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on     proper initialization of their context structures. A particular issue has been observed with the newly     added 'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af (crypto: af_alg - Disallow     multiple in-flight AIO requests) Because the context is not memset to zero after allocation, the inflight     variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY     randomly when the garbage value was interpreted as true:
    https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209 The check directly tests ctx->inflight     without explicitly comparing against true/false. Since inflight is only ever set to true or false later,     an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with     sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by     uninitialized data. (CVE-2025-71113)

  - In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for     %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte     stack buffers with %pISpc. That is too small for the longest current-tree IPv6-with-port form the     formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for     v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as     [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50     visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50]     buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch     the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum     current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier     mapped-v4 example (CVE-2026-31630)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: check for     partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are     adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous     set checks on start elements for this reason. However, it is possible to add intervals that overlap to     this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A     C Restore the check on overlapping start elements to report an overlap. (CVE-2026-45873)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-     chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;)     and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the     terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of     iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond     the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops     to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and     atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since     most are connector- based) 256 is a generous upper bound. (cherry picked from commit     95700a3d660287ed657d6892f7be9ffc0e294a93) (CVE-2026-53138)

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:1792445930 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: virt: tdx-guest: Just leak decrypted     memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause     set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers     need to take care to handle these errors to avoid returning decrypted (shared) memory to the page     allocator, which could lead to functional or security issues. Leak the decrypted memory when     set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call     WARN_ONCE(). (CVE-2024-57793)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - zero initialize     memory allocated via sock_kmalloc Several crypto user API contexts and requests allocated with     sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the     use of uninitialized data in certain error paths or when new fields are added in the future. The ACVP     patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on     proper initialization of their context structures. A particular issue has been observed with the newly     added 'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af (crypto: af_alg - Disallow     multiple in-flight AIO requests) Because the context is not memset to zero after allocation, the inflight     variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY     randomly when the garbage value was interpreted as true:
    https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209 The check directly tests ctx->inflight     without explicitly comparing against true/false. Since inflight is only ever set to true or false later,     an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with     sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by     uninitialized data. (CVE-2025-71113)

  - In the Linux kernel, the following vulnerability has been resolved: rxrpc: proc: size address buffers for     %pISpc output The AF_RXRPC procfs helpers format local and remote socket addresses into fixed 50-byte     stack buffers with %pISpc. That is too small for the longest current-tree IPv6-with-port form the     formatter can produce. In lib/vsprintf.c, the compressed IPv6 path uses a dotted-quad tail not only for     v4mapped addresses, but also for ISATAP addresses via ipv6_addr_is_isatap(). As a result, a case such as     [ffff:ffff:ffff:ffff:0:5efe:255.255.255.255]:65535 is possible with the current formatter. That is 50     visible characters, so 51 bytes including the trailing NUL, which does not fit in the existing char[50]     buffers used by net/rxrpc/proc.c. Size the buffers from the formatter's maximum textual form and switch     the call sites to scnprintf(). Changes since v1: - correct the changelog to cite the actual maximum     current-tree case explicitly - frame the proof around the ISATAP formatting path instead of the earlier     mapped-v4 example (CVE-2026-31630)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_rbtree: check for     partial overlaps in anonymous sets Userspace provides an optimized representation in case intervals are     adjacent, where the end element is omitted. The existing partial overlap detection logic skips anonymous     set checks on start elements for this reason. However, it is possible to add intervals that overlap to     this anonymous where two start elements with the same, eg. A-B, A-C where C < B. start end A B start end A     C Restore the check on overlapping start elements to report an overlap. (CVE-2026-45873)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Bound VBIOS record-     chain walk loops [Why & How] All record-chain walk loops in bios_parser.c and bios_parser2.c use for(;;)     and only terminate on a 0xFF record_type sentinel or zero record_size. A malformed VBIOS image missing the     terminator record causes unbounded iteration at probe time, potentially hundreds of thousands of     iterations with record_size=1. In the final iterations near the BIOS image boundary, struct casts beyond     the 2-byte header validated by GET_IMAGE can also read out of bounds. Cap all 14 record-chain walk loops     to BIOS_MAX_NUM_RECORD (256) iterations. The atombios.h defines up to 22 distinct record types and     atomfirmware.h has 13. Assuming an average of less than 10 records per type (which is reasonable since     most are connector- based) 256 is a generous upper bound. (cherry picked from commit     95700a3d660287ed657d6892f7be9ffc0e294a93) (CVE-2026-53138)

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 host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-8886-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:

    - NVDIMM (Non-Volatile Memory Device) drivers;

    - Handshake API;

    - ARM32 architecture;

    - ARM64 architecture;

    - MIPS architecture;

    - OpenRISC architecture;

    - PowerPC architecture;

    - S390 architecture;

    - x86 architecture;

    - Block layer subsystem;

    - Cryptographic API;

    - Intel NPU Driver;

    - Android drivers;

    - Rados block device (RBD) driver;

    - Bluetooth drivers;

    - Hardware random number generator core;

    - TPM device driver;

    - CPU frequency scaling framework;

    - Hardware crypto device drivers;

    - DMA engine subsystem;

    - FireWire subsystem;

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

    - GPIO subsystem;

    - GPU drivers;

    - HID subsystem;

    - Hardware monitoring drivers;

    - CoreSight HW tracing drivers;

    - I2C subsystem;

    - IIO ADC drivers;

    - IIO subsystem;

    - InfiniBand drivers;

    - Input Device core drivers;

    - Input Device (Mouse) drivers;

    - IOMMU subsystem;

    - Multiple devices driver;

    - Media drivers;

    - Multifunction device drivers;

    - Fastrpc Driver;

    - Amazon Nitro Secure Module driver;

    - MMC subsystem;

    - MTD block device drivers;

    - Ethernet bonding driver;

    - Network drivers;

    - Mellanox network drivers;

    - Texas Instruments network drivers;

    - NTB driver;

    - NVME drivers;

    - NVMEM (Non Volatile Memory) drivers;

    - Parport drivers;

    - Pin controllers subsystem;

    - x86 platform drivers;

    - i.MX PM domains;

    - System reset/shutdown drivers;

    - PTP clock framework;

    - Voltage and Current Regulator drivers;

    - S/390 drivers;

    - SCSI subsystem;

    - SPI subsystem;

    - Realtek RTL8723BS SDIO drivers;

    - VME bus staging drivers;

    - Thermal drivers;

    - Thunderbolt and USB4 drivers;

    - TTY drivers;

    - DesignWare USB2 driver;

    - USB Gadget drivers;

    - USB Host Controller drivers;

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

    - USB Serial drivers;

    - USB Type-C Port Controller Manager driver;

    - vDPA drivers;

    - Virtio Host (VHOST) subsystem;

    - Framebuffer layer;

    - Watchdog drivers;

    - 9P distributed file system;

    - AFS file system;

    - File systems infrastructure;

    - BTRFS file system;

    - Ceph distributed file system;

    - EROFS file system;

    - exFAT file system;

    - F2FS file system;

    - FUSE (File system in Userspace);

    - Journaling layer for block devices (JBD2);

    - Network file system (NFS) client;

    - Network file system (NFS) server daemon;

    - NTFS3 file system;

    - OCFS2 file system;

    - Proc file system;

    - SMB network file system;

    - Tracing file system;

    - UDF file system;

    - XFS file system;

    - Key management;

    - BPF subsystem;

    - Control group (cgroup);

    - Glob pattern matching library;

    - MAC80211 subsystem;

    - Mellanox drivers;

    - Networking core;

    - Network sockets;

    - IPv6 networking;

    - Bluetooth subsystem;

    - Wireless networking;

    - IPv4 networking;

    - Netfilter;

    - Network traffic control;

    - SCTP protocol;

    - TCP network protocol;

    - XFRM subsystem;

    - RDMA verbs API;

    - io_uring subsystem;

    - IPC subsystem;

    - Audit subsystem;

    - Kernel CPU control infrastructure;

    - Perf events;

    - Kernel exit() syscall;

    - Kernel fork() syscall;

    - Scheduler infrastructure;

    - Signal handling mechanism;

    - Timer subsystem;

    - Tracing infrastructure;

    - Resizable hashtable library;

    - Memory management;

    - 6LoWPAN network protocol;

    - Asynchronous Transfer Mode (ATM) subsystem;

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

    - Ethernet bridge;

    - CAN network layer;

    - Ceph Core library;

    - Ethtool driver;

    - HSR network protocol;

    - IEEE802154.4 network protocol;

    - IUCV driver;

    - KCM (Kernel Connection Multiplexor) sockets driver;

    - IEEE 802.15.4 subsystem;

    - Multipath TCP;

    - Open vSwitch;

    - Packet sockets;

    - Phonet protocol;

    - Qualcomm IPC Router (QRTR);

    - RDS protocol;

    - RxRPC session sockets;

    - SMC sockets;

    - Sun RPC protocol;

    - TIPC protocol;

    - TLS protocol;

    - Unix domain sockets;

    - VMware vSockets driver;

    - X.25 network layer;

    - eXpress Data Path;

    - AppArmor security module;

    - Integrity Measurement Architecture(IMA) framework;

    - SELinux security module;

    - ALSA framework;

    - HD-audio driver;

    - QCOM ASoC drivers;

    - Simple audio multiplexer codec driver;

    - Texas InstrumentS Audio (ASoC/HDA) drivers;

    - SoC Audio for Freescale CPUs drivers;

    - Amlogic Meson SoC drivers;

    - SOF drivers;

    - NVIDIA Tegra ASoC drivers;

    - USB sound devices;

    - Perf tools;

    - KVM subsystem; (CVE-2025-37807, CVE-2026-23265, CVE-2026-43022, CVE-2026-46321, CVE-2026-46322,     CVE-2026-52917, CVE-2026-52923, CVE-2026-52927, CVE-2026-52929, CVE-2026-52935, CVE-2026-52942,     CVE-2026-52943, CVE-2026-52947, CVE-2026-52994, CVE-2026-53136, CVE-2026-53137, CVE-2026-53138,     CVE-2026-53143, CVE-2026-53146, CVE-2026-53147, CVE-2026-53149, CVE-2026-53156, CVE-2026-53157,     CVE-2026-53160, CVE-2026-53161, CVE-2026-53184, CVE-2026-53189, CVE-2026-53194, CVE-2026-53195,     CVE-2026-53199, CVE-2026-53202, CVE-2026-53205, CVE-2026-53209, CVE-2026-53223, CVE-2026-53229,     CVE-2026-53253, CVE-2026-53255, CVE-2026-53267, CVE-2026-53268, CVE-2026-53272, CVE-2026-53329,     CVE-2026-53330, CVE-2026-53356, CVE-2026-53362, CVE-2026-53365, CVE-2026-53366, CVE-2026-53381,     CVE-2026-53383, CVE-2026-53387, CVE-2026-53388, CVE-2026-53389, CVE-2026-53390, CVE-2026-53391,     CVE-2026-53392, CVE-2026-53397, CVE-2026-53400, CVE-2026-53401, CVE-2026-53402, CVE-2026-63794,     CVE-2026-63802, CVE-2026-63803, CVE-2026-63805, CVE-2026-63806, CVE-2026-63809, CVE-2026-63812,     CVE-2026-63814, CVE-2026-63816, CVE-2026-63817, CVE-2026-63819, CVE-2026-63823, CVE-2026-63824,     CVE-2026-63827, CVE-2026-63833, CVE-2026-63867, CVE-2026-63869, CVE-2026-63870, CVE-2026-63875,     CVE-2026-63879, CVE-2026-63881, CVE-2026-63884, CVE-2026-63889, CVE-2026-63909, CVE-2026-63913,     CVE-2026-63920, CVE-2026-63925, CVE-2026-63927, CVE-2026-63930, CVE-2026-63942, CVE-2026-63954,     CVE-2026-63968, CVE-2026-63970, CVE-2026-63971, CVE-2026-63985, CVE-2026-64002, CVE-2026-64003,     CVE-2026-64004, CVE-2026-64005, CVE-2026-64009, CVE-2026-64017, CVE-2026-64023, CVE-2026-64026,     CVE-2026-64036, CVE-2026-64095, CVE-2026-64123, CVE-2026-64188, CVE-2026-64189, CVE-2026-64210,     CVE-2026-64222, CVE-2026-64239, CVE-2026-64242, CVE-2026-64243, CVE-2026-64245, CVE-2026-64246,     CVE-2026-64266, CVE-2026-64270, CVE-2026-64271, CVE-2026-64272, CVE-2026-64273, CVE-2026-64274,     CVE-2026-64276, CVE-2026-64277, CVE-2026-64279, CVE-2026-64283, CVE-2026-64286, CVE-2026-64287,     CVE-2026-64296, CVE-2026-64298, CVE-2026-64299, CVE-2026-64304, CVE-2026-64312, CVE-2026-64317,     CVE-2026-64318, CVE-2026-64322, CVE-2026-64323, CVE-2026-64324, CVE-2026-64333, CVE-2026-64368,     CVE-2026-64372, CVE-2026-64374, CVE-2026-64375, CVE-2026-64378, CVE-2026-64379, CVE-2026-64380,     CVE-2026-64388, CVE-2026-64389, CVE-2026-64395, CVE-2026-64398, CVE-2026-64401, CVE-2026-64402,     CVE-2026-64403, CVE-2026-64411, CVE-2026-64412, CVE-2026-64413, CVE-2026-64418, CVE-2026-64420,     CVE-2026-64422, CVE-2026-64423, CVE-2026-64430, CVE-2026-64432, CVE-2026-64435, CVE-2026-64436,     CVE-2026-64440, CVE-2026-64442, CVE-2026-64443, CVE-2026-64444, CVE-2026-64448, CVE-2026-64449,     CVE-2026-64452, CVE-2026-64456, CVE-2026-64463, CVE-2026-64468, CVE-2026-64469, CVE-2026-64481,     CVE-2026-64496, CVE-2026-64524, CVE-2026-64532, CVE-2026-64533, CVE-2026-64536, CVE-2026-64539,     CVE-2026-64540, CVE-2026-64543, CVE-2026-64545, CVE-2026-64546, CVE-2026-64547, CVE-2026-64550,     CVE-2026-64556, CVE-2026-64560, CVE-2026-64563, CVE-2026-64567, CVE-2026-64568, CVE-2026-64570,     CVE-2026-64574, CVE-2026-64576, CVE-2026-64577, CVE-2026-64578, CVE-2026-64580, CVE-2026-64581,     CVE-2026-64582, CVE-2026-64583, CVE-2026-64584, CVE-2026-64585, CVE-2026-64599, CVE-2026-64600,     CVE-2026-68091, CVE-2026-68096, CVE-2026-68097, CVE-2026-68098, CVE-2026-68100, CVE-2026-68104,     CVE-2026-68106, CVE-2026-68107, CVE-2026-68108, CVE-2026-68116, CVE-2026-68118, CVE-2026-68119,     CVE-2026-68121, CVE-2026-68125, CVE-2026-68129, CVE-2026-68131, CVE-2026-68140, CVE-2026-68141,     CVE-2026-68142, CVE-2026-68143, CVE-2026-68145, CVE-2026-68148, CVE-2026-68149, CVE-2026-68153,     CVE-2026-68155, CVE-2026-68157, CVE-2026-68178, CVE-2026-68179, CVE-2026-68189, CVE-2026-68192,     CVE-2026-68196, CVE-2026-68199, CVE-2026-68202, CVE-2026-68204, CVE-2026-68216, CVE-2026-68219,     CVE-2026-68222, CVE-2026-68236, CVE-2026-68245, CVE-2026-68253, CVE-2026-68255, CVE-2026-68258,     CVE-2026-68260, CVE-2026-68262, CVE-2026-68263, CVE-2026-68266, CVE-2026-68273, CVE-2026-68284,     CVE-2026-68287, CVE-2026-68290, CVE-2026-68293, CVE-2026-68294, CVE-2026-68297, CVE-2026-68299,     CVE-2026-68314, CVE-2026-68315, CVE-2026-68320, CVE-2026-68322, CVE-2026-68323, CVE-2026-68326,     CVE-2026-68329, CVE-2026-68335, CVE-2026-68338, CVE-2026-68340, CVE-2026-68348, CVE-2026-68352,     CVE-2026-68353, CVE-2026-68354, CVE-2026-68370, CVE-2026-68371, CVE-2026-68373, CVE-2026-68376,     CVE-2026-68377, CVE-2026-68383, CVE-2026-68389, CVE-2026-68391, CVE-2026-68392, CVE-2026-68397,     CVE-2026-68398, CVE-2026-68399, CVE-2026-68400, CVE-2026-68401, CVE-2026-68402, CVE-2026-68404,     CVE-2026-68408, CVE-2026-68409, CVE-2026-68414, CVE-2026-68417, CVE-2026-68419, CVE-2026-68425,     CVE-2026-68432, CVE-2026-68433, CVE-2026-68442, CVE-2026-68445, CVE-2026-68446, CVE-2026-68447,     CVE-2026-68451, CVE-2026-68452, CVE-2026-68453, CVE-2026-68454, CVE-2026-68466, CVE-2026-68467,     CVE-2026-68471, CVE-2026-68474, CVE-2026-68479, CVE-2026-72005, CVE-2026-72009, CVE-2026-72012,     CVE-2026-72019, CVE-2026-72021, CVE-2026-72024, CVE-2026-72029, CVE-2026-72035, CVE-2026-72036,     CVE-2026-72045, CVE-2026-72049, CVE-2026-72051, CVE-2026-72052, CVE-2026-72053, CVE-2026-72054,     CVE-2026-72055, CVE-2026-72057, CVE-2026-72061, CVE-2026-72066, CVE-2026-72067, CVE-2026-72072,     CVE-2026-72089, CVE-2026-72099, CVE-2026-72102, CVE-2026-72105, CVE-2026-72107, CVE-2026-72108,     CVE-2026-72109, CVE-2026-72110, CVE-2026-72113, CVE-2026-72114, CVE-2026-72115, CVE-2026-72116,     CVE-2026-72117, CVE-2026-72118, CVE-2026-72119, CVE-2026-72120, CVE-2026-72121, CVE-2026-72122,     CVE-2026-72123, CVE-2026-72133, CVE-2026-72135, CVE-2026-72136, CVE-2026-72144, CVE-2026-72146,     CVE-2026-72148, CVE-2026-72149, CVE-2026-72157, CVE-2026-72160, CVE-2026-72162, CVE-2026-72164,     CVE-2026-72165, CVE-2026-72170, CVE-2026-72171, CVE-2026-72172, CVE-2026-72175, CVE-2026-72181,     CVE-2026-72195, CVE-2026-72196, CVE-2026-72197, CVE-2026-72213, CVE-2026-72225, CVE-2026-72227,     CVE-2026-72231, CVE-2026-72232, CVE-2026-72233, CVE-2026-72235, CVE-2026-72242, CVE-2026-72243,     CVE-2026-72244, CVE-2026-72247, CVE-2026-72250, CVE-2026-72252, CVE-2026-72253, CVE-2026-72254,     CVE-2026-72261, CVE-2026-72262, CVE-2026-72282, CVE-2026-72284, CVE-2026-72297, CVE-2026-72298,     CVE-2026-72301, CVE-2026-72302, CVE-2026-72304, CVE-2026-72310, CVE-2026-72312, CVE-2026-72314,     CVE-2026-72330, CVE-2026-72334, CVE-2026-72335, CVE-2026-72338, CVE-2026-72340, CVE-2026-72342,     CVE-2026-72343, CVE-2026-72347, CVE-2026-72350, CVE-2026-72352, CVE-2026-72369, CVE-2026-72371,     CVE-2026-72373, CVE-2026-72374, CVE-2026-72375, CVE-2026-72378, CVE-2026-72382, CVE-2026-72389,     CVE-2026-72390, CVE-2026-72397, CVE-2026-72400, CVE-2026-72404, CVE-2026-72405, CVE-2026-72406,     CVE-2026-72409, CVE-2026-72410, CVE-2026-72416, CVE-2026-72418, CVE-2026-72419, CVE-2026-72420,     CVE-2026-72423, CVE-2026-72425, CVE-2026-72427, CVE-2026-72435, CVE-2026-72438, CVE-2026-72440,     CVE-2026-72444, CVE-2026-72449, CVE-2026-72450, CVE-2026-72459, CVE-2026-72460, CVE-2026-72464,     CVE-2026-72469, CVE-2026-72470, CVE-2026-72476, CVE-2026-72478, CVE-2026-72480, CVE-2026-72483,     CVE-2026-72485, CVE-2026-72492, CVE-2026-72502, CVE-2026-74256, CVE-2026-74257, CVE-2026-74258,     CVE-2026-74262, CVE-2026-74270, CVE-2026-74281, CVE-2026-74282, CVE-2026-74283, CVE-2026-74288,     CVE-2026-74289, CVE-2026-74292, CVE-2026-74293, CVE-2026-74294, CVE-2026-74295, CVE-2026-74296,     CVE-2026-74297, CVE-2026-74300, CVE-2026-74312, CVE-2026-74313, CVE-2026-74314, CVE-2026-74317,     CVE-2026-74321, CVE-2026-74330, CVE-2026-74334, CVE-2026-74338, CVE-2026-74340, CVE-2026-74341,     CVE-2026-74344, CVE-2026-74347, CVE-2026-74349, CVE-2026-74356, CVE-2026-74359, CVE-2026-74363,     CVE-2026-74365, CVE-2026-74374, CVE-2026-74375, CVE-2026-74377, CVE-2026-74378, CVE-2026-74380,     CVE-2026-74385, CVE-2026-74387, CVE-2026-74388, CVE-2026-74390, CVE-2026-74397, CVE-2026-74438,     CVE-2026-74443, CVE-2026-74444, CVE-2026-74446, CVE-2026-74450, CVE-2026-74453, CVE-2026-74454,     CVE-2026-74456, CVE-2026-74461, CVE-2026-74465, CVE-2026-74467, CVE-2026-74469, CVE-2026-74470,     CVE-2026-74471, CVE-2026-74479, CVE-2026-74481, CVE-2026-74482, CVE-2026-74485, CVE-2026-74488,     CVE-2026-74490, CVE-2026-74492, CVE-2026-74496, CVE-2026-74497, CVE-2026-74507, CVE-2026-74508,     CVE-2026-74509, CVE-2026-74510, CVE-2026-74512, CVE-2026-74515, CVE-2026-74516, CVE-2026-74518,     CVE-2026-74519, CVE-2026-74522, CVE-2026-74523, CVE-2026-74527, CVE-2026-74530, CVE-2026-74531,     CVE-2026-74533, CVE-2026-74534, CVE-2026-74535, CVE-2026-74536, CVE-2026-74537, CVE-2026-74540,     CVE-2026-74544, CVE-2026-74548, CVE-2026-74549, CVE-2026-74550, CVE-2026-74551, CVE-2026-74557,     CVE-2026-74563, CVE-2026-74564, CVE-2026-74565, CVE-2026-74567, CVE-2026-74572, CVE-2026-74574,     CVE-2026-74575, CVE-2026-74578, CVE-2026-74579, CVE-2026-74580, CVE-2026-74581, CVE-2026-74582,     CVE-2026-74583, CVE-2026-74584, CVE-2026-74586, CVE-2026-74587, CVE-2026-74588, CVE-2026-74589,     CVE-2026-74590, CVE-2026-74592, CVE-2026-74594, CVE-2026-74595, CVE-2026-74597, CVE-2026-74598,     CVE-2026-74601, CVE-2026-74603, CVE-2026-74604, CVE-2026-74605, CVE-2026-74606, CVE-2026-74607,     CVE-2026-74608, CVE-2026-74609, CVE-2026-74610, CVE-2026-74611, CVE-2026-74612, CVE-2026-74613,     CVE-2026-74614, CVE-2026-74615, CVE-2026-74616, CVE-2026-74621, CVE-2026-74624, CVE-2026-74625,     CVE-2026-74626, CVE-2026-74628, CVE-2026-74630, CVE-2026-74631, CVE-2026-74632, CVE-2026-74634,     CVE-2026-74635, CVE-2026-74637, CVE-2026-74641, CVE-2026-74646, CVE-2026-74647, CVE-2026-74648,     CVE-2026-74649, CVE-2026-74651, CVE-2026-74656, CVE-2026-74660, CVE-2026-74661, CVE-2026-74662,     CVE-2026-74663, CVE-2026-74666, CVE-2026-74667, CVE-2026-74668, CVE-2026-74669, CVE-2026-74670,     CVE-2026-74675, CVE-2026-74678, CVE-2026-74684, CVE-2026-74687, CVE-2026-74688, CVE-2026-74689,     CVE-2026-74690, CVE-2026-74691, CVE-2026-74692, CVE-2026-74695, CVE-2026-74696, CVE-2026-74697,     CVE-2026-74700, CVE-2026-74701, CVE-2026-74704, CVE-2026-74705, CVE-2026-74710, CVE-2026-74711,     CVE-2026-74713, CVE-2026-74714, CVE-2026-74715, CVE-2026-74717, CVE-2026-74720, CVE-2026-74723,     CVE-2026-74724, CVE-2026-74725, CVE-2026-74726, CVE-2026-74730, CVE-2026-74733, CVE-2026-74736,     CVE-2026-74737, CVE-2026-74739, CVE-2026-74743, CVE-2026-74744, CVE-2026-74746, CVE-2026-74747,     CVE-2026-74748, CVE-2026-74752, CVE-2026-80521, CVE-2026-80526, CVE-2026-80527, CVE-2026-80528,     CVE-2026-80536, CVE-2026-80540, CVE-2026-80541, CVE-2026-80547, CVE-2026-80548, CVE-2026-80549,     CVE-2026-80550, CVE-2026-80551, CVE-2026-80552, CVE-2026-80553, CVE-2026-80554, CVE-2026-80555,     CVE-2026-80556, CVE-2026-80557, CVE-2026-80558, CVE-2026-80559, CVE-2026-80560, CVE-2026-80561,     CVE-2026-80565, CVE-2026-80568, CVE-2026-80569, CVE-2026-80570, CVE-2026-80572, CVE-2026-80574,     CVE-2026-80576, CVE-2026-80578, CVE-2026-80579, CVE-2026-80580, CVE-2026-80583, CVE-2026-80584,     CVE-2026-80585, CVE-2026-80586, CVE-2026-80587, CVE-2026-80589, CVE-2026-80721, CVE-2026-80901,     CVE-2026-97509)

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.

  - tipc: fix UAF in cleanup_bearer() due to premature dst_cache_destroy() TIPC UDP media bearer teardown     calls dst_cache_destroy() on its replicast caches before calling synchronize_net() to wait for concurrent     RCU readers (transmitters) to finish: static void cleanup_bearer(struct work_struct *work) { ...
    list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) { dst_cache_destroy(&rcast->dst_cache);
    list_del_rcu(&rcast->list); kfree_rcu(rcast, rcu); } ... dst_cache_destroy(&ub->rcast.dst_cache);
    udp_tunnel_sock_release(ub->sk); synchronize_net(); ... } This is highly buggy because dst_cache_destroy()     immediately frees the per-CPU cache memory (free_percpu()) and releases the cached dst entries without any     synchronization. If a concurrent transmitter (e.g., tipc_udp_xmit()) is running on another CPU under RCU     protection, it can call dst_cache_get() concurrently, leading to: 1. Use-After-Free on the per-CPU cache     pointer itself (crash). 2. rcuref - imbalanced put() warning if it attempts to release a dst that was     concurrently released by dst_cache_destroy(). Furthermore, calling kfree(ub) immediately after     synchronize_net() without closing the socket first (or waiting after closing it) leaves a window where a     concurrent receiver (tipc_udp_recv()) could start after synchronize_net(), access ub, and suffer a UAF     when kfree(ub) runs. To fix this, we must defer dst_cache_destroy() and kfree(ub) until after we have     ensured that no more readers can see the bearer/socket and all existing readers have finished: 1. Defer     rcast entry destruction (both dst_cache_destroy() and kfree()) to an RCU callback using call_rcu_hurry().
    Using call_rcu_hurry() ensures the dst entries are released quickly. 2. Release the bearer socket using     udp_tunnel_sock_release() (stops new receive readers). 3. Call synchronize_net() to wait for all     outstanding RCU readers (both transmit and receive) to finish. 4. Now that it is safe, call     dst_cache_destroy() on the main bearer cache, and free ub. Note: 3) and 4) can be changed later in net-     next to also use call_rcu_hurry() and get rid of the synchronize_net() latency. (CVE-2026-72404)

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

ID	Name	Product	Family	Type	Severity
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
377900	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3402)	Nessus	Amazon Linux Local Security Checks	Local	high
376875	EulerOS 2.0 SP12 : kernel (EulerOS-SA-2026-4411)	Nessus	Huawei Local Security Checks	Local	high
376715	EulerOS 2.0 SP12 : kernel (EulerOS-SA-2026-4488)	Nessus	Huawei Local Security Checks	Local	high
369491	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792445930)	Nessus	Rocky Linux Local Security Checks	Local	high
369490	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1792445930)	Nessus	Alma Linux Local Security Checks	Local	high
366742	SUSE SLED15: cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc (SUSE-SU-2026:4706-1)	Nessus	SuSE Local Security Checks	Local	high
365457	Ubuntu 24.04 LTS : Linux kernel (NVIDIA Tegra) vulnerabilities (USN-8886-1)	Nessus	Ubuntu Local Security Checks	Local	high
335701	Linux Distros Unpatched Vulnerability : CVE-2026-72404	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-72404

high

Tenable Plugins

Coming Soon

high

high

high

high

high

high

high

high

high