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.

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 Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

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

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

The remote Ubuntu 25.04 host has a package installed that is affected by multiple vulnerabilities as referenced in the USN-7594-1 advisory.

    Several security issues were discovered in the Linux kernel. An attacker could possibly use these to     compromise the system. This update corrects flaws in the following subsystems:

    - ARM32 architecture;

    - ARM64 architecture;

    - PowerPC architecture;

    - RISC-V architecture;

    - User-Mode Linux (UML);

    - x86 architecture;

    - Block layer subsystem;

    - Cryptographic API;

    - Compute Acceleration Framework;

    - ACPI drivers;

    - Serial ATA and Parallel ATA drivers;

    - Drivers core;

    - Ublk userspace block driver;

    - Bluetooth drivers;

    - Bus devices;

    - TPM device driver;

    - Clock framework and drivers;

    - CPU frequency scaling framework;

    - Buffer Sharing and Synchronization framework;

    - DMA engine subsystem;

    - GPU drivers;

    - HID subsystem;

    - HSI subsystem;

    - I2C subsystem;

    - I3C subsystem;

    - IIO subsystem;

    - InfiniBand drivers;

    - IOMMU subsystem;

    - IRQ chip drivers;

    - MCB driver;

    - Multiple devices driver;

    - Media drivers;

    - MemoryStick subsystem;

    - Multifunction device drivers;

    - Microchip PCI driver;

    - Intel Management Engine Interface driver;

    - PCI Endpoint Test driver;

    - MTD block device drivers;

    - Network drivers;

    - Ethernet bonding driver;

    - Mellanox network drivers;

    - STMicroelectronics network drivers;

    - NTB driver;

    - NVME drivers;

    - PCI subsystem;

    - Synopsys DesignWare PCIe PMU;

    - Mellanox platform drivers;

    - PWM drivers;

    - Remote Processor subsystem;

    - S/390 drivers;

    - SCSI subsystem;

    - Samsung SoC drivers;

    - SPI subsystem;

    - GPIB drivers;

    - VideoCore services drivers;

    - Thermal drivers;

    - TTY drivers;

    - UFS subsystem;

    - Cadence USB3 driver;

    - ChipIdea USB driver;

    - USB Device Class drivers;

    - DesignWare USB3 driver;

    - USB Gadget drivers;

    - USB Host Controller drivers;

    - USB Type-C support driver;

    - Virtio Host (VHOST) subsystem;

    - Backlight driver;

    - Framebuffer layer;

    - W1 Dallas's 1-wire bus driver;

    - 9P distributed file system;

    - File systems infrastructure;

    - BTRFS file system;

    - Ext4 file system;

    - F2FS file system;

    - JFS file system;

    - Network file systems library;

    - Network file system (NFS) server daemon;

    - NTFS3 file system;

    - Overlay file system;

    - SMB network file system;

    - Ethernet bridge;

    - io_uring subsystem;

    - Perf events;

    - Memory management;

    - UProbes tracing;

    - Amateur Radio drivers;

    - SCTP protocol;

    - Network sockets;

    - RDMA verbs API;

    - BPF subsystem;

    - Kernel fork() syscall;

    - Hibernation control;

    - Scheduler infrastructure;

    - Tracing infrastructure;

    - Watch queue notification mechanism;

    - Vector I/O iterator library;

    - 802.1Q VLAN protocol;

    - 9P file system network protocol;

    - Asynchronous Transfer Mode (ATM) subsystem;

    - Networking core;

    - Distributed Switch Architecture;

    - Ethtool driver;

    - IPv4 networking;

    - IPv6 networking;

    - MAC80211 subsystem;

    - Management Component Transport Protocol (MCTP);

    - Multipath TCP;

    - Netfilter;

    - Open vSwitch;

    - Network traffic control;

    - TIPC protocol;

    - TLS protocol;

    - Wireless networking;

    - ALSA framework;

    - WCD audio codecs;

    - SoC Audio for Freescale CPUs drivers;

    - SoC Audio generic drivers;

    - Intel ASoC drivers;

    - QCOM ASoC drivers;

    - Virtio sound driver;

    - CPU Power monitoring subsystem; (CVE-2025-37806, CVE-2025-22084, CVE-2025-39688, CVE-2025-22030,     CVE-2025-37754, CVE-2025-37783, CVE-2025-37825, CVE-2025-37752, CVE-2025-22104, CVE-2025-40014,     CVE-2025-22103, CVE-2025-37874, CVE-2025-37773, CVE-2025-37741, CVE-2025-37763, CVE-2025-37859,     CVE-2025-37779, CVE-2025-23155, CVE-2025-23143, CVE-2025-37788, CVE-2025-22028, CVE-2024-58096,     CVE-2025-37842, CVE-2025-37854, CVE-2025-38637, CVE-2024-58097, CVE-2023-53034, CVE-2025-37797,     CVE-2025-37851, CVE-2025-37941, CVE-2025-37942, CVE-2025-37748, CVE-2025-37982, CVE-2025-22058,     CVE-2025-37781, CVE-2025-23130, CVE-2025-23149, CVE-2025-23146, CVE-2025-37809, CVE-2025-37801,     CVE-2025-22080, CVE-2025-23160, CVE-2025-37823, CVE-2025-37827, CVE-2025-39755, CVE-2025-22124,     CVE-2025-22033, CVE-2025-22075, CVE-2025-37850, CVE-2025-37757, CVE-2025-22060, CVE-2025-37979,     CVE-2025-22098, CVE-2025-39989, CVE-2025-37989, CVE-2025-37790, CVE-2025-37885, CVE-2025-37875,     CVE-2025-22066, CVE-2025-37975, CVE-2025-37819, CVE-2025-37755, CVE-2025-37794, CVE-2025-23148,     CVE-2025-22067, CVE-2025-22061, CVE-2025-22109, CVE-2025-37884, CVE-2025-37852, CVE-2025-37866,     CVE-2025-37872, CVE-2025-37751, CVE-2025-23156, CVE-2025-22065, CVE-2025-37837, CVE-2025-22069,     CVE-2025-37822, CVE-2025-22128, CVE-2025-22087, CVE-2025-22023, CVE-2025-22038, CVE-2025-22096,     CVE-2025-22076, CVE-2025-22045, CVE-2025-38049, CVE-2025-37870, CVE-2025-37939, CVE-2025-37865,     CVE-2025-37860, CVE-2025-37771, CVE-2025-23144, CVE-2025-22081, CVE-2025-39778, CVE-2025-23153,     CVE-2025-22036, CVE-2025-23154, CVE-2025-22101, CVE-2025-37808, CVE-2025-37772, CVE-2025-22070,     CVE-2025-37789, CVE-2025-22025, CVE-2025-22019, CVE-2025-37868, CVE-2025-22083, CVE-2025-22095,     CVE-2025-23161, CVE-2025-22027, CVE-2025-37843, CVE-2025-37985, CVE-2025-23132, CVE-2025-22073,     CVE-2025-37940, CVE-2025-23140, CVE-2025-37828, CVE-2025-22063, CVE-2025-22053, CVE-2025-37787,     CVE-2025-23152, CVE-2025-37840, CVE-2025-22118, CVE-2025-37981, CVE-2025-22111, CVE-2025-22091,     CVE-2025-37841, CVE-2025-23142, CVE-2025-37838, CVE-2025-37775, CVE-2025-23147, CVE-2025-22022,     CVE-2025-37745, CVE-2025-37785, CVE-2025-37821, CVE-2025-37988, CVE-2025-37986, CVE-2025-23138,     CVE-2025-37836, CVE-2025-37792, CVE-2025-23141, CVE-2025-23159, CVE-2025-38240, CVE-2025-37764,     CVE-2025-22120, CVE-2025-37881, CVE-2025-37777, CVE-2025-37987, CVE-2025-37811, CVE-2025-22032,     CVE-2025-22044, CVE-2025-37943, CVE-2025-37802, CVE-2025-37829, CVE-2025-37862, CVE-2025-38575,     CVE-2025-37799, CVE-2025-37882, CVE-2025-37812, CVE-2025-37765, CVE-2025-37813, CVE-2025-37980,     CVE-2025-37873, CVE-2025-37766, CVE-2025-37761, CVE-2025-37892, CVE-2025-22094, CVE-2025-22035,     CVE-2025-22055, CVE-2025-22100, CVE-2025-37816, CVE-2025-22062, CVE-2025-22110, CVE-2025-22088,     CVE-2025-23129, CVE-2025-38479, CVE-2025-37740, CVE-2025-23136, CVE-2025-37846, CVE-2025-23163,     CVE-2025-37977, CVE-2025-37879, CVE-2025-22082, CVE-2025-22046, CVE-2025-22050, CVE-2025-22126,     CVE-2025-37796, CVE-2025-37815, CVE-2025-22127, CVE-2025-22105, CVE-2025-22068, CVE-2025-22119,     CVE-2025-22089, CVE-2025-37858, CVE-2025-37826, CVE-2025-37945, CVE-2025-23157, CVE-2025-22054,     CVE-2025-37805, CVE-2025-37856, CVE-2025-37878, CVE-2025-37768, CVE-2025-22040, CVE-2025-37944,     CVE-2025-37774, CVE-2025-22117, CVE-2025-37888, CVE-2025-37857, CVE-2025-37791, CVE-2025-37817,     CVE-2025-22041, CVE-2025-37983, CVE-2025-22039, CVE-2025-37749, CVE-2025-22097, CVE-2025-37747,     CVE-2025-37762, CVE-2025-22114, CVE-2025-37831, CVE-2025-23133, CVE-2025-22020, CVE-2025-22085,     CVE-2025-37807, CVE-2025-22059, CVE-2025-22042, CVE-2025-22123, CVE-2025-22107, CVE-2025-37759,     CVE-2024-58094, CVE-2025-40114, CVE-2025-37810, CVE-2025-37833, CVE-2025-23134, CVE-2025-23151,     CVE-2025-37743, CVE-2025-22034, CVE-2025-37739, CVE-2025-37863, CVE-2025-39735, CVE-2025-39930,     CVE-2025-37847, CVE-2025-37803, CVE-2025-37786, CVE-2025-22112, CVE-2025-37830, CVE-2025-22108,     CVE-2025-37767, CVE-2025-37814, CVE-2025-37798, CVE-2025-22086, CVE-2025-37778, CVE-2024-58093,     CVE-2025-37848, CVE-2025-22024, CVE-2025-37776, CVE-2025-38104, CVE-2025-37938, CVE-2025-37861,     CVE-2025-23150, CVE-2025-22021, CVE-2025-22018, CVE-2025-23137, CVE-2025-37756, CVE-2025-37784,     CVE-2025-37769, CVE-2025-37820, CVE-2025-37758, CVE-2025-22047, CVE-2025-37844, CVE-2025-22093,     CVE-2025-23162, CVE-2025-22051, CVE-2025-22115, CVE-2025-37845, CVE-2025-22074, CVE-2025-37883,     CVE-2025-22116, CVE-2025-37824, CVE-2025-22052, CVE-2025-22090, CVE-2025-37750, CVE-2025-39728,     CVE-2025-23145, CVE-2025-22125, CVE-2025-37834, CVE-2025-37738, CVE-2025-37760, CVE-2025-22079,     CVE-2025-37877, CVE-2025-37849, CVE-2025-22026, CVE-2025-37886, CVE-2025-22043, CVE-2025-22122,     CVE-2025-37937, CVE-2025-22071, CVE-2025-37742, CVE-2025-37744, CVE-2025-22106, CVE-2025-38152,     CVE-2025-37869, CVE-2025-23135, CVE-2025-22056, CVE-2024-58095, CVE-2025-37853, CVE-2025-37770,     CVE-2025-22031, CVE-2025-23158, CVE-2025-22072, CVE-2025-22102, CVE-2025-40325, CVE-2025-22037,     CVE-2025-37876, CVE-2025-37864, CVE-2025-37867, CVE-2025-37855, CVE-2025-37984, CVE-2025-37839,     CVE-2025-23131, CVE-2025-22121, CVE-2025-22078, CVE-2025-37800, CVE-2025-37880, CVE-2025-37925,     CVE-2025-22113, CVE-2025-22064, CVE-2025-22057, CVE-2025-22092, CVE-2025-37780, CVE-2025-37887,     CVE-2025-22099, CVE-2025-37793, CVE-2025-37978, CVE-2025-37746)

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

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

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
244566	Linux Distros Unpatched Vulnerability : CVE-2025-37825	Nessus	Misc.	Local	high
240657	Ubuntu 25.04 : Linux kernel vulnerabilities (USN-7594-1)	Nessus	Ubuntu Local Security Checks	Local	high

Detections

Analytics

CVE-2025-37825

high

Tenable Plugins

high

high

high

high

high