In the Linux kernel, the following vulnerability has been resolved: ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status() when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as the remove-time guard for draining these work objects. The delayed works are initialized during rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove path should drain work based on whether the work object exists, not on a runtime hardware state bit that can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED, and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a reachable race on current systems.

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

  - In the Linux kernel, the following vulnerability has been resolved: udf: Avoid double brelse() in     udf_rename() syzbot reported a warning like below [1]: VFS: brelse: Trying to free free buffer WARNING:
    CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace: <TASK>     invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ?     generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ?     smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ?
    __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80     blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760     deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0     task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ?     reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ?     rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0
    __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause     of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it     returns NULL. However, brelse() is called by udf_rename(), too. So, b_count on buffer_head becomes     unbalanced. This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry()     returns NULL. (CVE-2022-50755)

  - In the Linux kernel, the following vulnerability has been resolved: soc: qcom: qmi_encdec: Restrict string     length in decode The QMI TLV value for strings in a lot of qmi element info structures account for null     terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of     bounds access when the NULL character is appended in decoding. (CVE-2023-53729)

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: check CAN address family     in isotp_bind() Add missing check to block non-AF_CAN binds. Syzbot created some code which matched the     right sockaddr struct size but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family field:
    bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^ This has no funtional impact but the     userspace should be notified about the wrong address family field content. (CVE-2023-54105)

  - In the Linux kernel, the following vulnerability has been resolved: usb: rndis_host: Secure rndis_query     check against int overflow Variables off and len typed as uint32 in rndis_query function are controlled by     incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large     value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently     the response pointer will be referring to a location past the expected buffer boundaries allowing     information leakage e.g. via RNDIS_OID_802_3_PERMANENT_ADDRESS OID. (CVE-2023-54110)

  - In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: Fix shift-out-of-bounds     in spi_nor_set_erase_type spi_nor_set_erase_type() was used either to set or to mask out an erase type.
    When we used it to mask out an erase type a shift-out-of-bounds was hit: UBSAN: shift-out-of-bounds in     drivers/mtd/spi-nor/core.c:2237:24 shift exponent 4294967295 is too large for 32-bit type 'int' The     setting of the size_{shift, mask} and of the opcode are unnecessary when the erase size is zero, as     throughout the code just the erase size is considered to determine whether an erase type is supported or     not. Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF is an unused opcode. Thus     when masking out an erase type, just set the erase size to zero. This will fix the shift-out-of-bounds.
    [ta: refine changes, new commit message, fix compilation error] (CVE-2023-54295)

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.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1793100968 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: udf: Avoid double brelse() in     udf_rename() syzbot reported a warning like below [1]: VFS: brelse: Trying to free free buffer WARNING:
    CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0 ... Call Trace: <TASK>     invalidate_bh_lru+0x99/0x150 smp_call_function_many_cond+0xe2a/0x10c0 ?     generic_remap_file_range_prep+0x50/0x50 ? __brelse+0xa0/0xa0 ? __mutex_lock+0x21c/0x12d0 ?     smp_call_on_cpu+0x250/0x250 ? rcu_read_lock_sched_held+0xb/0x60 ? lock_release+0x587/0x810 ?
    __brelse+0xa0/0xa0 ? generic_remap_file_range_prep+0x50/0x50 on_each_cpu_cond_mask+0x3c/0x80     blkdev_flush_mapping+0x13a/0x2f0 blkdev_put_whole+0xd3/0xf0 blkdev_put+0x222/0x760     deactivate_locked_super+0x96/0x160 deactivate_super+0xda/0x100 cleanup_mnt+0x222/0x3d0     task_work_run+0x149/0x240 ? task_work_cancel+0x30/0x30 do_exit+0xb29/0x2a40 ?     reacquire_held_locks+0x4a0/0x4a0 ? do_raw_spin_lock+0x12a/0x2b0 ? mm_update_next_owner+0x7c0/0x7c0 ?     rwlock_bug.part.0+0x90/0x90 ? zap_other_threads+0x234/0x2d0 do_group_exit+0xd0/0x2a0
    __x64_sys_exit_group+0x3a/0x50 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause     of the issue is that brelse() is called on both ofibh.sbh and ofibh.ebh by udf_find_entry() when it     returns NULL. However, brelse() is called by udf_rename(), too. So, b_count on buffer_head becomes     unbalanced. This patch fixes the issue by not calling brelse() by udf_rename() when udf_find_entry()     returns NULL. (CVE-2022-50755)

  - In the Linux kernel, the following vulnerability has been resolved: soc: qcom: qmi_encdec: Restrict string     length in decode The QMI TLV value for strings in a lot of qmi element info structures account for null     terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of     bounds access when the NULL character is appended in decoding. (CVE-2023-53729)

  - In the Linux kernel, the following vulnerability has been resolved: can: isotp: check CAN address family     in isotp_bind() Add missing check to block non-AF_CAN binds. Syzbot created some code which matched the     right sockaddr struct size but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family field:
    bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^ This has no funtional impact but the     userspace should be notified about the wrong address family field content. (CVE-2023-54105)

  - In the Linux kernel, the following vulnerability has been resolved: usb: rndis_host: Secure rndis_query     check against int overflow Variables off and len typed as uint32 in rndis_query function are controlled by     incoming RNDIS response message thus their value may be manipulated. Setting off to a unexpectetly large     value will cause the sum with len and 8 to overflow and pass the implemented validation step. Consequently     the response pointer will be referring to a location past the expected buffer boundaries allowing     information leakage e.g. via RNDIS_OID_802_3_PERMANENT_ADDRESS OID. (CVE-2023-54110)

  - In the Linux kernel, the following vulnerability has been resolved: mtd: spi-nor: Fix shift-out-of-bounds     in spi_nor_set_erase_type spi_nor_set_erase_type() was used either to set or to mask out an erase type.
    When we used it to mask out an erase type a shift-out-of-bounds was hit: UBSAN: shift-out-of-bounds in     drivers/mtd/spi-nor/core.c:2237:24 shift exponent 4294967295 is too large for 32-bit type 'int' The     setting of the size_{shift, mask} and of the opcode are unnecessary when the erase size is zero, as     throughout the code just the erase size is considered to determine whether an erase type is supported or     not. Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF is an unused opcode. Thus     when masking out an erase type, just set the erase size to zero. This will fix the shift-out-of-bounds.
    [ta: refine changes, new commit message, fix compilation error] (CVE-2023-54295)

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

  - In the Linux kernel, the following vulnerability has been resolved: vhost: fix hung thread due to     erroneous iotlb entries In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and     last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with     iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends     up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous     entry. Call Trace: <TASK> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340     vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366 vhost_transport_do_send_pkt+0xe0/0xfd0     drivers/vhost/vsock.c:104 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372 kthread+0x2e9/0x3a0     kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Reported by syzbot at:
    https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87 To fix this, do two things: 1. Return -EINVAL     in vhost_chr_write_iter() when userspace asks to map a range with size 0. 2. Fix     vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX] by splitting it into two entries.
    (CVE-2022-48862)

  - In the Linux kernel, the following vulnerability has been resolved: net: hns3: add vlan list lock to     protect vlan list When adding port base VLAN, vf VLAN need to remove from HW and modify the vlan state in     vf VLAN list as false. If the periodicity task is freeing the same node, it may cause use after free     error. This patch adds a vlan list lock to protect the vlan list. (CVE-2022-49182)

  - In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: Fix crash due to race     between amd_pmu_enable_all, perf NMI and throttling amd_pmu_enable_all() does: if (!test_bit(idx,     cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can     come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the     one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled     event has very low sampling period and causes immediate successive NMI, causing the event to be throttled,     cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in     amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the     NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF:
    supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK>     amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ?     hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60
    __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0     cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK>     amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of     BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and     enable it back while returning from NMI. This will solve the issue by not enabling those events whose     active_masks are set but are not yet enabled in hw pmu. (CVE-2022-49781)

  - In the Linux kernel, the following vulnerability has been resolved: blk-iolatency: Fix memory leak on     add_disk() failures When a gendisk is successfully initialized but add_disk() fails such as when a loop     device has invalid number of minor device numbers specified, blkcg_init_disk() is called during init and     then blkcg_exit_disk() during error handling. Unfortunately, iolatency gets initialized in the former but     doesn't get cleaned up in the latter. This is because, in non-error cases, the cleanup is performed by     del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos policies, iolatency being one of     them, can only be activated once the disk is fully registered and visible. That assumption is true for wbt     and iocost, but not so for iolatency as it gets initialized before add_disk() is called. It is desirable     to lazy-init rq_qos policies because they are optional features and add to hot path overhead once     initialized - each IO has to walk all the registered rq_qos policies. So, we want to switch iolatency to     lazy init too. However, that's a bigger change. As a fix for the immediate problem, let's just add an     extra call to rq_qos_exit() in blkcg_exit_disk(). This is safe because duplicate calls to rq_qos_exit()     become noop's. (CVE-2022-50550)

  - In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to     remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put     down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed.
    Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1)     Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host     ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up     [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23:
    enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen     1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd     ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0     down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc     mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off     (CVE-2024-26830)

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.

  - ASoC: rt700-sdw: always drain jack work on remove rt700_sdw_remove() drains jack_detect_work and     jack_btn_check_work only when rt700->hw_init is true. That state bit is cleared by rt700_update_status()     when the SoundWire slave becomes UNATTACHED, but a jack work item can already have been queued by     rt700_interrupt_callback() or rt700_jack_init() while the device was initialized. Do not use hw_init as     the remove-time guard for draining these work objects. The delayed works are initialized during     rt700_init(), so remove can cancel them unconditionally and pair the object lifetime with the codec-     private data lifetime instead of a mutable hardware state bit. This issue was found by our static analysis     tool and then confirmed by manual review of the SoundWire status, interrupt and remove paths. The remove     path should drain work based on whether the work object exists, not on a runtime hardware state bit that     can change after the work was queued. A QEMU PoC queued jack_detect_work, simulated SDW_SLAVE_UNATTACHED,     and then entered remove. DEBUG_OBJECTS reported an active timer/work object associated with the rt700 jack     work path after remove skipped the cancel. This is sent as an RFC because the practical trigger depends on     SoundWire core remove ordering after an UNATTACHED status update. If remove cannot run after hw_init has     been cleared while jack work is still pending, this is a defensive lifecycle cleanup rather than a     reachable race on current systems. (CVE-2026-93185)

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

ID	Name	Product	Family	Type	Severity
373068	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793100968)	Nessus	Rocky Linux Local Security Checks	Local	high
373062	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1793100968)	Nessus	Alma Linux Local Security Checks	Local	high
366919	Debian dla-4841 : ata-modules-6.1.0-53-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
364688	AlmaLinux 9.2 [TuxCare] Security Update: bpftool / kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1791741836)	Nessus	Alma Linux Local Security Checks	Local	critical
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	Local	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
347546	Linux Distros Unpatched Vulnerability : CVE-2026-93185	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-93185

medium

Tenable Plugins

high

high

high

critical

high

high

high

medium