In the Linux kernel, the following vulnerability has been resolved: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver Currently phylink_resolve() protects itself against concurrent phylink_bringup_phy() or phylink_disconnect_phy() calls which modify pl->phydev by relying on pl->state_mutex. The problem is that in phylink_resolve(), pl->state_mutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->state_mutex. But that requires dereferencing pl->phydev in the first place, and without pl->state_mutex, that is racy. Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutex_lock(&phy->lock) will be moved outside of the mutex_lock(&pl->state_mutex) section. Another alternative considered would have been to let phylink_resolve() acquire the rtnl_mutex, which is also held when phylink_bringup_phy() and phylink_disconnect_phy() are called. But since phylink_disconnect_phy() runs under rtnl_lock(), it would deadlock with phylink_resolve() when calling flush_work(&pl->resolve). Additionally, it would have been undesirable because it would have unnecessarily blocked many other call paths as well in the entire kernel, so the smaller-scoped lock was preferred.

The AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1771081379 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix slab-use-after-     free Read in mgmt_remove_adv_monitor_sync This fixes the following crash:
    ================================================================== BUG: KASAN: slab-use-after-free in     mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 Read of size 8 at addr ffff88814128f898     by task kworker/u9:4/5961 CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted     6.12.0-syzkaller-10684-gf1cd565ce577 #0 Hardware name: Google Google Compute Engine/Google Compute Engine,     BIOS Google 09/13/2024 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> __dump_stack     lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description     mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180     mm/kasan/report.c:602 mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543     hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229     [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30     kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80     arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated     by task 16026: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80     mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0     mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390     mm/slub.c:4314 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037     [inline] mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x36/0x120     net/bluetooth/mgmt_util.c:296 remove_adv_monitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568     hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x7b8/0x11c0     net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x221/0x270     net/socket.c:726 sock_write_iter+0x2d7/0x3f0 net/socket.c:1147 new_sync_write fs/read_write.c:586 [inline]     vfs_write+0xaeb/0xd30 fs/read_write.c:679 ksys_write+0x18f/0x2b0 fs/read_write.c:731 do_syscall_x64     arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83     entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 16022: kasan_save_stack mm/kasan/common.c:47     [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50     mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70     mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338     [inline] slab_free mm/slub.c:4598 [inline] kfree+0x196/0x420 mm/slub.c:4746     mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259 __mgmt_power_off+0x183/0x430     net/bluetooth/mgmt.c:9550 hci_dev_close_sync+0x6c4/0x11c0 net/bluetooth/hci_sync.c:5208 hci_dev_do_close     net/bluetooth/hci_core.c:483 [inline] hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508     sock_do_ioctl+0x158/0x460 net/socket.c:1209 sock_ioctl+0x626/0x8e0 net/socket.c:1328 vfs_ioctl     fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892     do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83     entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2024-58013)

  - In the Linux kernel, the following vulnerability has been resolved: nvmet: fix out-of-bounds access in     nvmet_enable_port When trying to enable a port that has no transport configured yet, nvmet_enable_port()     uses NVMF_TRTYPE_MAX (255) to query the transports array, causing an out-of-bounds access: [ 106.058694]     BUG: KASAN: global-out-of-bounds in nvmet_enable_port+0x42/0x1da [ 106.058719] Read of size 8 at addr     ffffffff89dafa58 by task ln/632 [...] [ 106.076026] nvmet: transport type 255 not supported Since commit     200adac75888, NVMF_TRTYPE_MAX is the default state as configured by nvmet_ports_make(). Avoid this by     checking for NVMF_TRTYPE_MAX before proceeding. (CVE-2025-37825)

  - In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op     runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The     content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe'     counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can     be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of     concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh.
    At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this     variable can be modified from both contexts too. (CVE-2025-38004)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Set n_channels after     allocating struct cfg80211_scan_request Make sure that n_channels is set after allocating the struct     cfg80211_registered_device::int_scan_req member. Seen with syzkaller: UBSAN: array-index-out-of-bounds in     net/mac80211/scan.c:1208:5 index 0 is out of range for type 'struct ieee80211_channel *[]
    __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]') This was missed in the initial conversions     because I failed to locate the allocation likely due to the sizeof(void *) not matching the channels     array type. (CVE-2025-38013)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix KASAN: slab-use-after-     free Read in ib_register_device problem Call Trace: __dump_stack lib/dump_stack.c:94 [inline]     dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline]     print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634     strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline]     get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158     kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device     drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00     drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320     drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550     rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680     drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195     rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313     [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0     net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727     [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620
    __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]     do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f This     problem is similar to the problem that the commit 1d6a9e7449e2 (RDMA/core: Fix use-after-free when rename     device name) fixes. The root cause is: the function ib_device_rename() renames the name with lock. But in     the function kobject_uevent(), this name is accessed without lock protection at the same time. The     solution is to add the lock protection when this name is accessed in the function kobject_uevent().
    (CVE-2025-38022)

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

