In the Linux kernel, the following vulnerability has been resolved: ice: set tx_tstamps when creating new Tx rings via ethtool When the user changes the number of queues via ethtool, the driver allocates new rings. This allocation did not initialize tx_tstamps. This results in the tx_tstamps field being zero (due to kcalloc allocation), and would result in a NULL pointer dereference when attempting a transmit timestamp on the new ring.

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

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix UBSAN shift-out-of-     bounds warning If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up doing a shift operation     where the number of bits shifted equals number of bits in the operand. This behaviour is undefined. Set     num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the count is >= number of bits in the operand.
    Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472 (CVE-2021-4460)

  - An out-of-bounds(OOB) memory access vulnerability was found in vmwgfx driver in     drivers/gpu/vmxgfx/vmxgfx_kms.c in GPU component in the Linux kernel with device file '/dev/dri/renderD128     (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing     a denial of service(DoS). (CVE-2022-36280)

  - In the Linux kernel, the following vulnerability has been resolved: ata: ahci: Match EM_MAX_SLOTS with     SATA_PMP_MAX_PORTS UBSAN complains about array-index-out-of-bounds: [ 1.980703] kernel: UBSAN: array-     index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41 [ 1.980709] kernel:
    index 15 is out of range for type 'ahci_em_priv [8]' [ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8     Not tainted 5.15.0-25-generic #25-Ubuntu [ 1.980716] kernel: Hardware name: System manufacturer System     Product Name/P5Q3, BIOS 1102 06/11/2010 [ 1.980718] kernel: Call Trace: [ 1.980721] kernel: <TASK> [     1.980723] kernel: show_stack+0x52/0x58 [ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f [ 1.980734] kernel:
    dump_stack+0x10/0x12 [ 1.980736] kernel: ubsan_epilogue+0x9/0x45 [ 1.980739] kernel:
    __ubsan_handle_out_of_bounds.cold+0x44/0x49 [ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci] [     1.980748] kernel: ata_qc_issue+0x135/0x240 [ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580 [     1.980754] kernel: ? vprintk_default+0x1d/0x20 [ 1.980759] kernel: ata_exec_internal+0x67/0xa0 [ 1.980762]     kernel: sata_pmp_read+0x8d/0xc0 [ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90 [ 1.980768] kernel:
    sata_pmp_attach+0x8b/0x310 [ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0 [ 1.980775]     kernel: ata_eh_recover+0x6b6/0xb30 [ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci] [     1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci] [ 1.980787] kernel: ?     ahci_do_softreset+0x290/0x290 [libahci] [ 1.980792] kernel: ?     trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0 [ 1.980795] kernel:
    sata_pmp_eh_recover.isra.0+0x214/0x560 [ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40 [ 1.980802]     kernel: ahci_error_handler+0x43/0x80 [libahci] [ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600     [ 1.980810] kernel: ata_scsi_error+0x9c/0xd0 [ 1.980813] kernel: scsi_error_handler+0xa1/0x180 [ 1.980817]     kernel: ? scsi_unjam_host+0x1c0/0x1c0 [ 1.980820] kernel: kthread+0x12a/0x150 [ 1.980823] kernel: ?     set_kthread_struct+0x50/0x50 [ 1.980826] kernel: ret_from_fork+0x22/0x30 [ 1.980831] kernel: </TASK> This     happens because sata_pmp_init_links() initialize link->pmp up to SATA_PMP_MAX_PORTS while em_priv is     declared as 8 elements array. I can't find the maximum Enclosure Management ports specified in AHCI spec     v1.3.1, but 12.2.1 LED message type states that Port Multiplier Information can utilize 4 bits, which     implies it can support up to 16 ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve the issue.
    BugLink: https://bugs.launchpad.net/bugs/1970074 (CVE-2022-50315)

  - In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix error code path in     acpi_ds_call_control_method() A use-after-free in acpi_ps_parse_aml() after a failing invocaion of     acpi_ds_call_control_method() is reported by KASAN [1] and code inspection reveals that next_walk_state     pushed to the thread by acpi_ds_create_walk_state() is freed on errors, but it is not popped from the     thread beforehand. Thus acpi_ds_get_current_walk_state() called by acpi_ps_parse_aml() subsequently     returns it as the new walk state which is incorrect. To address this, make acpi_ds_call_control_method()     call acpi_ds_pop_walk_state() to pop next_walk_state from the thread before returning an error.
    (CVE-2022-50411)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sysfs: Fix attempting     to call device_add multiple times device_add shall not be called multiple times as stated in its     documentation: 'Do not call this routine or device_register() more than once for any device structure'     Syzkaller reports a bug as follows [1]: ------------[ cut here ]------------ kernel BUG at     lib/list_debug.c:33! invalid opcode: 0000 [#1] PREEMPT SMP KASAN [...] Call Trace: <TASK> __list_add     include/linux/list.h:69 [inline] list_add_tail include/linux/list.h:102 [inline] kobj_kset_join     lib/kobject.c:164 [inline] kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214 kobject_add_varg     lib/kobject.c:358 [inline] kobject_add+0x150/0x1c0 lib/kobject.c:410 device_add+0x368/0x1e90     drivers/base/core.c:3452 hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53     hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799 hci_le_meta_evt+0x2b8/0x510     net/bluetooth/hci_event.c:7110 hci_event_func net/bluetooth/hci_event.c:7440 [inline]     hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495 hci_rx_work+0xae7/0x1230     net/bluetooth/hci_core.c:4007 process_one_work+0x991/0x1610 kernel/workqueue.c:2289     worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> (CVE-2022-50419)

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

  - In the Linux kernel, the following vulnerability has been resolved: ice: set tx_tstamps when creating new     Tx rings via ethtool When the user changes the number of queues via ethtool, the driver allocates new     rings. This allocation did not initialize tx_tstamps. This results in the tx_tstamps field being zero (due     to kcalloc allocation), and would result in a NULL pointer dereference when attempting a transmit     timestamp on the new ring. (CVE-2022-50710)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: Fix use-after-free in     ath9k_hif_usb_disconnect() This patch fixes a use-after-free in ath9k that occurs in     ath9k_hif_usb_disconnect() when ath9k_destroy_wmi() is trying to access 'drv_priv' that has already been     freed by ieee80211_free_hw(), called by ath9k_htc_hw_deinit(). The patch moves ath9k_destroy_wmi() before     ieee80211_free_hw(). Note that urbs from the driver should be killed before freeing 'wmi' with     ath9k_destroy_wmi() as their callbacks will access 'wmi'. Found by a modified version of syzkaller.
    ================================================================== BUG: KASAN: use-after-free in     ath9k_destroy_wmi+0x38/0x40 Read of size 8 at addr ffff8881069132a0 by task kworker/0:1/7 CPU: 0 PID: 7     Comm: kworker/0:1 Tainted: G O 5.14.0+ #131 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS     rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace:
    dump_stack_lvl+0x8e/0xd1 print_address_description.constprop.0.cold+0x93/0x334 ?     ath9k_destroy_wmi+0x38/0x40 ? ath9k_destroy_wmi+0x38/0x40 kasan_report.cold+0x83/0xdf ?     ath9k_destroy_wmi+0x38/0x40 ath9k_destroy_wmi+0x38/0x40 ath9k_hif_usb_disconnect+0x329/0x3f0 ?     ath9k_hif_usb_suspend+0x120/0x120 ? usb_disable_interface+0xfc/0x180 usb_unbind_interface+0x19b/0x7e0 ?     usb_autoresume_device+0x50/0x50 device_release_driver_internal+0x44d/0x520 bus_remove_device+0x2e5/0x5a0     device_del+0x5b2/0xe30 ? __device_link_del+0x370/0x370 ? usb_remove_ep_devs+0x43/0x80 ?     remove_intf_ep_devs+0x112/0x1a0 usb_disable_device+0x1e3/0x5a0 usb_disconnect+0x267/0x870     hub_event+0x168d/0x3950 ? rcu_read_lock_sched_held+0xa1/0xd0 ? hub_port_debounce+0x2e0/0x2e0 ?     check_irq_usage+0x860/0xf20 ? drain_workqueue+0x281/0x360 ? lock_release+0x640/0x640 ?     rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ?     lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x92b/0x1460 ? pwq_dec_nr_in_flight+0x330/0x330 ?     rwlock_bug.part.0+0x90/0x90 worker_thread+0x95/0xe00 ? __kthread_parkme+0x115/0x1e0 ?     process_one_work+0x1460/0x1460 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120     ret_from_fork+0x1f/0x30 The buggy address belongs to the page: page:ffffea00041a44c0 refcount:0 mapcount:0     mapping:0000000000000000 index:0x0 pfn:0x106913 flags: 0x200000000000000(node=0|zone=2) raw:
    0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000     00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the     page as freed page last allocated via order 3, migratetype Unmovable, gfp_mask     0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), pid 7, ts 38347963444, free_ts 41399957635     prep_new_page+0x1aa/0x240 get_page_from_freelist+0x159a/0x27c0 __alloc_pages+0x2da/0x6a0     alloc_pages+0xec/0x1e0 kmalloc_order+0x39/0xf0 kmalloc_order_trace+0x19/0x120 __kmalloc+0x308/0x390     wiphy_new_nm+0x6f5/0x1dd0 ieee80211_alloc_hw_nm+0x36d/0x2230 ath9k_htc_probe_device+0x9d/0x1e10     ath9k_htc_hw_init+0x34/0x50 ath9k_hif_usb_firmware_cb+0x25f/0x4e0 request_firmware_work_func+0x131/0x240     process_one_work+0x92b/0x1460 worker_thread+0x95/0xe00 kthread+0x3a1/0x480 page last free stack trace:
    free_pcp_prepare+0x3d3/0x7f0 free_unref_page+0x1e/0x3d0 device_release+0xa4/0x240 kobject_put+0x186/0x4c0     put_device+0x20/0x30 ath9k_htc_disconnect_device+0x1cf/0x2c0 ath9k_htc_hw_deinit+0x26/0x30     ath9k_hif_usb_disconnect+0x2d9/0x3f0 usb_unbind_interface+0x19b/0x7e0     device_release_driver_internal+0x44d/0x520 bus_remove_device+0x2e5/0x5a0 device_del+0x5b2/0xe30     usb_disable_device+0x1e3/0x5a0 usb_disconnect+0x267/0x870 hub_event+0x168d/0x3950     process_one_work+0x92b/0x1460 Memory state around the buggy address: ffff888106913180: ff ff ff ff ff ff     ff ff ff ff ff ff ff ff ff ff ffff888106913200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888
    ---truncated--- (CVE-2022-50881)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: allow exp not to be removed     in nf_ct_find_expectation Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp     from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct     will not be confirmed, like in OVS and TC conntrack in the following patches. This patch allows exp not to     be removed by setting IPS_CONFIRMED in the status of the tmpl. (CVE-2023-52927)

  - In the Linux kernel, the following vulnerability has been resolved: sched/fair: Don't balance task to its     current running CPU We've run into the case that the balancer tries to balance a migration disabled task     and trigger the warning in set_task_cpu() like below: ------------[ cut here ]------------ WARNING: CPU: 7     PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240 Modules linked in: hclgevf xt_CHECKSUM     ipt_REJECT nf_reject_ipv4 <...snip> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1     Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021 pstate: 604000c9     (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : set_task_cpu+0x188/0x240 lr : load_balance+0x5d0/0xc60     sp : ffff80000803bc70 x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040 x26:
    ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 x23: ffff80000803be84 x22: 000000000000000c     x21: ffffb093e79e2a78 x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000 x17:
    0000000000001fad x16: 0000000000000030 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000     x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530 x8 :
    00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e x5 : 00000000ffffffe1 x4 : 0000000000000001     x3 : 0000000000000b2a x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001 Call trace:
    set_task_cpu+0x188/0x240 load_balance+0x5d0/0xc60 rebalance_domains+0x26c/0x380
    _nohz_idle_balance.isra.0+0x1e0/0x370 run_rebalance_domains+0x6c/0x80 __do_softirq+0x128/0x3d8
    ____do_softirq+0x18/0x24 call_on_irq_stack+0x2c/0x38 do_softirq_own_stack+0x24/0x3c
    __irq_exit_rcu+0xcc/0xf4 irq_exit_rcu+0x18/0x24 el1_interrupt+0x4c/0xe4 el1h_64_irq_handler+0x18/0x2c     el1h_64_irq+0x74/0x78 arch_cpu_idle+0x18/0x4c default_idle_call+0x58/0x194 do_idle+0x244/0x2b0     cpu_startup_entry+0x30/0x3c secondary_start_kernel+0x14c/0x190 __secondary_switched+0xb0/0xb4 ---[ end     trace 0000000000000000 ]--- Further investigation shows that the warning is superfluous, the migration     disabled task is just going to be migrated to its current running CPU. This is because that on load     balance if the dst_cpu is not allowed by the task, we'll re-select a new_dst_cpu as a candidate. If no     task can be balanced to dst_cpu we'll try to balance the task to the new_dst_cpu instead. In this case     when the migration disabled task is not on CPU it only allows to run on its current CPU, load balance will     select its current CPU as new_dst_cpu and later triggers the warning above. The new_dst_cpu is chosen from     the env->dst_grpmask. Currently it contains CPUs in sched_group_span() and if we have overlapped groups     it's possible to run into this case. This patch makes env->dst_grpmask of group_balance_mask() which     exclude any CPUs from the busiest group and solve the issue. For balancing in a domain with no overlapped     groups the behaviour keeps same as before. (CVE-2023-53215)

  - In the Linux kernel, the following vulnerability has been resolved: ubi: ensure that VID header offset +     VID header size <= alloc, size Ensure that the VID header offset + VID header size does not exceed the     allocated area to avoid slab OOB. BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]     BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline] BUG: KASAN: slab-out-of-bounds     in crc32_le_base+0x58c/0x626 lib/crc32.c:197 Read of size 4 at addr ffff88802bb36f00 by task syz-     executor136/1555 CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W 6.0.0-1868 #1 Hardware name: Red Hat     KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29 04/01/2014 Call Trace: <TASK> __dump_stack     lib/dump_stack.c:88 [inline] dump_stack_lvl+0x85/0xad lib/dump_stack.c:106 print_address_description     mm/kasan/report.c:317 [inline] print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433     kasan_report+0xa7/0x11b mm/kasan/report.c:495 crc32_body lib/crc32.c:111 [inline] crc32_le_generic     lib/crc32.c:179 [inline] crc32_le_base+0x58c/0x626 lib/crc32.c:197 ubi_io_write_vid_hdr+0x1b7/0x472     drivers/mtd/ubi/io.c:1067 create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317 create_empty_lvol     drivers/mtd/ubi/vtbl.c:500 [inline] ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812     ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e     drivers/mtd/ubi/build.c:965 ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl     fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline]
    __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline]     do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0x0 RIP:
    0033:0x7f96d5cf753d Code: RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX:
    ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d RDX: 0000000020000080 RSI: 0000000040186f40     RDI: 0000000000000003 RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000 R10:
    0000000000000000 R11: 0000000000000246 R12: 0000000000400be0 R13: 00007fffd72207e0 R14: 0000000000000000     R15: 0000000000000000 </TASK> Allocated by task 1555: kasan_save_stack+0x20/0x3d mm/kasan/common.c:38     kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline]
    ____kasan_kmalloc mm/kasan/common.c:516 [inline] __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525     kasan_kmalloc include/linux/kasan.h:234 [inline] __kmalloc+0x138/0x257 mm/slub.c:4429 kmalloc     include/linux/slab.h:605 [inline] ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline]     create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295 create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]     ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812 ubi_attach+0xf34/0x1603     drivers/mtd/ubi/attach.c:1601 ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965     ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl     fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856     do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x63/0x0 The buggy address belongs to the object at ffff88802bb36e00 which     belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes to the right of 256-byte     region [ffff88802bb36e00, ffff88802bb36f00) The buggy address belongs to the physical page:
    page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2bb36     head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0 flags:
    0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0010200 ffffea000066c300     dead000000000003 ffff888100042b40 raw: 0000000000000000 00000000001 ---truncated--- (CVE-2023-53265)

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

  - An issue was discovered in slc_bump in drivers/net/can/slcan.c in the Linux kernel 3.16 through 5.6.2. It     allows attackers to read uninitialized can_frame data, potentially containing sensitive information from     kernel stack memory, if the configuration lacks CONFIG_INIT_STACK_ALL, aka CID-b9258a2cece4.
    (CVE-2020-11494)

  - An out-of-bounds(OOB) memory access vulnerability was found in vmwgfx driver in     drivers/gpu/vmxgfx/vmxgfx_kms.c in GPU component in the Linux kernel with device file '/dev/dri/renderD128     (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing     a denial of service(DoS). (CVE-2022-36280)

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

  - In the Linux kernel, the following vulnerability has been resolved: ata: libata-transport: fix double     ata_host_put() in ata_tport_add() In the error path in ata_tport_add(), when calling put_device(),     ata_tport_release() is called, it will put the refcount of 'ap->host'. And then ata_host_put() is called     again, the refcount is decreased to 0, ata_host_release() is called, all ports are freed and set to null.
    When unbinding the device after failure, ata_host_stop() is called to release the resources, it leads a     null-ptr-deref(), because all the ports all freed and null. Unable to handle kernel NULL pointer     dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G     E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc :
    ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Call trace: ata_host_stop+0x3c/0x84 [libata]     release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70     really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120
    __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240     driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci] Fix     this by removing redundant ata_host_put() in the error path. (CVE-2022-49826)

  - In the Linux kernel, the following vulnerability has been resolved: capabilities: fix undefined behavior     in bit shift for CAP_TO_MASK Shifting signed 32-bit value by 31 bits is undefined, so changing significant     bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in     security/commoncap.c:1252:2 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace:
    <TASK> dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e
    __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c cap_task_prctl+0x561/0x6f0 security_task_prctl+0x5a/0xb0
    __x64_sys_prctl+0x61/0x8f0 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK>     (CVE-2022-49870)

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-2026:0317-1 advisory.

    The SUSE Linux Enterprise 15 SP5 kernel was updated to fix various security issues

    The following security issues were fixed:

    - CVE-2022-50630: mm: hugetlb: fix UAF in hugetlb_handle_userfault (bsc#1254785).
    - CVE-2022-50700: wifi: ath10k: Delay the unmapping of the buffer (bsc#1255576).
    - CVE-2023-53254: cacheinfo: Fix shared_cpu_map to handle shared caches at different levels (bsc#1249871).
    - CVE-2023-53781: smc: Fix use-after-free in tcp_write_timer_handler() (bsc#1254751).
    - CVE-2024-56590: Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packet (bsc#1235038).
    - CVE-2025-39977: futex: Prevent use-after-free during requeue-PI (bsc#1252046).
    - CVE-2025-40019: crypto: essiv - Check ssize for decryption and in-place encryption (bsc#1252678).
    - CVE-2025-40139: smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set() (bsc#1253409).
    - CVE-2025-40215: kABI: xfrm: delete x->tunnel as we delete x (bsc#1254959).
    - CVE-2025-40220: fuse: fix livelock in synchronous file put from fuseblk workers (bsc#1254520).
    - CVE-2025-40233: ocfs2: clear extent cache after moving/defragmenting extents (bsc#1254813).
    - CVE-2025-40258: mptcp: fix race condition in mptcp_schedule_work() (bsc#1254843).
    - CVE-2025-40277: drm/vmwgfx: Validate command header size against (bsc#1254894).
    - CVE-2025-40280: tipc: Fix use-after-free in tipc_mon_reinit_self() (bsc#1254847).
    - CVE-2025-40331: sctp: Prevent TOCTOU out-of-bounds write (bsc#1254615).
    - CVE-2025-68732: gpu: host1x: Fix race in syncpt alloc/free (bsc#1255688).

    The following non security issues were fixed:

    - ACPI/IORT: Fix memory leak in iort_rmr_alloc_sids() (git-fixes).
    - ACPI: PRM: Remove unnecessary strict handler address checks (git-fixes).
    - ACPI: property: Do not pass NULL handles to acpi_attach_data() (git-fixes).
    - ACPI: property: Fix buffer properties extraction for subnodes (git-fixes).
    - KVM: SVM: Fix TSC_AUX virtualization setup (git-fixes).
    - RDMA/cm: Rate limit destroy CM ID timeout error message (git-fixes).
    - RDMA/counter: Check CAP_NET_RAW check in user namespace for RDMA counters (git-fixes).
    - RDMA/hns: Fix the modification of max_send_sge (git-fixes).
    - RDMA/mlx5: Check CAP_NET_RAW in user namespace for anchor create (git-fixes).
    - RDMA/mlx5: Check CAP_NET_RAW in user namespace for devx create (git-fixes).
    - RDMA/mlx5: Check CAP_NET_RAW in user namespace for flow create (git-fixes).
    - RDMA/mlx5: Fix compilation warning when USER_ACCESS isn't set (git-fixes).
    - RDMA/nldev: Check CAP_NET_RAW in user namespace for QP modify (git-fixes).
    - RDMA/uverbs: Add empty rdma_uattrs_has_raw_cap() declaration (git-fixes).
    - RDMA/uverbs: Check CAP_NET_RAW in user namespace for QP create (git-fixes).
    - RDMA/uverbs: Check CAP_NET_RAW in user namespace for RAW QP create (git-fixes).
    - RDMA/uverbs: Check CAP_NET_RAW in user namespace for flow create (git-fixes).
    - arch/idle: Change arch_cpu_idle() behavior: always exit with IRQs disabled (git-fixes).
    - cpuidle/poll: Ensure IRQs stay disabled after cpuidle_state::enter() calls (git-fixes).
    - cpuidle: Move IRQ state validation (git-fixes).
    - cpuidle: haltpoll: Do not enable interrupts when entering idle (git-fixes).
    - dm: free table mempools if not used in __bind (git-fixes).
    - padata: Honor the caller's alignment in case of chunk_size 0 (bsc#1237563).
    - platform/x86/intel-uncore-freq: Fail module load when plat_info is NULL (git-fixes).
    - x86/bugs: Fix RSB clearing in indirect_branch_prediction_barrier() (git-fixes).
    - x86/bugs: Use SBPB in write_ibpb() if applicable (git-fixes).
    - x86/paravirt: Move halt paravirt calls under CONFIG_PARAVIRT (git-fixes).
    - x86/tdx: Drop flags from __tdx_hypercall() (git-fixes).
    - x86/tdx: Dynamically disable SEPT violations from causing #VEs (git-fixes).
    - x86/tdx: Emit warning if IRQs are enabled during HLT #VE handling (git-fixes).
    - x86/tdx: Extend TDX_MODULE_CALL to support more TDCALL/SEAMCALL leafs (git-fixes).
    - x86/tdx: Fix __noreturn build warning around __tdx_hypercall_failed() (git-fixes).
    - x86/tdx: Fix arch_safe_halt() execution for TDX VMs (git-fixes).
    - x86/tdx: Introduce wrappers to read and write TD metadata (git-fixes).
    - x86/tdx: Make TDX_HYPERCALL asm similar to TDX_MODULE_CALL (git-fixes).
    - x86/tdx: Make macros of TDCALLs consistent with the spec (git-fixes).
    - x86/tdx: Pass TDCALL/SEAMCALL input/output registers via a structure (git-fixes).
    - x86/tdx: Reimplement __tdx_hypercall() using TDX_MODULE_CALL asm (git-fixes).
    - x86/tdx: Remove 'struct tdx_hypercall_args' (git-fixes).
    - x86/tdx: Remove TDX_HCALL_ISSUE_STI (git-fixes).
    - x86/tdx: Rename __tdx_module_call() to __tdcall() (git-fixes).
    - x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup() (git-fixes).
    - x86/tdx: Retry partially-completed page conversion hypercalls (git-fixes).
    - x86/tdx: Skip saving output regs when SEAMCALL fails with VMFailInvalid (git-fixes).
    - x86/tdx: Zero out the missing RSI in TDX_HYPERCALL macro (git-fixes).
    - x86/virt/tdx: Make TDX_MODULE_CALL handle SEAMCALL #UD and #GP (git-fixes).
    - x86/virt/tdx: Wire up basic SEAMCALL functions (git-fixes).
    - xfs: fix sparse inode limits on runt AG (bsc#1254392).

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.

  - ice: set tx_tstamps when creating new Tx rings via ethtool When the user changes the number of queues via     ethtool, the driver allocates new rings. This allocation did not initialize tx_tstamps. This results in     the tx_tstamps field being zero (due to kcalloc allocation), and would result in a NULL pointer     dereference when attempting a transmit timestamp on the new ring. (CVE-2022-50710)

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

ID	Name	Product	Family	Type	Severity
359997	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1768774361)	Nessus	CentOS Local Security Checks	Local	high
359586	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1768663754)	Nessus	Alma Linux Local Security Checks	Local	high
353189	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1768775579)	Nessus	CentOS Local Security Checks	Local	high
297191	SUSE SLES15 : Security update for the Linux Kernel (SUSE-SU-2026:0317-1)	Nessus	SuSE Local Security Checks	Local	high
279841	Linux Distros Unpatched Vulnerability : CVE-2022-50710	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2022-50710

medium

Tenable Plugins

high

high

high

high

medium