In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2 gss_krb5_verify_mic_v2() reads the token ID at ptr[0..1], the flags byte at ptr[2], and padding at ptr[3..7], then passes ptr + GSS_KRB5_TOK_HDR_LEN and cksum_len to gss_krb5_mic_build_sg(). None of these accesses check read_token->len first. The minimum safe token size is GSS_KRB5_TOK_HDR_LEN (16) plus ctx->krb5e->cksum_len (12-24, depending on the enctype). All callers accept shorter tokens from the wire: - gss_unwrap_resp_integ() enforces only an upper bound (offset + len <= rcv_buf->len) before allocating mic.data = kmalloc(len) and passing it to gss_verify_mic(). A malicious NFS server can therefore supply a short checksum opaque, producing a small slab allocation that the Kerberos MIC verifier reads past. - gss_validate() enforces only len <= RPC_MAX_AUTH_SIZE (400) before passing the wire-supplied length to gss_validate_seqno_mic(), which constructs a mic xdr_netobj and calls gss_verify_mic(). - svcauth_gss_verify_header() enforces only checksum.len >= XDR_UNIT (4 bytes) before dispatching to gss_verify_mic(). - svcauth_gss_unwrap_integ() checks only that the checksum fits in gsd->gsd_scratch. Add a length guard at the top of gss_krb5_verify_mic_v2(), before any ptr[] access or scatterlist construction. Well-formed MIC tokens from gss_krb5_get_mic_v2() already have exactly GSS_KRB5_TOK_HDR_LEN + cksum_len bytes, so valid traffic is unaffected.

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

  - In the Linux kernel, the following vulnerability has been resolved: mrp: introduce active flags to prevent     UAF when applicant uninit The caller of del_timer_sync must prevent restarting of the timer, If we have no     this synchronization, there is a small probability that the cancellation will not be successful. And     syzbot report the fellowing crash: ================================================================== BUG:
    KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline] BUG: KASAN: use-after-free in     enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 Write at addr f9ff000024df6058 by task syz-fuzzer/2256     Pointer tag: [f9], memory tag: [fe] CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted     6.1.0-rc5-syzkaller-00008- ge01d50cbd6ee #0 Hardware name: linux,dummy-virt (DT) Call trace:
    dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace     arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106     print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395     kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320     do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749     do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367     el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68     arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4     kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm     net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627     call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4     kernel/time/timer.c:1519 To fix it, we can introduce a new active flags to make sure the timer will not     restart. (CVE-2022-50697)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: add peer map clean up     for peer delete in ath10k_sta_state() When peer delete failed in a disconnect operation, use-after-free     detected by KFENCE in below log. It is because for each vdev_id and address, it has only one struct     ath10k_peer, it is allocated in ath10k_peer_map_event(). When connected to an AP, it has more than one     HTT_T2H_MSG_TYPE_PEER_MAP reported from firmware, then the array peer_map of struct ath10k will be set     muti-elements to the same ath10k_peer in ath10k_peer_map_event(). When peer delete failed in     ath10k_sta_state(), the ath10k_peer will be free for the 1st peer id in array peer_map of struct ath10k,     and then use-after-free happened for the 2nd peer id because they map to the same ath10k_peer. And clean     up all peers in array peer_map for the ath10k_peer, then user-after-free disappeared peer map event log: [     306.911021] wlan0: authenticate with b0:2a:43:e6:75:0e [ 306.957187] ath10k_pci 0000:01:00.0: mac vdev 0     peer create b0:2a:43:e6:75:0e (new sta) sta 1 / 32 peer 1 / 33 [ 306.957395] ath10k_pci 0000:01:00.0: htt     peer map vdev 0 peer b0:2a:43:e6:75:0e id 246 [ 306.957404] ath10k_pci 0000:01:00.0: htt peer map vdev 0     peer b0:2a:43:e6:75:0e id 198 [ 306.986924] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer     b0:2a:43:e6:75:0e id 166 peer unmap event log: [ 435.715691] wlan0: deauthenticating from     b0:2a:43:e6:75:0e by local choice (Reason: 3=DEAUTH_LEAVING) [ 435.716802] ath10k_pci 0000:01:00.0: mac     vdev 0 peer delete b0:2a:43:e6:75:0e sta ffff990e0e9c2b50 (sta gone) [ 435.717177] ath10k_pci     0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 246 [ 435.717186] ath10k_pci 0000:01:00.0:
    htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 198 [ 435.717193] ath10k_pci 0000:01:00.0: htt peer unmap     vdev 0 peer b0:2a:43:e6:75:0e id 166 use-after-free log: [21705.888627] wlan0: deauthenticating from     d0:76:8f:82:be:75 by local choice (Reason: 3=DEAUTH_LEAVING) [21713.799910] ath10k_pci 0000:01:00.0:
    failed to delete peer d0:76:8f:82:be:75 for vdev 0: -110 [21713.799925] ath10k_pci 0000:01:00.0: found sta     peer d0:76:8f:82:be:75 (ptr 0000000000000000 id 102) entry on vdev 0 after it was supposedly removed     [21713.799968] ================================================================== [21713.799991] BUG:
    KFENCE: use-after-free read in ath10k_sta_state+0x265/0xb8a [ath10k_core] [21713.799991] [21713.799997]     Use-after-free read at 0x00000000abe1c75e (in kfence-#69): [21713.800010] ath10k_sta_state+0x265/0xb8a     [ath10k_core] [21713.800041] drv_sta_state+0x115/0x677 [mac80211] [21713.800059]
    __sta_info_destroy_part2+0xb1/0x133 [mac80211] [21713.800076] __sta_info_flush+0x11d/0x162 [mac80211]     [21713.800093] ieee80211_set_disassoc+0x12d/0x2f4 [mac80211] [21713.800110]     ieee80211_mgd_deauth+0x26c/0x29b [mac80211] [21713.800137] cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211]     [21713.800153] nl80211_deauthenticate+0xf8/0x121 [cfg80211] [21713.800161] genl_rcv_msg+0x38e/0x3be     [21713.800166] netlink_rcv_skb+0x89/0xf7 [21713.800171] genl_rcv+0x28/0x36 [21713.800176]     netlink_unicast+0x179/0x24b [21713.800181] netlink_sendmsg+0x3a0/0x40e [21713.800187]     sock_sendmsg+0x72/0x76 [21713.800192] ____sys_sendmsg+0x16d/0x1e3 [21713.800196] ___sys_sendmsg+0x95/0xd1     [21713.800200] __sys_sendmsg+0x85/0xbf [21713.800205] do_syscall_64+0x43/0x55 [21713.800210]     entry_SYSCALL_64_after_hwframe+0x44/0xa9 [21713.800213] [21713.800219] kfence-#69:
    0x000000009149b0d5-0x000000004c0697fb, size=1064, cache=kmalloc-2k [21713.800219] [21713.800224] allocated     by task 13 on cpu 0 at 21705.501373s: [21713.800241] ath10k_peer_map_event+0x7e/0x154 [ath10k_core]     [21713.800254] ath10k_htt_t2h_msg_handler+0x586/0x1039 [ath10k_core] [21713.800265]     ath10k_htt_htc_t2h_msg_handler+0x12/0x28 [ath10k_core] [21713.800277]     ath10k_htc_rx_completion_handler+0x14c/0x1b5 [ath10k_core] [21713.800283]     ath10k_pci_process_rx_cb+0x195/0x1d ---truncated--- (CVE-2022-50880)

  - In the Linux kernel, the following vulnerability has been resolved: ubi: Fix use-after-free when volume     resizing failed There is an use-after-free problem reported by KASAN:
    ================================================================== BUG: KASAN: use-after-free in     ubi_eba_copy_table+0x11f/0x1c0 [ubi] Read of size 8 at addr ffff888101eec008 by task ubirsvol/4735 CPU: 2     PID: 4735 Comm: ubirsvol Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14 Hardware name: QEMU Standard     PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44     print_report+0x171/0x472 kasan_report+0xad/0x130 ubi_eba_copy_table+0x11f/0x1c0 [ubi]     ubi_resize_volume+0x4f9/0xbc0 [ubi] ubi_cdev_ioctl+0x701/0x1850 [ubi] __x64_sys_ioctl+0x11d/0x170     do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> When ubi_change_vtbl_record()     returns an error in ubi_resize_volume(), new_eba_tbl will be freed on error handing path, but it is     holded by vol->eba_tbl in ubi_eba_replace_table(). It means that the liftcycle of vol->eba_tbl and     vol are different, so when resizing volume in next time, it causing an use-after-free fault. Fix it by     not freeing new_eba_tbl after it replaced in ubi_eba_replace_table(), while will be freed in next volume     resizing. (CVE-2023-53800)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: essiv - Handle EBUSY correctly     As it is essiv only handles the special return value of EINPROGERSS, which means that in all other cases     it will free data related to the request. However, as the caller of essiv may specify MAY_BACKLOG, we also     need to expect EBUSY and treat it in the same way. Otherwise backlogged requests will trigger a use-after-     free. (CVE-2023-54046)

  - In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in     qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (net: be more gentle about silly gso requests     coming from user) virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space     to cook a bad GSO packet. Then commit cf9acc90c80ec (net: virtio_net_hdr_to_skb: count transport header     in UFO) while fixing one issue, allowed user space to cook a GSO packet with the following characteristic     : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up     with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 :
    gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set     qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This     leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an     estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular     issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel     NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel     mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD     107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm:
    b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX,     1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue     (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [     70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00     eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49     All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp)     b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov     %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx     22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx     <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34     mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the     faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11     mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00     00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561]     RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI:
    0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09:
    ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [     70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS:
    000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES:
    0000 C ---truncated--- (CVE-2024-49949)

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

The CentOS Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS-STREAM8:CLSA-2026:1792759740 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: mrp: introduce active flags to prevent     UAF when applicant uninit The caller of del_timer_sync must prevent restarting of the timer, If we have no     this synchronization, there is a small probability that the cancellation will not be successful. And     syzbot report the fellowing crash: ================================================================== BUG:
    KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline] BUG: KASAN: use-after-free in     enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 Write at addr f9ff000024df6058 by task syz-fuzzer/2256     Pointer tag: [f9], memory tag: [fe] CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted     6.1.0-rc5-syzkaller-00008- ge01d50cbd6ee #0 Hardware name: linux,dummy-virt (DT) Call trace:
    dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace     arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106     print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395     kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320     do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749     do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367     el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68     arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4     kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm     net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627     call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4     kernel/time/timer.c:1519 To fix it, we can introduce a new active flags to make sure the timer will not     restart. (CVE-2022-50697)

  - In the Linux kernel, the following vulnerability has been resolved: ubi: Fix use-after-free when volume     resizing failed There is an use-after-free problem reported by KASAN:
    ================================================================== BUG: KASAN: use-after-free in     ubi_eba_copy_table+0x11f/0x1c0 [ubi] Read of size 8 at addr ffff888101eec008 by task ubirsvol/4735 CPU: 2     PID: 4735 Comm: ubirsvol Not tainted 6.1.0-rc1-00003-g84fa3304a7fc-dirty #14 Hardware name: QEMU Standard     PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x44     print_report+0x171/0x472 kasan_report+0xad/0x130 ubi_eba_copy_table+0x11f/0x1c0 [ubi]     ubi_resize_volume+0x4f9/0xbc0 [ubi] ubi_cdev_ioctl+0x701/0x1850 [ubi] __x64_sys_ioctl+0x11d/0x170     do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> When ubi_change_vtbl_record()     returns an error in ubi_resize_volume(), new_eba_tbl will be freed on error handing path, but it is     holded by vol->eba_tbl in ubi_eba_replace_table(). It means that the liftcycle of vol->eba_tbl and     vol are different, so when resizing volume in next time, it causing an use-after-free fault. Fix it by     not freeing new_eba_tbl after it replaced in ubi_eba_replace_table(), while will be freed in next volume     resizing. (CVE-2023-53800)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before     using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any     validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a     user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to     user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an     out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to     userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory     allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which     properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same     validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).
    (CVE-2026-45856)

  - In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in     qd_put Commit a475c5dd16e5 (gfs2: Free quota data objects synchronously) started freeing quota data     objects during filesystem shutdown instead of putting them back onto the LRU list, but it failed to remove     these objects from the LRU list, causing LRU list corruption. This caused use-after-free when the shrinker     (gfs2_qd_shrink_scan) tried to access already-freed objects on the LRU list. Fix this by removing qd     objects from the LRU list before freeing them in qd_put(). Initial fix from Deepanshu Kartikey     <kartikey406@gmail.com>. (CVE-2026-45861)

  - In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in iomap     inline data write path The inline data buffer head (dibh) is being released prematurely in     gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This     causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area. The     bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2.
    Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which     calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report)     5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write     to freed memory Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in     gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write     completes, ensuring the page stays alive for the entire iomap operation. Note: A C reproducer is not     available for this issue. The fix is based on analysis of the KASAN report and code review showing the     buffer head is freed before use. [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid     leaks in gfs2_iomap_get() and gfs2_iomap_alloc().] (CVE-2026-45984)

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

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: RDMA: Fix use-after-free in     rxe_queue_cleanup On error handling path in rxe_qp_from_init() qp->sq.queue is freed and then     rxe_create_qp() will drop last reference to this object. qp clean up function will try to free this queue     one time and it causes UAF bug. Fix it by zeroing queue pointer after freeing queue in rxe_qp_from_init().
    (CVE-2021-47616)

  - In the Linux kernel, the following vulnerability has been resolved: mrp: introduce active flags to prevent     UAF when applicant uninit The caller of del_timer_sync must prevent restarting of the timer, If we have no     this synchronization, there is a small probability that the cancellation will not be successful. And     syzbot report the fellowing crash: ================================================================== BUG:
    KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline] BUG: KASAN: use-after-free in     enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 Write at addr f9ff000024df6058 by task syz-fuzzer/2256     Pointer tag: [f9], memory tag: [fe] CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted     6.1.0-rc5-syzkaller-00008- ge01d50cbd6ee #0 Hardware name: linux,dummy-virt (DT) Call trace:
    dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace     arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163
    __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106     print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395     kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320     do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749     do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367     el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68     arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4     kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm     net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627     call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4     kernel/time/timer.c:1519 To fix it, we can introduce a new active flags to make sure the timer will not     restart. (CVE-2022-50697)

  - In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: fix ->anon_vma race If     an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires it to be locked. Page table     traversal is allowed under any one of the mmap lock, the anon_vma lock (if the VMA is associated with an     anon_vma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove     page tables, we must hold all three of them. retract_page_tables() bails out if an ->anon_vma is attached,     but does this check before holding the mmap lock (as the comment above the check explains). If we racily     merged an existing ->anon_vma (shared with a child process) from a neighboring VMA, subsequent rmap     traversals on pages belonging to the child will be able to see the page tables that we are concurrently     removing while assuming that nothing else can access them. Repeat the ->anon_vma check once we hold the     mmap lock to ensure that there really is no concurrent page table access. Hitting this bug causes a     lockdep warning in collapse_and_free_pmd(), in the line     lockdep_assert_held_write(&vma->anon_vma->root->rwsem). It can also lead to use-after-free access.
    (CVE-2023-52935)

  - In the Linux kernel, the following vulnerability has been resolved: SUNRPC: make sure cache entry active     before cache_show The function `c_show` was called with protection from RCU. This only ensures that `cp`     will not be freed. Therefore, the reference count for `cp` can drop to zero, which will trigger a refcount     use-after-free warning when `cache_get` is called. To resolve this issue, use `cache_get_rcu` to ensure     that `cp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822     Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS     1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 Call Trace: <TASK> c_show+0x2fc/0x380     [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530     ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e (CVE-2024-53174)

  - In the Linux kernel, the following vulnerability has been resolved: net: skbuff: propagate shared-frag     marker through frag-transfer helpers Two frag-transfer helpers (__pskb_copy_fclone() and skb_shift()) fail     to propagate the SKBFL_SHARED_FRAG bit in skb_shinfo()->flags when moving frags from source to     destination. __pskb_copy_fclone() defers the rest of the shinfo metadata to skb_copy_header() after     copying frag descriptors, but that helper only carries over gso_{size,segs, type} and never touches     skb_shinfo()->flags; skb_shift() moves frag descriptors directly and leaves flags untouched. As a result,     the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while     reporting skb_has_shared_frag() as false. The mismatch is harmful in any in-place writer that uses     skb_has_shared_frag() to decide whether shared pages must be detoured through skb_cow_data(). ESP input is     one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nf_dup_ipv4() /     xt_TEE caller -- is enough to land a pskb_copy()'d skb in esp_input() with the marker stripped, letting an     unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray     writes. Set SKBFL_SHARED_FRAG on the destination whenever frag descriptors were actually moved from the     source. skb_copy() and skb_copy_expand() share skb_copy_header() too but linearize all paged data into     freshly allocated head storage and emerge with nr_frags == 0, so skb_has_shared_frag() returns false on     its own; they need no change. The same omission exists in skb_gro_receive() and skb_gro_receive_list().
    The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a     direct frag-move loop and the head_frag + memcpy path); the latter chains the incoming skb whole onto p's     frag_list. Downstream skb_segment() reads only skb_shinfo(p)->flags, and skb_segment_list() reuses each     sub-skb's shinfo as the nskb -- both p and lp must carry the marker. The same omission also exists in     tcp_clone_payload(), which builds an MTU probe skb by moving frag descriptors from skbs on sk_write_queue     into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for     consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but     a future consumer depending on the marker would regress silently. The same omission exists in     skb_segment(): the per-iteration flag merge takes only head_skb's flag, and the inner switch that rebinds     frag_skb to list_skb on head_skb-frags exhaustion does not fold the new frag_skb's flag into nskb. Fold     frag_skb's flag at both sites so segments drawing frags from frag_list members carry the marker.
    (CVE-2026-43503)

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.

  - SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2 gss_krb5_verify_mic_v2() reads the     token ID at ptr[0..1], the flags byte at ptr[2], and padding at ptr[3..7], then passes ptr +     GSS_KRB5_TOK_HDR_LEN and cksum_len to gss_krb5_mic_build_sg(). None of these accesses check     read_token->len first. The minimum safe token size is GSS_KRB5_TOK_HDR_LEN (16) plus ctx->krb5e->cksum_len     (12-24, depending on the enctype). All callers accept shorter tokens from the wire: -     gss_unwrap_resp_integ() enforces only an upper bound (offset + len <= rcv_buf->len) before allocating     mic.data = kmalloc(len) and passing it to gss_verify_mic(). A malicious NFS server can therefore supply a     short checksum opaque, producing a small slab allocation that the Kerberos MIC verifier reads past. -     gss_validate() enforces only len <= RPC_MAX_AUTH_SIZE (400) before passing the wire-supplied length to     gss_validate_seqno_mic(), which constructs a mic xdr_netobj and calls gss_verify_mic(). -     svcauth_gss_verify_header() enforces only checksum.len >= XDR_UNIT (4 bytes) before dispatching to     gss_verify_mic(). - svcauth_gss_unwrap_integ() checks only that the checksum fits in gsd->gsd_scratch. Add     a length guard at the top of gss_krb5_verify_mic_v2(), before any ptr[] access or scatterlist     construction. Well-formed MIC tokens from gss_krb5_get_mic_v2() already have exactly GSS_KRB5_TOK_HDR_LEN     + cksum_len bytes, so valid traffic is unaffected. (CVE-2026-89537)

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

ID	Name	Product	Family	Type	Severity
372044	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1792979607)	Nessus	CentOS Local Security Checks	Local	high
371420	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1792759740)	Nessus	CentOS Local Security Checks	Local	high
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	Local	high
345147	Linux Distros Unpatched Vulnerability : CVE-2026-89537	Nessus	Misc.	Local	critical

Detections

Analytics

CVE-2026-89537

critical

Tenable Plugins

high

high

high

critical