The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1771081379 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix slab-use-after-     free Read in mgmt_remove_adv_monitor_sync This fixes the following crash:
    ================================================================== BUG: KASAN: slab-use-after-free in     mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 Read of size 8 at addr ffff88814128f898     by task kworker/u9:4/5961 CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted     6.12.0-syzkaller-10684-gf1cd565ce577 #0 Hardware name: Google Google Compute Engine/Google Compute Engine,     BIOS Google 09/13/2024 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> __dump_stack     lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description     mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180     mm/kasan/report.c:602 mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543     hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229     [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30     kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80     arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated     by task 16026: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80     mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0     mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390     mm/slub.c:4314 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037     [inline] mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x36/0x120     net/bluetooth/mgmt_util.c:296 remove_adv_monitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568     hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x7b8/0x11c0     net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x221/0x270     net/socket.c:726 sock_write_iter+0x2d7/0x3f0 net/socket.c:1147 new_sync_write fs/read_write.c:586 [inline]     vfs_write+0xaeb/0xd30 fs/read_write.c:679 ksys_write+0x18f/0x2b0 fs/read_write.c:731 do_syscall_x64     arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83     entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 16022: kasan_save_stack mm/kasan/common.c:47     [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50     mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70     mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338     [inline] slab_free mm/slub.c:4598 [inline] kfree+0x196/0x420 mm/slub.c:4746     mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259 __mgmt_power_off+0x183/0x430     net/bluetooth/mgmt.c:9550 hci_dev_close_sync+0x6c4/0x11c0 net/bluetooth/hci_sync.c:5208 hci_dev_do_close     net/bluetooth/hci_core.c:483 [inline] hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508     sock_do_ioctl+0x158/0x460 net/socket.c:1209 sock_ioctl+0x626/0x8e0 net/socket.c:1328 vfs_ioctl     fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892     do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83     entry_SYSCALL_64_after_hwframe+0x77/0x7f (CVE-2024-58013)

  - In the Linux kernel, the following vulnerability has been resolved: nvmet: fix out-of-bounds access in     nvmet_enable_port When trying to enable a port that has no transport configured yet, nvmet_enable_port()     uses NVMF_TRTYPE_MAX (255) to query the transports array, causing an out-of-bounds access: [ 106.058694]     BUG: KASAN: global-out-of-bounds in nvmet_enable_port+0x42/0x1da [ 106.058719] Read of size 8 at addr     ffffffff89dafa58 by task ln/632 [...] [ 106.076026] nvmet: transport type 255 not supported Since commit     200adac75888, NVMF_TRTYPE_MAX is the default state as configured by nvmet_ports_make(). Avoid this by     checking for NVMF_TRTYPE_MAX before proceeding. (CVE-2025-37825)

  - In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op     runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The     content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe'     counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can     be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of     concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh.
    At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this     variable can be modified from both contexts too. (CVE-2025-38004)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Set n_channels after     allocating struct cfg80211_scan_request Make sure that n_channels is set after allocating the struct     cfg80211_registered_device::int_scan_req member. Seen with syzkaller: UBSAN: array-index-out-of-bounds in     net/mac80211/scan.c:1208:5 index 0 is out of range for type 'struct ieee80211_channel *[]
    __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]') This was missed in the initial conversions     because I failed to locate the allocation likely due to the sizeof(void *) not matching the channels     array type. (CVE-2025-38013)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix KASAN: slab-use-after-     free Read in ib_register_device problem Call Trace: __dump_stack lib/dump_stack.c:94 [inline]     dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline]     print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634     strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline]     get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158     kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device     drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00     drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320     drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550     rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680     drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195     rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313     [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0     net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727     [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620
    __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]     do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f This     problem is similar to the problem that the commit 1d6a9e7449e2 (RDMA/core: Fix use-after-free when rename     device name) fixes. The root cause is: the function ib_device_rename() renames the name with lock. But in     the function kobject_uevent(), this name is accessed without lock protection at the same time. The     solution is to add the lock protection when this name is accessed in the function kobject_uevent().
    (CVE-2025-38022)

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

  - In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix uaf for bfqq in     bfq_exit_icq_bfqq Commit 64dc8c732f5c (block, bfq: fix possible uaf for 'bfqq->bic') will access     'bic->bfqq' in bic_set_bfqq(), however, bfq_exit_icq_bfqq() can free bfqq first, and then call     bic_set_bfqq(), which will cause uaf. Fix the problem by moving bfq_exit_bfqq() behind bic_set_bfqq().
    (CVE-2022-50329)

  - In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible uaf for     'bfqq->bic' Our test report a uaf for 'bfqq->bic' in 5.10:
    ================================================================== BUG: KASAN: use-after-free in     bfq_select_queue+0x378/0xa30 CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted     5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),     BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014 Call Trace:
    bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0
    __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0
    __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190     blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90
    __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4]     ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0     do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6 Commit 3bc5e683c67d (bfq: Split shared     queues on move between cgroups) changes that move process to a new cgroup will allocate a new bfqq to     use, however, the old bfqq and new bfqq can point to the same bic: 1) Initial state, two process with io     in the same cgroup. Process 1 Process 2 (BIC1) (BIC2) |  |  | | | | V | V | bfqq1 bfqq2 2) bfqq1 is     merged to bfqq2. Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop) 3) Process 1     exit, then issue new io(denoce IOA) from Process 2. (BIC2) |  | | V | bfqq2(coop) 4) Before IOA is     completed, move Process 2 to another cgroup and issue io. Process 2 (BIC2)  |\--------------\ | V bfqq2     bfqq3 Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2. If all the requests are     completed, and Process 2 exit, BIC2 will be freed while there is no guarantee that bfqq2 will be freed     before BIC2. Fix the problem by clearing bfqq->bic while bfqq is detached from bic. (CVE-2022-50488)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Delay the unmapping of     the buffer On WCN3990, we are seeing a rare scenario where copy engine hardware is sending a copy complete     interrupt to the host driver while still processing the buffer that the driver has sent, this is leading     into an SMMU fault triggering kernel panic. This is happening on copy engine channel 3 (CE3) where the     driver normally enqueues WMI commands to the firmware. Upon receiving a copy complete interrupt, host     driver will immediately unmap and frees the buffer presuming that hardware has processed the buffer. In     the issue case, upon receiving copy complete interrupt, host driver will unmap and free the buffer but     since hardware is still accessing the buffer (which in this case got unmapped in parallel), SMMU hardware     will trigger an SMMU fault resulting in a kernel panic. In order to avoid this, as a work around, add a     delay before unmapping the copy engine source DMA buffer. This is conditionally done for WCN3990 and only     for the CE3 channel where issue is seen. Below is the crash signature: wifi smmu error: kernel: [     10.120965] arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x7fdfd8ac0,     fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandled context fault:fsr=0x402,     iova=0x7fe06fdc0, fsynr=0x710003, cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal error     received: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091: cmnos_thread.c:3998:Asserted in     copy_engine.c:AXI_ERROR_DETECTED:2149 remoteproc remoteproc0: crash detected in 4080000.remoteproc: type     fatal error <3> remoteproc remoteproc0: handling crash #1 in 4080000.remoteproc pc :
    __arm_lpae_unmap+0x500/0x514 lr : __arm_lpae_unmap+0x4bc/0x514 sp : ffffffc011ffb530 x29: ffffffc011ffb590     x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000004 x25: 0000000000000003 x24:
    ffffffc011ffb890 x23: ffffffa762ef9be0 x22: ffffffa77244ef00 x21: 0000000000000009 x20: 00000007fff7c000     x19: 0000000000000003 x18: 0000000000000000 x17: 0000000000000004 x16: ffffffd7a357d9f0 x15:
    0000000000000000 x14: 00fd5d4fa7ffffff x13: 000000000000000e x12: 0000000000000000 x11: 00000000ffffffff     x10: 00000000fffffe00 x9 : 000000000000017c x8 : 000000000000000c x7 : 0000000000000000 x6 :
    ffffffa762ef9000 x5 : 0000000000000003 x4 : 0000000000000004 x3 : 0000000000001000 x2 : 00000007fff7c000     x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace: __arm_lpae_unmap+0x500/0x514
    __arm_lpae_unmap+0x4bc/0x514 __arm_lpae_unmap+0x4bc/0x514 arm_lpae_unmap_pages+0x78/0xa4     arm_smmu_unmap_pages+0x78/0x104 __iommu_unmap+0xc8/0x1e4 iommu_unmap_fast+0x38/0x48
    __iommu_dma_unmap+0x84/0x104 iommu_dma_free+0x34/0x50 dma_free_attrs+0xa4/0xd0     ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c [ath10k_core]     ath10k_halt+0x11c/0x180 [ath10k_core] ath10k_stop+0x54/0x94 [ath10k_core] drv_stop+0x48/0x1c8 [mac80211]     ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c [mac80211] __dev_open+0xb4/0x174
    __dev_change_flags+0xc4/0x1dc dev_change_flags+0x3c/0x7c devinet_ioctl+0x2b4/0x580 inet_ioctl+0xb0/0x1b4     sock_do_ioctl+0x4c/0x16c compat_ifreq_ioctl+0x1cc/0x35c compat_sock_ioctl+0x110/0x2ac
    __arm64_compat_sys_ioctl+0xf4/0x3e0 el0_svc_common+0xb4/0x17c el0_svc_compat_handler+0x2c/0x58     el0_svc_compat+0x8/0x2c Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 (CVE-2022-50700)

  - In the Linux kernel, the following vulnerability has been resolved: tcp: fix a signed-integer-overflow bug     in tcp_add_backlog() The type of sk_rcvbuf and sk_sndbuf in struct sock is int, and in tcp_add_backlog(),     the variable limit is caculated by adding sk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max value     of int and overflow. This patch reduces the limit budget by halving the sndbuf to solve this issue since     ACK packets are much smaller than the payload. (CVE-2022-50865)

  - In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix uaf for bfqq in     bic_set_bfqq() After commit 64dc8c732f5c (block, bfq: fix possible uaf for 'bfqq->bic'), bic->bfqq will     be accessed in bic_set_bfqq(), however, in some context bic->bfqq will be freed, and bic_set_bfqq() is     called with the freed bic->bfqq. Fix the problem by always freeing bfqq after bic_set_bfqq().
    (CVE-2023-52983)

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: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 Rocky Linux 10.1 host has packages installed that are affected by multiple vulnerabilities as referenced in the CIQ crlsa-2026_0453 advisory.

    * kernel: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CVE-2025-39806)

    * kernel: audit: fix out-of-bounds read in audit_compare_dname_path() (CVE-2025-39840)

    * kernel: mm: slub: avoid wake up kswapd in set_track_prepare (CVE-2025-39843)

    * kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver     (CVE-2025-39905)

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

    * kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)

    * kernel: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CVE-2025-40277)

    * kernel: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths     (CVE-2025-68287)

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

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

