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

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix race between     dump and ip_set_list resize The release path of ip_set_dump_do() and ip_set_dump_done() read     inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run     from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent     ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s     the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait     for them and the old array can be freed while they still index into it, causing a use-after-free. The     dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take     rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-     after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr     ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do     (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg     (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ...
    Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-     memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do     (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception (CVE-2026-64189)

  - In the Linux kernel, the following vulnerability has been resolved: dm log: fix out-of-bounds write due to     region_count overflow The local variable region_count in create_log_context() is declared as unsigned int     (32-bit), but dm_sector_div_up() returns sector_t (64-bit). When a device-mapper target has a sufficiently     large ti->len with a small region_size, the division result can exceed UINT_MAX. The truncated value is     then used to calculate bitset_size, causing clean_bits, sync_bits, and recovering_bits to be allocated far     smaller than needed for the actual number of regions. Subsequent log operations (log_set_bit,     log_clear_bit, log_test_bit) use region indices derived from the full untruncated region space, causing     out-of-bounds writes to kernel heap memory allocated by vmalloc. This can be reproduced by creating a     mirror target whose region_count overflows 32 bits: dmsetup create bigzero --table '0 8589934594 zero'     dmsetup create mymirror --table '0 8589934594 mirror \ core 2 2 nosync 2 /dev/mapper/bigzero 0 \     /dev/mapper/bigzero 0' The status output confirms the truncation (sync_count=1 instead of 4294967297,     because 0x100000001 was truncated to 1): $ dmsetup status mymirror 0 8589934594 mirror 2 254:1 254:1     1/4294967297 ... This leads to a kernel crash in core_in_sync: BUG: scheduling while atomic: (udev-     worker)/9150/0x00000000 RIP: 0010:core_in_sync+0x14/0x30 [dm_log] CR2: 0000000000000008 Fixing recursive     fault but reboot is needed! Fix by widening the local region_count to sector_t and adding an explicit     overflow check before the value is assigned to lc->region_count. (CVE-2026-53059)

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: fix fib6 walker UAF on seq stop     ipv6_route_iter_active() treats a walker in FWS_U at the table root as already unlinked. fib6_del_route()     can move a still-linked walker into that same state when the current leaf is the last route at the root,     so ipv6_route_native_seq_stop() skips fib6_walker_unlink(). The seq private object can then be freed while     it remains on net->ipv6.fib6_walkers. A later route deletion walks the dangling list and uses the freed     walker. Use the list head as membership state and reinitialize it when unlinking. Keep the existing     w->node check so a never-started iterator with a zeroed private object is not treated as linked. The same     stop helper is used by /proc/net/ipv6_route and by the BPF ipv6_route iterator. The BPF show path only     widens the race. (CVE-2026-97940)

  - In the Linux kernel, the following vulnerability has been resolved: net: bridge: stop fast-leave after     deleting a port group br_multicast_leave_group() iterates mp->ports with pp = &p->next in its fast-leave     path. After br_multicast_del_pg() removes p, continuing the loop advances pp through the deleted entry. If     multicast-to-unicast was enabled, the bridge can hold multiple port groups for the same port and group     with different source MAC addresses. Once multicast-to-unicast is disabled, br_port_group_equal() matches     those entries by port only. A fast leave can then delete one entry and continue from its stale next     pointer, leaving mp->ports pointing at a deleted port group. Fast leave only needs to remove one matching     port group. Break after br_multicast_del_pg() so the loop stops before dereferencing the removed entry.
    (CVE-2026-74480)

  - In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix possible use after free     In dma_release_channel(), check chan->device->privatecnt after call dma_chan_put(). However,     dma_chan_put() call dma_device_put() which could release the last reference of the device if the DMA     provider is already gone and hence free it. Fixes it by moving dma_chan_put() after the check.
    (CVE-2026-72476)

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.

ID	名稱	產品	系列	已發布	已更新	嚴重性
371224	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1792750763)	Nessus	CentOS Local Security Checks	2026/10/23	2026/11/12	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	2026/10/21	2026/11/13	high

偵測

搜尋 Plugin

high

high