In the Linux kernel, the following vulnerability has been resolved: ACPI: platform: Use acpi_bus_get_primary_device() The acpi_get_first_physical_node() usage in acpi_platform_fill_resource() and acpi_create_platform_device() is generally unsafe because in theory the device returned by it may be freed at any time [1]. It is also inefficient because acpi_get_first_physical_node() is called multiple times for the same argument which can be avoided. Address these issues by using acpi_bus_get_primary_device() instead of acpi_get_first_physical_node() and adjusting the code to call it just once at the beginning of and acpi_create_platform_device() and drop the device reference acquired by it upon the return from that function.

amazon_alas ALAS2023-2026-3402: Amazon Linux 2023 Security Advisory:ALAS2023-2026-3402

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

  - In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix premature hw access     after PCI error After a recoverable PCI error has been detected and recovered, qla driver needs to check     to see if the error condition still persist and/or wait for the OS to give the resume signal. Sep 8     22:26:03 localhost kernel: WARNING: CPU: 9 PID: 124606 at qla_tmpl.c:440 qla27xx_fwdt_entry_t266+0x55/0x60     [qla2xxx] Sep 8 22:26:03 localhost kernel: RIP: 0010:qla27xx_fwdt_entry_t266+0x55/0x60 [qla2xxx] Sep 8     22:26:03 localhost kernel: Call Trace: Sep 8 22:26:03 localhost kernel: ? qla27xx_walk_template+0xb1/0x1b0     [qla2xxx] Sep 8 22:26:03 localhost kernel: ? qla27xx_execute_fwdt_template+0x12a/0x160 [qla2xxx] Sep 8     22:26:03 localhost kernel: ? qla27xx_fwdump+0xa0/0x1c0 [qla2xxx] Sep 8 22:26:03 localhost kernel: ?     qla2xxx_pci_mmio_enabled+0xfb/0x120 [qla2xxx] Sep 8 22:26:03 localhost kernel: ?     report_mmio_enabled+0x44/0x80 Sep 8 22:26:03 localhost kernel: ? report_slot_reset+0x80/0x80 Sep 8     22:26:03 localhost kernel: ? pci_walk_bus+0x70/0x90 Sep 8 22:26:03 localhost kernel: ?     aer_dev_correctable_show+0xc0/0xc0 Sep 8 22:26:03 localhost kernel: ? pcie_do_recovery+0x1bb/0x240 Sep 8     22:26:03 localhost kernel: ? aer_recover_work_func+0xaa/0xd0 Sep 8 22:26:03 localhost kernel: ?     process_one_work+0x1a7/0x360 .. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-8041:22: detected     PCI disconnect. Sep 8 22:26:03 localhost kernel: qla2xxx [0000:42:00.2]-107ff:22: qla27xx_fwdt_entry_t262:
    dump ram MB failed. Area 5h start 198013h end 198013h Sep 8 22:26:03 localhost kernel: qla2xxx     [0000:42:00.2]-107ff:22: Unable to capture FW dump Sep 8 22:26:03 localhost kernel: qla2xxx     [0000:42:00.2]-1015:22: cmd=0x0, waited 5221 msecs Sep 8 22:26:03 localhost kernel: qla2xxx     [0000:42:00.2]-680d:22: mmio enabled returning. Sep 8 22:26:03 localhost kernel: qla2xxx     [0000:42:00.2]-d04c:22: MBX Command timeout for cmd 0, iocontrol=ffffffff jiffies=10140f2e5     mb[0-3]=[0xffff 0xffff 0xffff 0xffff] (CVE-2022-49157)

  - 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: crypto: qat - fix DMA transfer     direction When CONFIG_DMA_API_DEBUG is selected, while running the crypto self test on the QAT crypto     algorithms, the function add_dma_entry() reports a warning similar to the one below, saying that     overlapping mappings are not supported. This occurs in tests where the input and the output scatter list     point to the same buffers (i.e. two different scatter lists which point to the same chunks of memory). The     logic that implements the mapping uses the flag DMA_BIDIRECTIONAL for both the input and the output     scatter lists which leads to overlapped write mappings. These are not supported by the DMA layer. Fix by     specifying the correct DMA transfer directions when mapping buffers. For in-place operations where the     input scatter list matches the output scatter list, buffers are mapped once with DMA_BIDIRECTIONAL,     otherwise input buffers are mapped using the flag DMA_TO_DEVICE and output buffers are mapped with     DMA_FROM_DEVICE. Overlapping a read mapping with a write mapping is a valid case in dma-coherent devices     like QAT. The function that frees and unmaps the buffers, qat_alg_free_bufl() has been changed accordingly     to the changes to the mapping function. DMA-API: 4xxx 0000:06:00.0: cacheline tracking EEXIST, overlapping     mappings aren't supported WARNING: CPU: 53 PID: 4362 at kernel/dma/debug.c:570 add_dma_entry+0x1e9/0x270     ... Call Trace: dma_map_page_attrs+0x82/0x2d0 ? preempt_count_add+0x6a/0xa0     qat_alg_sgl_to_bufl+0x45b/0x990 [intel_qat] qat_alg_aead_dec+0x71/0x250 [intel_qat]     crypto_aead_decrypt+0x3d/0x70 test_aead_vec_cfg+0x649/0x810 ? number+0x310/0x3a0 ? vsnprintf+0x2a3/0x550 ?     scnprintf+0x42/0x70 ? valid_sg_divisions.constprop.0+0x86/0xa0 ? test_aead_vec+0xdf/0x120     test_aead_vec+0xdf/0x120 alg_test_aead+0x185/0x400 alg_test+0x3d8/0x500 ?     crypto_acomp_scomp_free_ctx+0x30/0x30 ? __schedule+0x32a/0x12a0 ? ttwu_queue_wakelist+0xbf/0x110 ?
    _raw_spin_unlock_irqrestore+0x23/0x40 ? try_to_wake_up+0x83/0x570 ? _raw_spin_unlock_irqrestore+0x23/0x40     ? __set_cpus_allowed_ptr_locked+0xea/0x1b0 ? crypto_acomp_scomp_free_ctx+0x30/0x30     cryptomgr_test+0x27/0x50 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30     (CVE-2022-50774)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: cfg80211: Pass the PMK     in binary instead of hex Apparently the hex passphrase mechanism does not work on newer chips/firmware     (e.g. BCM4387). It seems there was a simple way of passing it in binary all along, so use that and avoid     the hexification. OpenBSD has been doing it like this from the beginning, so this should work on all     chips. Also clear the structure before setting the PMK. This was leaking uninitialized stack contents to     the device. (CVE-2023-53715)

  - In the Linux kernel, the following vulnerability has been resolved: posix-timers: Ensure timer ID search-     loop limit is valid posix_timer_add() tries to allocate a posix timer ID by starting from the cached ID     which was stored by the last successful allocation. This is done in a loop searching the ID space for a     free slot one by one. The loop has to terminate when the search wrapped around to the starting point. But     that's racy vs. establishing the starting point. That is read out lockless, which leads to the following     problem: CPU0 CPU1 posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add()     if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0; So CPU1 can observe a     negative start value, i.e. -1, and the loop break never happens because the condition can never be true:
    if (sig->posix_timer_id == start) break; While this is unlikely to ever turn into an endless loop as the     ID space is huge (INT_MAX), the racy read of the start value caught the attention of KCSAN and Dmitry     unearthed that incorrectness. Rewrite it so that all id operations are under the hash lock.
    (CVE-2023-53728)

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.

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

  - In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix vlan tunnel dst     refcnt when egressing The egress tunnel code uses dst_clone() and directly sets the result which is wrong     because the entry might have 0 refcnt or be already deleted, causing number of problems. It also triggers     the WARN_ON() in dst_hold()[1] when a refcnt couldn't be taken. Fix it by using dst_hold_safe() and     checking if a reference was actually taken before setting the dst. [1] dmesg WARN_ON log and following     refcnt errors WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134     [bridge] Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net CPU: 5 PID: 38 Comm:
    ksoftirqd/5 Kdump: loaded Tainted: G W 5.13.0-rc3+ #360 Hardware name: QEMU Standard PC (i440FX + PIIX,     1996), BIOS 1.14.0-1.fc33 04/01/2014 RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge] Code: e8     85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc     01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49 RSP:
    0018:ffff8881003d39e8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000     RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0 RBP: ffff8881040c6700 R08:
    0000000000000000 R09: 0000000000000001 R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000     R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401 FS: 0000000000000000(0000)     GS:ffff88822bf40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0 Call Trace: br_handle_vlan+0xbc/0xca [bridge]
    __br_forward+0x23/0x164 [bridge] deliver_clone+0x41/0x48 [bridge] br_handle_frame_finish+0x36f/0x3aa     [bridge] ? skb_dst+0x2e/0x38 [bridge] ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge] ?     br_handle_frame_finish+0x3aa/0x3aa [bridge] br_handle_frame+0x2c3/0x377 [bridge] ? __skb_pull+0x33/0x51 ?     vlan_do_receive+0x4f/0x36a ? br_handle_frame_finish+0x3aa/0x3aa [bridge]
    __netif_receive_skb_core+0x539/0x7c6 ? __list_del_entry_valid+0x16e/0x1c2
    __netif_receive_skb_list_core+0x6d/0xd6 netif_receive_skb_list_internal+0x1d9/0x1fa     gro_normal_list+0x22/0x3e dev_gro_receive+0x55b/0x600 ? detach_buf_split+0x58/0x140     napi_gro_receive+0x94/0x12e virtnet_poll+0x15d/0x315 [virtio_net] __napi_poll+0x2c/0x1c9     net_rx_action+0xe6/0x1fb __do_softirq+0x115/0x2d8 run_ksoftirqd+0x18/0x20 smpboot_thread_fn+0x183/0x19c ?     smpboot_unregister_percpu_thread+0x66/0x66 kthread+0x10a/0x10f ? kthread_mod_delayed_work+0xb6/0xb6     ret_from_fork+0x22/0x30 ---[ end trace 49f61b07f775fd2b ]--- dst_release: dst:00000000c02d677a refcnt:-1     dst_release underflow (CVE-2021-47222)

  - In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix vlan tunnel dst null     pointer dereference This patch fixes a tunnel_dst null pointer dereference due to lockless access in the     tunnel egress path. When deleting a vlan tunnel the tunnel_dst pointer is set to NULL without waiting a     grace period (i.e. while it's still usable) and packets egressing are dereferencing it without checking.
    Use READ/WRITE_ONCE to annotate the lockless use of tunnel_id, use RCU for accessing tunnel_dst and make     sure it is read only once and checked in the egress path. The dst is already properly RCU protected so we     don't need to do anything fancy than to make sure tunnel_id and tunnel_dst are read only once and checked     in the egress path. (CVE-2021-47223)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Guard stack limits against 32bit     overflow This patch promotes the arithmetic around checking stack bounds to be done in the 64-bit domain,     instead of the current 32bit. The arithmetic implies adding together a 64-bit register with a int offset.
    The register was checked to be below 1<<29 when it was variable, but not when it was fixed. The offset     either comes from an instruction (in which case it is 16 bit), from another register (in which case the     caller checked it to be below 1<<29 [1]), or from the size of an argument to a kfunc (in which case it can     be a u32 [2]). Between the register being inconsistently checked to be below 1<<29, and the offset being     up to an u32, it appears that we were open to overflowing the `int`s which were currently used for     arithmetic. [1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf     /verifier.c#L7494-L7498 [2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e     9/kernel/bpf/verifier.c#L11904 (CVE-2023-52676)

  - In the Linux kernel, the following vulnerability has been resolved: cifs: fix session state check in     reconnect to avoid use-after-free issue Don't collect exiting session in smb2_reconnect_server(), because     it will be released soon. Note that the exiting session will stay in server->smb_ses_list until it     complete the cifs_free_ipc() and logoff() and then delete itself from the list. (CVE-2023-53794)

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

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.

  - ACPI: platform: Use acpi_bus_get_primary_device() The acpi_get_first_physical_node() usage in     acpi_platform_fill_resource() and acpi_create_platform_device() is generally unsafe because in theory the     device returned by it may be freed at any time [1]. It is also inefficient because     acpi_get_first_physical_node() is called multiple times for the same argument which can be avoided.
    Address these issues by using acpi_bus_get_primary_device() instead of acpi_get_first_physical_node() and     adjusting the code to call it just once at the beginning of and acpi_create_platform_device() and drop the     device reference acquired by it upon the return from that function. (CVE-2026-100072)

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

ID	Name	Product	Family	Type	Severity
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	Local	high
375672	CentOS Linux 7 [TuxCare] Security Update: bpftool / kernel / kernel-debug / kernel-debug-devel / kernel-devel / etc Multiple Vulnerabilities (CENTOS7:CLSA-2026:1793321383)	Nessus	CentOS Local Security Checks	Local	high
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
371988	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1792979985)	Nessus	CentOS Local Security Checks	Local	high
350749	Linux Distros Unpatched Vulnerability : CVE-2026-100072	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-100072

high

Tenable Plugins

Coming Soon

high

high

high

high

high