The CentOS Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare CENTOS-STREAM8:CLSA-2026:1784275029 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic     ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had     registered two ops with the same content successively, both dynamic. After unregistering the second ops, a     use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the     FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also,     both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the     FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and     ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is     released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1]     BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-     after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr     ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7     Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c     arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack     lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118     print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report     mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline     mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func     kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049     ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault     mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user     lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139     getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445:
    kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline]
    __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c     mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924     mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline]     perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733     [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline]
    __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80     kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48     kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358
    __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445     [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline]     slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10     mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc     kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline]
    __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...] (CVE-2022-49892)

  - In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Fix references to     freed memory Most users after parsing a topology file, release memory used by it, so having pointer     references directly into topology file contents is wrong. Use devm_kmemdup(), to allocate memory as     needed. (CVE-2024-41069)

  - In the Linux kernel, the following vulnerability has been resolved: tls: separate no-async decryption     request handling from async If we're not doing async, the handling is much simpler. There's no reference     counting, we just need to wait for the completion to wake us up and return its result. We should     preferably also use a separate crypto_wait. I'm not seeing a UAF as I did in the past, I think     aec7961916f3 (tls: fix race between async notify and socket close) took care of it. This will make the     next fix easier. (CVE-2024-58240)

  - In the Linux kernel, the following vulnerability has been resolved: can: bcm: add locking for bcm_op     runtime updates The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The     content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe'     counter is then set to zero. Although this appeared to be a safe operation the updates of 'currframe' can     be triggered from user space and hrtimer context in bcm_can_tx(). Anderson Nascimento created a proof of     concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spin_lock_bh.
    At the rework of bcm_can_tx() the 'count' variable has been moved into the protected section as this     variable can be modified from both contexts too. (CVE-2025-38004)

  - In the Linux kernel, the following vulnerability has been resolved: xfrm: Duplicate SPI Handling The issue     originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel     function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index     (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI     is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by     their destination addresses. This behavior causes inconsistencies during SPI lookups for inbound packets.
    Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail,     resulting in packet drops. According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is     uniquely identified by the SPI and optionally protocol. Reproducing the Issue Reliably: To consistently     reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max =     0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each     using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a     duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently     reproducible. With a broader/default range, it becomes rare and unpredictable. Current implementation:
    xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same     SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in     different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a     result, the lookup will result in NULL and kernel allows that Duplicate SPI Proposed Change:
    xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket     and matches SPI and proto. (CVE-2025-39797)

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

An update of the linux package has been released.

The remote AlmaLinux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the ALSA-2026:0453 advisory.

    * kernel: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CVE-2025-39806)
      * kernel: audit: fix out-of-bounds read in audit_compare_dname_path() (CVE-2025-39840)
      * kernel: mm: slub: avoid wake up kswapd in set_track_prepare (CVE-2025-39843)
      * kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver     (CVE-2025-39905)
      * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)
      * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)
      * kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)
      * kernel: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CVE-2025-40277)
      * kernel: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths     (CVE-2025-68287)

