In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit() There is a global-out-of-bounds reported by KASAN: BUG: KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411 CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ... kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae] rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae] ... </TASK> The root cause of the problem is that the comparison order of "prate_section" in _rtl8812ae_phy_set_txpower_limit() is wrong. The _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two strings from tail to head, which causes the problem. In the _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet this requirement by carefully designing the comparison order. For example, "pregulation" and "pbandwidth" are compared in order of length from small to large, first is 3 and last is 4. However, the comparison order of "prate_section" dose not obey such order requirement, therefore when "prate_section" is "HT", when comparing from tail to head, it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As mentioned above, the _rtl8812ae_eq_n_byte() has the same function as strcmp(), so just strcmp() is enough. Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order of "prate_section", this may cause the value of "rate_section" to not be from 0 to 5. In addition, commit "21e4b0726dc6" not only moved driver from staging to regular tree, but also added setting txpower limit function during the driver config phase, so the problem was introduced by this commit.

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

  - In the Linux kernel, the following vulnerability has been resolved: pid: take a reference when     initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct     pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will     increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via     put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never     incremented, can therefore free the init task's struct pid early. As there can be dangling references to     the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted     when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to     struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age     of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in     task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-     executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware     name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline]     task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950     exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8     kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882     [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by     task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc     mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180     copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500     kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687     arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free     mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8     kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401     proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48     fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510     fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585     ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write     fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall     arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline]     el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150     arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416     el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180     arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to     the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Don't generate an interrupt     on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to     recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler     (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling     the end of a successful transaction. In the case of a block transaction, this can result in an out-of-     range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e     https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e     https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e     https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb     https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a     https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset     the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix WRITE_SAME No Data     Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer     that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in     target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because     its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support     it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal     WRITE SAME with no data buffer. (CVE-2022-21546)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: IPoIB, Block PKEY     interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues     when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child     interface uses the parent receive channels. Although the child shares the parent's receive channels, the     number of rx queues is important for the channel_stats array: the parent's rx channel index is used to     access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size     for the counting to work correctly and to prevent out of bound accesses. This patch checks for the     mentioned scenario and returns an error when trying to create the interface. The error is propagated to     the user. (CVE-2022-48883)

  - In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix potential out of bounds     access with invalid rxstatus->rs_keyix The rxstatus->rs_keyix eventually gets passed to test_bit() so we     need to ensure that it is within the bitmap. drivers/net/wireless/ath/ath9k/common.c:46     ath9k_cmn_rx_accept() error: passing untrusted data 'rx_stats->rs_keyix' to 'test_bit()' (CVE-2022-49503)

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

  - In the Linux kernel, the following vulnerability has been resolved: pid: take a reference when     initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct     pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will     increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via     put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never     incremented, can therefore free the init task's struct pid early. As there can be dangling references to     the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted     when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to     struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age     of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in     task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-     executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware     name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline]     task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950     exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8     kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882     [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by     task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc     mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180     copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500     kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687     arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free     mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8     kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401     proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48     fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510     fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585     ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write     fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall     arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline]     el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150     arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416     el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180     arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to     the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Don't generate an interrupt     on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to     recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler     (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling     the end of a successful transaction. In the case of a block transaction, this can result in an out-of-     range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e     https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e     https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e     https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb     https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a     https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset     the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix WRITE_SAME No Data     Buffer crash In newer version of the SBC specs, we have a NDOB bit that indicates there is no data buffer     that gets written out. If this bit is set using commands like sg_write_same --ndob we will crash in     target_core_iblock/file's execute_write_same handlers when we go to access the se_cmd->t_data_sg because     its NULL. This patch adds a check for the NDOB bit in the common WRITE SAME code because we don't support     it. And, it adds a check for zero SG elements in each handler in case the initiator tries to send a normal     WRITE SAME with no data buffer. (CVE-2022-21546)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: IPoIB, Block PKEY     interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues     when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child     interface uses the parent receive channels. Although the child shares the parent's receive channels, the     number of rx queues is important for the channel_stats array: the parent's rx channel index is used to     access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size     for the counting to work correctly and to prevent out of bound accesses. This patch checks for the     mentioned scenario and returns an error when trying to create the interface. The error is propagated to     the user. (CVE-2022-48883)

  - In the Linux kernel, the following vulnerability has been resolved: be2net: Fix buffer overflow in     be_get_module_eeprom be_cmd_read_port_transceiver_data assumes that it is given a buffer that is at least     PAGE_DATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case.
    Fix this by passing the desired offset and length to be_cmd_read_port_transceiver_data so that we only     copy the bytes once. (CVE-2022-49581)

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

  - In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Ensure scpi_info     is not assigned if the probe fails When scpi probe fails, at any point, we need to ensure that the     scpi_info is not set and will remain NULL until the probe succeeds. If it is not taken care, then it could     result use-after-free as the value is exported via get_scpi_ops() and could refer to a memory allocated     via devm_kzalloc() but freed when the probe fails. (CVE-2022-50087)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: Fix global-out-of-     bounds bug in _rtl8812ae_phy_set_txpower_limit() There is a global-out-of-bounds reported by KASAN: BUG:
    KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae] Read of size 1 at addr     ffffffffa0773c43 by task NetworkManager/411 CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D 6.1.0-rc8+     #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), Call Trace: <TASK> ...
    kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]     rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae] rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae] ...
    </TASK> The root cause of the problem is that the comparison order of prate_section in
    _rtl8812ae_phy_set_txpower_limit() is wrong. The _rtl8812ae_eq_n_byte() is used to compare the first n     bytes of the two strings from tail to head, which causes the problem. In the
    _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet this requirement by carefully     designing the comparison order. For example, pregulation and pbandwidth are compared in order of     length from small to large, first is 3 and last is 4. However, the comparison order of prate_section     dose not obey such order requirement, therefore when prate_section is HT, when comparing from tail to     head, it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As mentioned above, the
    _rtl8812ae_eq_n_byte() has the same function as strcmp(), so just strcmp() is enough. Fix it by removing
    _rtl8812ae_eq_n_byte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order     of prate_section, this may cause the value of rate_section to not be from 0 to 5. In addition, commit     21e4b0726dc6 not only moved driver from staging to regular tree, but also added setting txpower limit     function during the driver config phase, so the problem was introduced by this commit. (CVE-2022-50279)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix monitor mode bringup     crash When the interface is brought up in monitor mode, it leads to NULL pointer dereference crash. This     crash happens when the packet type is extracted for a SKB. This extraction which is present in the     received msdu delivery path,is not needed for the monitor ring packets since they are all RAW packets.
    Hence appending the flags with RX_FLAG_ONLY_MONITOR to skip that extraction. Observed calltrace: Unable     to handle kernel NULL pointer dereference at virtual address 0000000000000064 Mem abort info: ESR =     0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC =     0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable:
    4k pages, 48-bit VAs, pgdp=0000000048517000 [0000000000000064] pgd=0000000000000000, p4d=0000000000000000     Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: ath11k_pci ath11k qmi_helpers     CPU: 2 PID: 1781 Comm: napi/-271 Not tainted 6.1.0-rc5-wt-ath-656295-gef907406320c-dirty #6 Hardware name:
    Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C2 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS     BTYPE=--) pc : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k] lr :
    ath11k_hw_qcn9074_rx_desc_get_decap_type+0x5c/0x60 [ath11k] sp : ffff80000ef5bb10 x29: ffff80000ef5bb10     x28: 0000000000000000 x27: ffff000007baafa0 x26: ffff000014a91ed0 x25: 0000000000000000 x24:
    0000000000000000 x23: ffff800002b77378 x22: ffff000014a91ec0 x21: ffff000006c8d600 x20: 0000000000000000     x19: ffff800002b77740 x18: 0000000000000006 x17: 736564203634343a x16: 656e694c20657079 x15:
    0000000000000143 x14: 00000000ffffffea x13: ffff80000ef5b8b8 x12: ffff80000ef5b8c8 x11: ffff80000a591d30     x10: ffff80000a579d40 x9 : c0000000ffffefff x8 : 0000000000000003 x7 : 0000000000017fe8 x6 :
    ffff80000a579ce8 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 3a35ec12ed7f8900     x1 : 0000000000000000 x0 : 0000000000000052 Call trace: ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60     [ath11k] ath11k_dp_rx_deliver_msdu.isra.42+0xa4/0x3d0 [ath11k]     ath11k_dp_rx_mon_deliver.isra.43+0x2f8/0x458 [ath11k] ath11k_dp_rx_process_mon_rings+0x310/0x4c0 [ath11k]     ath11k_dp_service_srng+0x234/0x338 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xb8 [ath11k]
    __napi_poll+0x5c/0x190 napi_threaded_poll+0xf0/0x118 kthread+0xf4/0x110 ret_from_fork+0x10/0x20 Tested-on:
    QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 (CVE-2022-50627)

  - In the Linux kernel, the following vulnerability has been resolved: mm: hugetlb: fix UAF in     hugetlb_handle_userfault The vma_lock and hugetlb_fault_mutex are dropped before handling userfault and     reacquire them again after handle_userfault(), but reacquire the vma_lock could lead to UAF[1,2] due to     the following race, hugetlb_fault hugetlb_no_page /*unlock vma_lock */ hugetlb_handle_userfault     handle_userfault /* unlock mm->mmap_lock*/ vm_mmap_pgoff do_mmap mmap_region munmap_vma_range /* clean old     vma */ /* lock vma_lock again <--- UAF */ /* unlock vma_lock */ Since the vma_lock will unlock immediately     after hugetlb_handle_userfault(), let's drop the unneeded lock and unlock in hugetlb_handle_userfault() to     fix the issue. [1] https://lore.kernel.org/linux-mm/000000000000d5e00a05e834962e@google.com/ [2]     https://lore.kernel.org/linux-mm/20220921014457.1668-1-liuzixian4@huawei.com/ (CVE-2022-50630)

  - In the Linux kernel, the following vulnerability has been resolved: PCI: Fix pci_device_is_present() for     VFs by checking PF pci_device_is_present() previously didn't work for VFs because it reads the Vendor and     Device ID, which are 0xffff for VFs, which looks like they aren't present. Check the PF instead. Wei Gong     reported that if virtio I/O is in progress when the driver is unbound or 0 is written to     /sys/.../sriov_numvfs, the virtio I/O operation hangs, which may result in output like this: task:bash     state:D stack: 0 pid: 1773 ppid: 1241 flags:0x00004002 Call Trace: schedule+0x4f/0xc0     blk_mq_freeze_queue_wait+0x69/0xa0 blk_mq_freeze_queue+0x1b/0x20 blk_cleanup_queue+0x3d/0xd0     virtblk_remove+0x3c/0xb0 [virtio_blk] virtio_dev_remove+0x4b/0x80 ... device_unregister+0x1b/0x60     unregister_virtio_device+0x18/0x30 virtio_pci_remove+0x41/0x80 pci_device_remove+0x3e/0xb0 This happened     because pci_device_is_present(VF) returned false in virtio_pci_remove(), so it called     virtio_break_device(). The broken vq meant that vring_interrupt() skipped the vq.callback() that would     have completed the virtio I/O operation via virtblk_done(). [bhelgaas: commit log, simplify to always use     pci_physfn(), add stable tag] (CVE-2022-50636)

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-992961 advisory.

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

    wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit()

    There is a global-out-of-bounds reported by KASAN:

      BUG: KASAN: global-out-of-bounds in
      _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]       Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411

      CPU: 6 PID: 411 Comm: NetworkManager Tainted: G      D       6.1.0-rc8+ #144 e15588508517267d37       Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),       Call Trace:
       <TASK>        ...
       kasan_report+0xbb/0x1c0
       _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]        rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae]        rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae]        ...
       </TASK>

    The root cause of the problem is that the comparison order of     prate_section in _rtl8812ae_phy_set_txpower_limit() is wrong. The
    _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two     strings from tail to head, which causes the problem. In the
    _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet     this requirement by carefully designing the comparison order.
    For example, pregulation and pbandwidth are compared in order of     length from small to large, first is 3 and last is 4. However, the     comparison order of prate_section dose not obey such order requirement,     therefore when prate_section is HT, when comparing from tail to head,     it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As     mentioned above, the _rtl8812ae_eq_n_byte() has the same function as     strcmp(), so just strcmp() is enough.

    Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely.
    Although it can be fixed by adjusting the comparison order of     prate_section, this may cause the value of rate_section to not be     from 0 to 5. In addition, commit 21e4b0726dc6 not only moved driver     from staging to regular tree, but also added setting txpower limit     function during the driver config phase, so the problem was introduced     by this commit.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-992184 advisory.

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

    wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit()

    There is a global-out-of-bounds reported by KASAN:

      BUG: KASAN: global-out-of-bounds in
      _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]       Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411

      CPU: 6 PID: 411 Comm: NetworkManager Tainted: G      D       6.1.0-rc8+ #144 e15588508517267d37       Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),       Call Trace:
       <TASK>        ...
       kasan_report+0xbb/0x1c0
       _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]        rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae]        rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae]        ...
       </TASK>

    The root cause of the problem is that the comparison order of     prate_section in _rtl8812ae_phy_set_txpower_limit() is wrong. The
    _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two     strings from tail to head, which causes the problem. In the
    _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet     this requirement by carefully designing the comparison order.
    For example, pregulation and pbandwidth are compared in order of     length from small to large, first is 3 and last is 4. However, the     comparison order of prate_section dose not obey such order requirement,     therefore when prate_section is HT, when comparing from tail to head,     it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As     mentioned above, the _rtl8812ae_eq_n_byte() has the same function as     strcmp(), so just strcmp() is enough.

    Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely.
    Although it can be fixed by adjusting the comparison order of     prate_section, this may cause the value of rate_section to not be     from 0 to 5. In addition, commit 21e4b0726dc6 not only moved driver     from staging to regular tree, but also added setting txpower limit     function during the driver config phase, so the problem was introduced     by this commit.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

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

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2025-992349 advisory.

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

    wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit()

    There is a global-out-of-bounds reported by KASAN:

      BUG: KASAN: global-out-of-bounds in
      _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]       Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411

      CPU: 6 PID: 411 Comm: NetworkManager Tainted: G      D       6.1.0-rc8+ #144 e15588508517267d37       Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),       Call Trace:
       <TASK>        ...
       kasan_report+0xbb/0x1c0
       _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]        rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae]        rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae]        ...
       </TASK>

    The root cause of the problem is that the comparison order of     prate_section in _rtl8812ae_phy_set_txpower_limit() is wrong. The
    _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two     strings from tail to head, which causes the problem. In the
    _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet     this requirement by carefully designing the comparison order.
    For example, pregulation and pbandwidth are compared in order of     length from small to large, first is 3 and last is 4. However, the     comparison order of prate_section dose not obey such order requirement,     therefore when prate_section is HT, when comparing from tail to head,     it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As     mentioned above, the _rtl8812ae_eq_n_byte() has the same function as     strcmp(), so just strcmp() is enough.

    Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely.
    Although it can be fixed by adjusting the comparison order of     prate_section, this may cause the value of rate_section to not be     from 0 to 5. In addition, commit 21e4b0726dc6 not only moved driver     from staging to regular tree, but also added setting txpower limit     function during the driver config phase, so the problem was introduced     by this commit.

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

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

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:03628-1 advisory.

    The SUSE Linux Enterprise 15 SP4 kernel was updated to receive various security bugfixes.


    The following security bugs were fixed:

    - CVE-2022-49138: Bluetooth: hci_event: Fix checking conn for le_conn_complete_evt (bsc#1238160).
    - CVE-2022-49980: USB: gadget: fix use-after-free read in usb_udc_uevent() (bsc#1245110).
    - CVE-2022-50233: Bluetooth: eir: Fix using strlen with hdev->{dev_name,short_name} (bsc#1246968).
    - CVE-2022-50252: igb: Do not free q_vector unless new one was allocated (bsc#1249846).
    - CVE-2022-50409: net: If sock is dead do not access sock's sk_wq in sk_stream_wait_memory (bsc#1250392).
    - CVE-2023-53178: mm: fix zswap writeback race condition (bsc#1249827).
    - CVE-2023-53321: wifi: mac80211_hwsim: drop short frames (bsc#1250313).
    - CVE-2023-53438: x86/MCE: Always save CS register on AMD Zen IF Poison errors (bsc#1250180).
    - CVE-2025-23155: net: stmmac: Fix accessing freed irq affinity_hint (bsc#1242573).
    - CVE-2025-37738: ext4: ignore xattrs past end (bsc#1242846).
    - CVE-2025-37885: KVM: x86: Reset IRTE to host control if *new* route isn't postable (bsc#1242960).
    - CVE-2025-37958: mm/huge_memory: fix dereferencing invalid pmd migration entry (bsc#1243539).
    - CVE-2025-38014: dmaengine: idxd: Refactor remove call with idxd_cleanup() helper (bsc#1244732).
    - CVE-2025-38084: mm/hugetlb: unshare page tables during VMA split, not before (bsc#1245498).
    - CVE-2025-38085: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race (bsc#1245499).
    - CVE-2025-38111: net/mdiobus: Fix potential out-of-bounds read/write access (bsc#1245666).
    - CVE-2025-38184: tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer (bsc#1245956).
    - CVE-2025-38380: i2c/designware: Fix an initialization issue (bsc#1247028).
    - CVE-2025-38470: net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime     (bsc#1247288).
    - CVE-2025-38476: rpl: Fix use-after-free in rpl_do_srh_inline() (bsc#1247317).
    - CVE-2025-38488: smb: client: fix use-after-free in crypt_message when using async crypto (bsc#1247239).
    - CVE-2025-38553: net/sched: Restrict conditions for adding duplicating netems to qdisc tree     (bsc#1248255).
    - CVE-2025-38572: ipv6: reject malicious packets in ipv6_gso_segment() (bsc#1248399).
    - CVE-2025-38659: gfs2: No more self recovery (bsc#1248639).
    - CVE-2025-38664: ice: Fix a null pointer dereference in ice_copy_and_init_pkg() (bsc#1248628).
    - CVE-2025-38678: netfilter: nf_tables: reject duplicate device on updates (bsc#1249126).
    - CVE-2025-38685: fbdev: Fix vmalloc out-of-bounds write in fast_imageblit (bsc#1249220).
    - CVE-2025-38706: ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime() (bsc#1249195).
    - CVE-2025-38713: hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc() (bsc#1249200).
    - CVE-2025-38734: net/smc: fix UAF on smcsk after smc_listen_out() (bsc#1249324).
    - CVE-2025-39691: fs/buffer: fix use-after-free when call bh_read() helper (bsc#1249374).
    - CVE-2025-39703: net, hsr: reject HSR frame if skb can't hold tag (bsc#1249315).
    - CVE-2025-39726: s390/ism: fix concurrency management in ism_cmd() (bsc#1249266).
    - CVE-2025-39746: wifi: ath10k: shutdown driver when hardware is unreliable (bsc#1249516).
    - CVE-2025-39751: ALSA: hda/ca0132: Fix buffer overflow in add_tuning_control (bsc#1249538).
    - CVE-2025-39790: bus: mhi: host: Detect events pointing to unexpected TREs (bsc#1249548).
    - CVE-2025-39797: xfrm: xfrm_alloc_spi shouldn't use 0 as SPI (bsc#1249608).
    - CVE-2025-39823: KVM: x86: use array_index_nospec with indices that come from guest (bsc#1250002).
    - CVE-2025-39824: HID: asus: fix UAF via HID_CLAIMED_INPUT validation (bsc#1250007).
    - CVE-2025-39860: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() (bsc#1250247).
    - CVE-2025-39869: dmaengine: ti: edma: Fix memory allocation size for queue_priority_map (bsc#1250406).


Tenable has extracted the preceding description block directly from the SUSE 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 remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2025:03615-1 advisory.

    The SUSE Linux Enterprise 15 SP5 kernel was updated to receive various security bugfixes.


    The following security bugs were fixed:

    - CVE-2022-49138: Bluetooth: hci_event: Fix checking conn for le_conn_complete_evt (bsc#1238160).
    - CVE-2022-50233: Bluetooth: eir: Fix using strlen with hdev->{dev_name,short_name} (bsc#1246968).
    - CVE-2022-50252: igb: Do not free q_vector unless new one was allocated (bsc#1249846).
    - CVE-2022-50409: net: If sock is dead do not access sock's sk_wq in sk_stream_wait_memory (bsc#1250392).
    - CVE-2023-53178: mm: fix zswap writeback race condition (bsc#1249827).
    - CVE-2023-53257: wifi: mac80211: check S1G action frame size (bsc#1249869).
    - CVE-2023-53321: wifi: mac80211_hwsim: drop short frames (bsc#1250313).
    - CVE-2023-53438: x86/MCE: Always save CS register on AMD Zen IF Poison errors (bsc#1250180).
    - CVE-2025-37738: ext4: ignore xattrs past end (bsc#1242846).
    - CVE-2025-37958: mm/huge_memory: fix dereferencing invalid pmd migration entry (bsc#1243539).
    - CVE-2025-38014: dmaengine: idxd: Refactor remove call with idxd_cleanup() helper (bsc#1244732).
    - CVE-2025-38111: net/mdiobus: Fix potential out-of-bounds read/write access (bsc#1245666).
    - CVE-2025-38380: i2c/designware: Fix an initialization issue (bsc#1247028).
    - CVE-2025-38488: smb: client: fix use-after-free in crypt_message when using async crypto (bsc#1247239).
    - CVE-2025-38553: net/sched: Restrict conditions for adding duplicating netems to qdisc tree     (bsc#1248255).
    - CVE-2025-38572: ipv6: reject malicious packets in ipv6_gso_segment() (bsc#1248399).
    - CVE-2025-38659: gfs2: No more self recovery (bsc#1248639).
    - CVE-2025-38664: ice: Fix a null pointer dereference in ice_copy_and_init_pkg() (bsc#1248628).
    - CVE-2025-38678: netfilter: nf_tables: reject duplicate device on updates (bsc#1249126).
    - CVE-2025-38685: fbdev: Fix vmalloc out-of-bounds write in fast_imageblit (bsc#1249220).
    - CVE-2025-38706: ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime() (bsc#1249195).
    - CVE-2025-38713: hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc() (bsc#1249200).
    - CVE-2025-38734: net/smc: fix UAF on smcsk after smc_listen_out() (bsc#1249324).
    - CVE-2025-39691: fs/buffer: fix use-after-free when call bh_read() helper (bsc#1249374).
    - CVE-2025-39703: net, hsr: reject HSR frame if skb can't hold tag (bsc#1249315).
    - CVE-2025-39726: s390/ism: fix concurrency management in ism_cmd() (bsc#1249266).
    - CVE-2025-39746: wifi: ath10k: shutdown driver when hardware is unreliable (bsc#1249516).
    - CVE-2025-39751: ALSA: hda/ca0132: Fix buffer overflow in add_tuning_control (bsc#1249538).
    - CVE-2025-39790: bus: mhi: host: Detect events pointing to unexpected TREs (bsc#1249548).
    - CVE-2025-39823: KVM: x86: use array_index_nospec with indices that come from guest (bsc#1250002).
    - CVE-2025-39824: HID: asus: fix UAF via HID_CLAIMED_INPUT validation (bsc#1250007).
    - CVE-2025-39860: Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen() (bsc#1250247).
    - CVE-2025-39869: dmaengine: ti: edma: Fix memory allocation size for queue_priority_map (bsc#1250406).


Tenable has extracted the preceding description block directly from the SUSE security advisory.

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

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit() There is a global-out-     of-bounds reported by KASAN: BUG: KASAN: global-out-of-bounds in _rtl8812ae_eq_n_byte.part.0+0x3d/0x84     [rtl8821ae] Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411 CPU: 6 PID: 411 Comm:
    NetworkManager Tainted: G D 6.1.0-rc8+ #144 e15588508517267d37 Hardware name: QEMU Standard PC (Q35 +     ICH9, 2009), Call Trace: <TASK> ... kasan_report+0xbb/0x1c0 _rtl8812ae_eq_n_byte.part.0+0x3d/0x84     [rtl8821ae] rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae] rtl8821ae_hw_init+0x1f5e/0x79b0     [rtl8821ae] ... </TASK> The root cause of the problem is that the comparison order of prate_section in
    _rtl8812ae_phy_set_txpower_limit() is wrong. The _rtl8812ae_eq_n_byte() is used to compare the first n     bytes of the two strings from tail to head, which causes the problem. In the
    _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet this requirement by carefully     designing the comparison order. For example, pregulation and pbandwidth are compared in order of     length from small to large, first is 3 and last is 4. However, the comparison order of prate_section     dose not obey such order requirement, therefore when prate_section is HT, when comparing from tail to     head, it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As mentioned above, the
    _rtl8812ae_eq_n_byte() has the same function as strcmp(), so just strcmp() is enough. Fix it by removing
    _rtl8812ae_eq_n_byte() and use strcmp() barely. Although it can be fixed by adjusting the comparison order     of prate_section, this may cause the value of rate_section to not be from 0 to 5. In addition, commit     21e4b0726dc6 not only moved driver from staging to regular tree, but also added setting txpower limit     function during the driver config phase, so the problem was introduced by this commit. (CVE-2022-50279)

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

An update of the linux package has been released.

ID	Name	Product	Family	Type	Severity
361173	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1771078945)	Nessus	CentOS Local Security Checks	Local	high
360928	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1771077729)	Nessus	CentOS Local Security Checks	Local	high
360579	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1767864313)	Nessus	Alma Linux Local Security Checks	Local	high
281372	Unity Linux 20.1060a / 20.1070a Security Update: kernel (UTSA-2025-992961)	Nessus	Unity Linux Local Security Checks	Local	high
280447	Unity Linux 20.1070e Security Update: kernel (UTSA-2025-992184)	Nessus	Unity Linux Local Security Checks	Local	high
280223	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2025-992349)	Nessus	Unity Linux Local Security Checks	Local	high
270857	SUSE SLES15 Security Update : kernel (SUSE-SU-2025:03628-1)	Nessus	SuSE Local Security Checks	Local	high
270837	SUSE SLES15 : Security update for the Linux Kernel (SUSE-SU-2025:03615-1)	Nessus	SuSE Local Security Checks	Local	high
264917	Linux Distros Unpatched Vulnerability : CVE-2022-50279	Nessus	Misc.	Local	high
151965	Photon OS 4.0: Linux PHSA-2021-4.0-0065	Nessus	PhotonOS Local Security Checks	Local	high

Detections

Analytics

CVE-2022-50279

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high