In the Linux kernel, the following vulnerability has been resolved: xfrm: hold net_device reference under RCU in bundle creation xfrm_bundle_create() and xfrm_create_dummy_bundle() read dst->dev into a local pointer without taking a device reference, then pass it to xfrm_fill_dst(). A concurrent RTM_DELLINK replaces dst->dev via dst_dev_put() and frees the old net_device, causing a use-after-free when xfrm6_fill_dst() later dereferences the stale dev pointer. BUG: KASAN: slab-use-after-free in xfrm6_fill_dst+0x82c/0x860 (net/ipv6/xfrm6_policy.c:86 netdev_hold()) Read of size 8 at addr ffff8880142fe588 by task exploit/153 Call Trace: xfrm6_fill_dst+0x82c/0x860 xfrm_resolve_and_create_bundle+0x21d4/0x2bd0 xfrm_lookup_with_ifid+0x485/0x1640 ip6_dst_lookup_flow+0x19b/0x1e0 udpv6_sendmsg+0x1443/0x2dd0 Fix this by reading dst->dev via dst_dev_rcu() and keeping the RCU read-side critical section active until xfrm_fill_dst() has taken the required device references.

The CentOS Linux 7 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS7:CLSA-2026:1792751247 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: mmmremap.c: avoid pointless     invalidate_range_start/end on mremap(old_size=0) If an mremap() syscall with old_size=0 ends up in     move_page_tables(), it will call invalidate_range_start()/invalidate_range_end() unnecessarily, i.e. with     an empty range. This causes a WARN in KVM's mmu_notifier. In the past, empty ranges have been diagnosed to     be off-by-one bugs, hence the WARNing. Given the low (so far) number of unique reports, the benefits of     detecting more buggy callers seem to outweigh the cost of having to fix cases such as this one, where     userspace is doing something silly. In this particular case, an early return from move_page_tables() is     enough to fix the issue. (CVE-2022-49077)

  - In the Linux kernel, the following vulnerability has been resolved: virtio_console: eliminate anonymous     module_init & module_exit Eliminate anonymous module_init() and module_exit(), which can lead to confusion     or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log. Give each of these init     and exit functions unique driver-specific names to eliminate the anonymous names. Example 1: (System.map)     ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init Example 2: (initcall_debug log)     calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1     initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned     0 after 74 usecs (CVE-2022-49100)

  - In the Linux kernel, the following vulnerability has been resolved: mtd: Fix device name leak when     register device failed in add_mtd_device() There is a kmemleak when register device failed: unreferenced     object 0xffff888101aab550 (size 8): comm insmod, pid 3922, jiffies 4295277753 (age 925.408s) hex dump     (first 8 bytes): 6d 74 64 30 00 88 ff ff mtd0.... backtrace: [<00000000bde26724>]
    __kmalloc_node_track_caller+0x4e/0x150 [<000000003c32b416>] kvasprintf+0xb0/0x130 [<000000001f7a8f15>]     kobject_set_name_vargs+0x2f/0xb0 [<000000006e781163>] dev_set_name+0xab/0xe0 [<00000000e30d0c78>]     add_mtd_device+0x4bb/0x700 [<00000000f3d34de7>] mtd_device_parse_register+0x2ac/0x3f0 [<00000000c0d88488>]     0xffffffffa0238457 [<00000000b40d0922>] 0xffffffffa02a008f [<0000000023d17b9d>] do_one_initcall+0x87/0x2a0     [<00000000770f6ca6>] do_init_module+0xdf/0x320 [<000000007b6768fe>] load_module+0x2f98/0x3330     [<00000000346bed5a>] __do_sys_finit_module+0x113/0x1b0 [<00000000674c2290>] do_syscall_64+0x35/0x80     [<000000004c6a8d97>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 If register device failed, should call     put_device() to give up the reference. (CVE-2022-50566)

  - In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: fix leak of     memory fw (CVE-2022-50664)

  - In the Linux kernel, the following vulnerability has been resolved: acct: fix potential integer overflow     in encode_comp_t() The integer overflow is descripted with following codes: > 317 static comp_t     encode_comp_t(u64 value) > 318 { > 319 int exp, rnd; ...... > 341 exp <<= MANTSIZE; > 342 exp += value; >     343 return exp; > 344 } Currently comp_t is defined as type of '__u16', but the variable 'exp' is type of     'int', so overflow would happen when variable 'exp' in line 343 is greater than 65535. (CVE-2022-50749)

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.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.

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

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

    bpf: Fix UAF in sock clone early bailouts (CVE-2026-68399)

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

    btrfs: initialize inode mapping flags for cached inodes (CVE-2026-80734)

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

    bpf: Mark NULL kptr stores precise (CVE-2026-98034)

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

    bpf: backtracking shouldn't clear outer frame R1-R5 for callbacks (CVE-2026-98084)

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

    xfrm: hold net_device reference under RCU in bundle creation (CVE-2026-98364)

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

    mm/hugetlb: preserve mremap address delta when skipping page tables (CVE-2026-98373)

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

    tcp: fix use-after-free of retransmit_skb_hint in tcp_send_synack() (CVE-2026-98374)

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

    xen/netfront: drop RX packets with a short Ethernet header (CVE-2026-98375)

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

    vlan: require the MAC header to be present in __vlan_insert_inner_tag() (CVE-2026-98377)

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

    bpf: Skip unsettled links in link iterator (CVE-2026-98378)

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

    netfilter: ip6t_rpfilter: reject routes without inet6_dev (CVE-2026-98379)

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

    net/sched: reject IDR error pointers when deleting actions (CVE-2026-98380)

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

    veth: manage XDP program pointers during channel resize (CVE-2026-98381)

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

    bpf: Reject dev-bound-only programs on other devices (CVE-2026-98382)

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

    bpf: Disallow bpf_skb_pull_data() for LWT_SEG6LOCAL (CVE-2026-98383)

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

    bpf: Fix out-of-bounds read of sk_protocol in bpf_sock_destroy() (CVE-2026-98384)

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

    ipv4: free inet_opt and ireq_opt after an RCU grace period (CVE-2026-98432)

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 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 AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1792751700 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix signed integer overflow in     l2tp_ip6_sendmsg When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we     can follow what udpv6 does and subtract the transhdrlen from the max. (CVE-2022-49727)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack     slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since     6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses     were permitted above state->allocated_stack, but not below it. In other words, if the stack was already     large enough, the access was permitted, but otherwise the access was rejected instead of being allowed     to grow the stack. This undesired rejection was happening in two places: - in     check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these     accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of     them were changed to add also run unprivileged, in which case the old behavior persists. One tests     couldn't be updated - global_func16 - because it can't run unprivileged for other reasons. This patch also     fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same     commit as the first one because they're inter-related. Before this patch, writes to the stack using     registers containing a variable offset (as opposed to registers with fixed, known values) were not     properly contributing to the function's needed stack size. As a result, it was possible for a program to     verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been     allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth,     which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling     update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the     variable offset. This was incorrect; the minimum possible value of that register should be used instead.
    This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by     lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The     code is now simpler and more convincingly tracks the correct maximum stack size.
    check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this     helps with the fix for the first issue. A few tests were changed to also check the stack depth     computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.
    (CVE-2023-52452)

  - In the Linux kernel, the following vulnerability has been resolved: qed/qed_sriov: guard against NULL     derefs from qed_iov_get_vf_info We have to make sure that the info returned by the helper is valid before     using it. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.
    (CVE-2023-53066)

  - In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix a server shutdown leak Fix     a race where kthread_stop() may prevent the threadfn from ever getting called. If that happens the     svc_rqst will not be cleaned up. (CVE-2023-53131)

  - In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Add check for kstrdup Add     check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer     dereference. (CVE-2023-54189)

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

  - In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report     buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it     during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted     report. (CVE-2024-50302)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-     bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that     exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-     of-bounds accesses later, e.g. in usb_destroy_configuration. (CVE-2024-53197)

  - In the Linux kernel, the following vulnerability has been resolved: smb: client: reject userspace     cifs.spnego descriptions cifs.spnego key descriptions contain authority-bearing fields such as pid, uid,     creduid, and upcall_target that cifs.upcall treats as kernel-originating inputs. However, userspace can     also create keys of this type through request_key(2) or add_key(2), allowing those fields to be supplied     without CIFS origin. Only accept cifs.spnego descriptions while CIFS is using its private spnego_cred to     request the key. (CVE-2026-46243)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: serialize accept_q access     bt_sock_poll() walks the accept queue without synchronization, while child teardown can unlink the same     socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial     Bluetooth import. Protect accept_q with a dedicated lock for queue updates and polling. Also rework     bt_accept_dequeue() to take temporary child references under the queue lock before dropping it and locking     the child socket. (CVE-2026-52918)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: bridge: make ebt_snat ARP     rewrite writable The ebtables SNAT target keeps the Ethernet source address rewrite behind     skb_ensure_writable(skb, 0). This is intentional: at the bridge ebtables hooks the Ethernet header is     addressed through skb_mac_header()/eth_hdr(), while skb->data points at the Ethernet payload. Asking     skb_ensure_writable() for ETH_HLEN bytes would check the payload, not the Ethernet header, and would     reintroduce the small packet regression fixed by commit 63137bc5882a. However, the optional ARP sender     hardware address rewrite is different. It writes through skb_store_bits() at an offset relative to     skb->data: skb_store_bits(skb, sizeof(struct arphdr), info->mac, ETH_ALEN) skb_header_pointer() only     safely reads the ARP header; it does not make the later sender hardware address range writable. If that     range is still held in a nonlinear skb fragment backed by a splice-imported file page, skb_store_bits()     maps the frag page and copies the new MAC address directly into it. Ensure the ARP SHA range is writable     before reading the ARP header and before calling skb_store_bits(). (CVE-2026-53266)

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.

  - xfrm: hold net_device reference under RCU in bundle creation xfrm_bundle_create() and     xfrm_create_dummy_bundle() read dst->dev into a local pointer without taking a device reference, then pass     it to xfrm_fill_dst(). A concurrent RTM_DELLINK replaces dst->dev via dst_dev_put() and frees the old     net_device, causing a use-after-free when xfrm6_fill_dst() later dereferences the stale dev pointer. BUG:
    KASAN: slab-use-after-free in xfrm6_fill_dst+0x82c/0x860 (net/ipv6/xfrm6_policy.c:86 netdev_hold()) Read     of size 8 at addr ffff8880142fe588 by task exploit/153 Call Trace: xfrm6_fill_dst+0x82c/0x860     xfrm_resolve_and_create_bundle+0x21d4/0x2bd0 xfrm_lookup_with_ifid+0x485/0x1640     ip6_dst_lookup_flow+0x19b/0x1e0 udpv6_sendmsg+0x1443/0x2dd0 Fix this by reading dst->dev via dst_dev_rcu()     and keeping the RCU read-side critical section active until xfrm_fill_dst() has taken the required device     references. (CVE-2026-98364)

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

ID	Name	Product	Family	Type	Severity
372116	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1792751247)	Nessus	CentOS Local Security Checks	Local	medium
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
371850	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3251)	Nessus	Amazon Linux Local Security Checks	Local	critical
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
371223	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1792751700)	Nessus	Alma Linux Local Security Checks	Local	high
367921	CentOS Linux 6 [TuxCare] Security Update: kernel / kernel-abi-whitelists / kernel-debug / kernel-debug-devel / etc Multiple Vulnerabilities (CENTOS6:CLSA-2026:1791949745)	Nessus	CentOS Local Security Checks	Local	high
363245	Linux Distros Unpatched Vulnerability : CVE-2026-98364	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-98364

high

Tenable Plugins

medium

high

critical

high

high

high

high