Tenable has extracted the preceding description block directly from the AlmaLinux 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 RockyLinux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the RLSA-2026:0453 advisory.

    * kernel: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CVE-2025-39806)

    * kernel: audit: fix out-of-bounds read in audit_compare_dname_path() (CVE-2025-39840)

    * kernel: mm: slub: avoid wake up kswapd in set_track_prepare (CVE-2025-39843)

    * kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver     (CVE-2025-39905)

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

    * kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)

    * kernel: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CVE-2025-40277)

    * kernel: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths     (CVE-2025-68287)

Tenable has extracted the preceding description block directly from the RockyLinux 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 Redhat Enterprise Linux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2026:0453 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    * kernel: HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CVE-2025-39806)

    * kernel: audit: fix out-of-bounds read in audit_compare_dname_path() (CVE-2025-39840)

    * kernel: mm: slub: avoid wake up kswapd in set_track_prepare (CVE-2025-39843)

    * kernel: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver     (CVE-2025-39905)

    * kernel: iommufd: Fix race during abort for file descriptors (CVE-2025-39966)

    * kernel: tls: wait for pending async decryptions if tls_strp_msg_hold fails (CVE-2025-40176)

    * kernel: sctp: avoid NULL dereference when chunk data buffer is missing (CVE-2025-40240)

    * kernel: drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CVE-2025-40277)

    * kernel: usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths     (CVE-2025-68287)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux 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 Oracle Linux 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-0453 advisory.

    - usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths (CKI Backport Bot)     [RHEL-137150] {CVE-2025-68287}
    - drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZE (CKI Backport Bot) [RHEL-134431]     {CVE-2025-40277}
    - net: phylink: add lock for serializing concurrent pl->phydev writes with resolver (CKI Backport Bot)     [RHEL-129812] {CVE-2025-39905}
    - sctp: avoid NULL dereference when chunk data buffer is missing (CKI Backport Bot) [RHEL-134010]     {CVE-2025-40240}
    - HID: multitouch: fix slab out-of-bounds access in mt_report_fixup() (CKI Backport Bot) [RHEL-124610]     {CVE-2025-39806}
    - audit: fix out-of-bounds read in audit_compare_dname_path() (Richard Guy Briggs) [RHEL-119185]     {CVE-2025-39840}
    - iommufd: Fix race during abort for file descriptors (Eder Zulian) [RHEL-123789] {CVE-2025-39966}
    - mm: slub: avoid wake up kswapd in set_track_prepare (Audra Mitchell) [RHEL-125522] {CVE-2025-39843}
    - tls: wait for pending async decryptions if tls_strp_msg_hold fails (CKI Backport Bot) [RHEL-128866]     {CVE-2025-40176}

