In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe called to release the compute pasid before KFD process destroy worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10

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

  - In the Linux kernel, the following vulnerability has been resolved: kyber: fix out of bounds access when     preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to
    ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the     corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls     to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx.
    This works accidentally most of the time, but it can cause us to read garbage if the second ctx came     from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This     manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-     bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int     [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40
    __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480     do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100     submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0     btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440
    __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0     extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0     writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660     wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240     ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge()     instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch.
    (CVE-2021-46984)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute     pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set     to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe     called to release the compute pasid before KFD process destroy worker to release the same pasid and set     vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper     amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm     pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference     taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for     id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP:
    0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu]     amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm]     drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20     task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address:
    0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu]     amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm]     drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20     task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 (CVE-2022-50303)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix mr->map double free     rxe_mr_cleanup() which tries to free mr->map again will be called when rxe_mr_init_user() fails: CPU: 0     PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25 Hardware name: QEMU     Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call     Trace: <TASK> dump_stack_lvl+0x45/0x5d panic+0x19e/0x349 end_report.part.0+0x54/0x7c     kasan_report.cold+0xa/0xf rxe_mr_cleanup+0x9d/0xf0 [rdma_rxe] __rxe_cleanup+0x10a/0x1e0 [rdma_rxe]     rxe_reg_user_mr+0xb7/0xd0 [rdma_rxe] ib_uverbs_reg_mr+0x26a/0x480 [ib_uverbs]     ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x1a2/0x250 [ib_uverbs] ib_uverbs_cmd_verbs+0x1397/0x15a0     [ib_uverbs] This issue was firstly exposed since commit b18c7da63fcb (RDMA/rxe: Fix memory leak in error     path code) and then we fixed it in commit 8ff5f5d9d8cf (RDMA/rxe: Prevent double freeing rxe_map_set())     but this fix was reverted together at last by commit 1e75550648da (Revert RDMA/rxe: Create duplicate     mapping tables for FMRs) Simply let rxe_mr_cleanup() always handle freeing the mr->map once it is     successfully allocated. (CVE-2022-50543)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: fix uninititialized value in     'ext4_evict_inode' Syzbot found the following issue: =====================================================     BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 ext4_evict_inode+0xdd/0x26b0     fs/ext4/inode.c:180 evict+0x365/0x9a0 fs/inode.c:664 iput_final fs/inode.c:1747 [inline] iput+0x985/0xdd0     fs/inode.c:1773 __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361 ext4_mknod+0x376/0x840     fs/ext4/namei.c:2844 vfs_mknod+0x79d/0x830 fs/namei.c:3914 do_mknodat+0x47d/0xaa0 __do_sys_mknodat     fs/namei.c:3992 [inline] __se_sys_mknodat fs/namei.c:3989 [inline] __ia32_sys_mknodat+0xeb/0x150     fs/namei.c:3989 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100     arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203     do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit     was created at: __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578 alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285     alloc_slab_page mm/slub.c:1794 [inline] allocate_slab+0x1b5/0x1010 mm/slub.c:1939 new_slab mm/slub.c:1992     [inline] ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180 __slab_alloc mm/slub.c:3279 [inline] slab_alloc_node     mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline]     kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3117 [inline]     ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321 alloc_inode+0x83/0x440 fs/inode.c:259 new_inode_pseudo     fs/inode.c:1018 [inline] new_inode+0x3b/0x430 fs/inode.c:1046 __ext4_new_inode+0x2a7/0x7ec0     fs/ext4/ialloc.c:959 ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992 vfs_mkdir+0x62a/0x870 fs/namei.c:4035     do_mkdirat+0x466/0x7b0 fs/namei.c:4060 __do_sys_mkdirat fs/namei.c:4075 [inline] __se_sys_mkdirat     fs/namei.c:4073 [inline] __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073 do_syscall_32_irqs_on     arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178     do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20     arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 CPU: 1 PID: 4625 Comm: syz-     executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0 Hardware name: Google Google Compute     Engine/Google Compute Engine, BIOS Google 10/26/2022 =====================================================     Now, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failed before set 'ei->i_flags' in     '__ext4_new_inode()', then do 'iput()'. As after 6bc0d63dad7f commit will access 'ei->i_flags' in     'ext4_evict_inode()' which will lead to access uninit-value. To solve above issue just init 'ei->i_flags'     in 'ext4_alloc_inode()'. (CVE-2022-50546)

  - In the Linux kernel, the following vulnerability has been resolved: ipvlan: add ipvlan_route_v6_outbound()     helper Inspired by syzbot reports using a stack of multiple ipvlan devices. Reduce stack size needed in     ipvlan_process_v6_outbound() by moving the flowi6 struct used for the route lookup in an non inlined     helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack, immediately reclaimed. Also make sure     ipvlan_process_v4_outbound() is not inlined. We might also have to lower MAX_NEST_DEV, because only syzbot     uses setups with more than four stacked devices. BUG: TASK stack guard page was hit at ffffc9000e803ff8     (stack is ffffc9000e804000..ffffc9000e808000) stack guard page: 0000 [#1] SMP KASAN CPU: 0 PID: 13442     Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0 Hardware name: Google Google Compute Engine/Google     Compute Engine, BIOS Google 10/09/2023 RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188 Code:
    48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00     00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89 RSP:
    0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2     RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08:
    0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c     R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000)     GS:ffff8881f6800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000     DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <#DF>     </#DF> <TASK> [<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 [<ffffffff817e5bf2>]     instrument_atomic_read include/linux/instrumented.h:72 [inline] [<ffffffff817e5bf2>] _test_bit     include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] [<ffffffff817e5bf2>] cpumask_test_cpu     include/linux/cpumask.h:506 [inline] [<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline]     [<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline] [<ffffffff817e5bf2>]     lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40     include/linux/rcupdate.h:306 [<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline]     [<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221 [<ffffffff85618120>]     ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606 [<ffffffff856f65b5>] pol_lookup_func     include/net/ip6_fib.h:584 [inline] [<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620     net/ipv6/fib6_rules.c:116 [<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0     net/ipv6/route.c:2638 [<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651     [<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline] [<ffffffff838bd5a3>]     ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline] [<ffffffff838bd5a3>]     ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bd5a3>]     ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bd5a3>]     ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>]     ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit     include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline]     [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>]
    __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit     include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529     [inline] [<f ---truncated--- (CVE-2023-52796)

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

  - In the Linux kernel, the following vulnerability has been resolved: virtio_net: fix xdp_rxq_info bug after     suspend/resume The following sequence currently causes a driver bug warning when using virtio_net: # ip     link set eth0 up # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem) <resume> # ip link set     eth0 down Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138     xdp_rxq_info_unreg+0x58/0x60 Call trace: xdp_rxq_info_unreg+0x58/0x60 virtnet_close+0x58/0xac
    __dev_close_many+0xac/0x140 __dev_change_flags+0xd8/0x210 dev_change_flags+0x24/0x64     do_setlink+0x230/0xdd0 ... This happens because virtnet_freeze() frees the receive_queue completely     (including struct xdp_rxq_info) but does not call xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets     up the receive_queue again but does not call xdp_rxq_info_reg(). Actually, parts of virtnet_freeze_down()     and virtnet_restore_up() are almost identical to virtnet_close() and virtnet_open(): only the calls to     xdp_rxq_info_(un)reg() are missing. This means that we can fix this easily and avoid such problems in the     future by just calling virtnet_close()/open() from the freeze/restore handlers. Aside from adding the     missing xdp_rxq_info calls the only difference is that the refill work is only cancelled if     netif_running(). However, this should not make any functional difference since the refill work should only     be active if the network interface is actually up. (CVE-2022-49687)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Fix a use-after-free Change     the LIO port members inside struct srpt_port from regular members into pointers. Allocate the LIO port     data structures from inside srpt_make_tport() and free these from inside srpt_make_tport(). Keep struct     srpt_device as long as either an RDMA port or a LIO target port is associated with it. This patch     decouples the lifetime of struct srpt_port (controlled by the RDMA core) and struct srpt_port_id     (controlled by LIO). This patch fixes the following KASAN complaint: BUG: KASAN: use-after-free in     srpt_enable_tpg+0x31/0x70 [ib_srpt] Read of size 8 at addr ffff888141cc34b8 by task check/5093 Call Trace:
    <TASK> show_stack+0x4e/0x53 dump_stack_lvl+0x51/0x66 print_address_description.constprop.0.cold+0xea/0x41e     print_report.cold+0x90/0x205 kasan_report+0xb9/0xf0 __asan_load8+0x69/0x90 srpt_enable_tpg+0x31/0x70     [ib_srpt] target_fabric_tpg_base_enable_store+0xe2/0x140 [target_core_mod] configfs_write_iter+0x18b/0x210     new_sync_write+0x1f2/0x2f0 vfs_write+0x3e3/0x540 ksys_write+0xbb/0x140 __x64_sys_write+0x42/0x50     do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> (CVE-2022-50129)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix double release compute     pasid If kfd_process_device_init_vm returns failure after vm is converted to compute vm and vm->pasid set     to compute pasid, KFD will not take pdd->drm_file reference. As a result, drm close file handler maybe     called to release the compute pasid before KFD process destroy worker to release the same pasid and set     vm->pasid to zero, this generates below WARNING backtrace and NULL pointer access. Add helper     amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of kfd_process_device_init_vm, to ensure vm     pasid is the original pasid if acquiring vm failed or is the compute pasid with pdd->drm_file reference     taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for     id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP:
    0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu]     amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm]     drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20     task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address:
    0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu]     amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm]     drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20     task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 (CVE-2022-50303)

  - In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: idle: Check     acpi_fetch_acpi_dev() return value The return value of acpi_fetch_acpi_dev() could be NULL, which would     cause a NULL pointer dereference to occur in acpi_device_hid(). [ rjw: Subject and changelog edits, added     empty line after if () ] (CVE-2022-50327)

  - In the Linux kernel, the following vulnerability has been resolved: NFSD: Protect against send buffer     overflow in NFSv2 READ Since before the git era, NFSD has conserved the number of pages held by each nfsd     thread by combining the RPC receive and send buffers into a single array of pages. This works because     there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same     time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of     rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks     when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by     sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full     maximum payload size cannot be constructed in that case. (CVE-2022-50410)

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.

  - drm/amdkfd: Fix double release compute pasid If kfd_process_device_init_vm returns failure after vm is     converted to compute vm and vm->pasid set to compute pasid, KFD will not take pdd->drm_file reference. As     a result, drm close file handler maybe called to release the compute pasid before KFD process destroy     worker to release the same pasid and set vm->pasid to zero, this generates below WARNING backtrace and     NULL pointer access. Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last step of     kfd_process_device_init_vm, to ensure vm pasid is the original pasid if acquiring vm failed or is the     compute pasid with pdd->drm_file reference taken to avoid double release same pasid. amdgpu: Failed to     create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542     at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace:
    amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu]     drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0     [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL     pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace:
    amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu]     drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0     [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 (CVE-2022-50303)

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

ID	Name	Product	Family	Type	Severity
359605	CentOS Linux 8.5 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.5:CLSA-2026:1777614954)	Nessus	CentOS Local Security Checks	Local	high
352091	CentOS Linux 8.4 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS8.4:CLSA-2026:1777614651)	Nessus	CentOS 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
264969	Linux Distros Unpatched Vulnerability : CVE-2022-50303	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2022-50303

high

Tenable Plugins

high

high

high

high