Tenable has extracted the preceding description block directly from the Oracle Linux 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.

  - net: phylink: add lock for serializing concurrent pl->phydev writes with resolver Currently     phylink_resolve() protects itself against concurrent phylink_bringup_phy() or phylink_disconnect_phy()     calls which modify pl->phydev by relying on pl->state_mutex. The problem is that in phylink_resolve(),     pl->state_mutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be     acquired prior to pl->state_mutex. But that requires dereferencing pl->phydev in the first place, and     without pl->state_mutex, that is racy. Hence the reason for the extra lock. Currently it is redundant, but     it will serve a functional purpose once mutex_lock(&phy->lock) will be moved outside of the     mutex_lock(&pl->state_mutex) section. Another alternative considered would have been to let     phylink_resolve() acquire the rtnl_mutex, which is also held when phylink_bringup_phy() and     phylink_disconnect_phy() are called. But since phylink_disconnect_phy() runs under rtnl_lock(), it would     deadlock with phylink_resolve() when calling flush_work(&pl->resolve). Additionally, it would have been     undesirable because it would have unnecessarily blocked many other call paths as well in the entire     kernel, so the smaller-scoped lock was preferred. (CVE-2025-39905)

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

ID	Name	Product	Family	Type	Severity
361179	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1771081379)	Nessus	Alma Linux Local Security Checks	Local	high
361071	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1771081379)	Nessus	Rocky Linux Local Security Checks	Local	high
360081	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-abi-stablelists / kernel-core / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1771239384)	Nessus	Alma Linux Local Security Checks	Local	high
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
354138	Rocky Linux 10.1 [CIQ] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (crlsa-2026_0453)	Nessus	Rocky Linux Local Security Checks	Local	high
352747	CentOS Linux 8 [TuxCare] Security Update: bpftool / kernel / kernel-core / kernel-cross-headers / etc Multiple Vulnerabilities (CENTOS-STREAM8:CLSA-2026:1784275029)	Nessus	CentOS Local Security Checks	Local	high
332358	Photon OS 5.0: Linux PHSA-2025-5.0-91-0720	Nessus	PhotonOS Local Security Checks	Local	high
291602	AlmaLinux 10 : kernel (ALSA-2026:0453)	Nessus	Alma Linux Local Security Checks	Local	high
291297	RockyLinux 10 : kernel (RLSA-2026:0453)	Nessus	Rocky Linux Local Security Checks	Local	high
283499	RHEL 10 : kernel (RHSA-2026:0453)	Nessus	Red Hat Local Security Checks	Local	high
282630	Oracle Linux 10 : kernel (ELSA-2026-0453)	Nessus	Oracle Linux Local Security Checks	Local	high
279911	Photon OS 5.0: Linux PHSA-2025-5.0-0720	Nessus	PhotonOS Local Security Checks	Local	high
269255	Linux Distros Unpatched Vulnerability : CVE-2025-39905	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2025-39905

high

Tenable Plugins

high

high

high

high

high

high

high

high

high

high

high

high

high