In the Linux kernel, the following vulnerability has been resolved: ALSA: usb: Fix UAF at delayed release of MIDI2 EPs The recent fix for UAF in ump_to_endpoint() caused another UAF because it tries to dereference the UMP endpoint object, but this might be executed at a delayed context where the endpoint has been already released. Add private_free to clear the associated data for avoiding the further dereference for delayed releases.

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

  - In the Linux kernel, the following vulnerability has been resolved: kunit: Fix potential null dereference     in kunit_device_driver_test() kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL     check may lead to NULL dereference. Add a NULL check for test_state. (CVE-2024-56773)

  - In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: fix partial SETREGSET     for NT_ARM_FPMR Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable, and a SETREGSET     call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written     back to target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from the kernel stack. The     read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. Fix     this by initializing the temporary value before copying the regset from userspace, as for other regsets     (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing     contents of FPMR will be retained. Before this patch: | # ./fpmr-test | Attempting to write     NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read     NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d     | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | |     Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr =     0xffff800083963d50 After this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr =     0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr |     GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to     write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read     NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d     (CVE-2024-57878)

  - In the Linux kernel, the following vulnerability has been resolved: mptcp: fix 'scheduling while atomic'     in mptcp_pm_nl_append_new_local_addr If multiple connection requests attempt to create an implicit mptcp     endpoint in parallel, more than one caller may end up in mptcp_pm_nl_append_new_local_addr because none     found the address in local_addr_list during their call to mptcp_pm_nl_get_local_id. In this case, the     concurrent new_local_addr calls may delete the address entry created by the previous caller. These deletes     use synchronize_rcu, but this is not permitted in some of the contexts where this function may be called.
    During packet recv, the caller may be in a rcu read critical section and have preemption disabled. An     example stack: BUG: scheduling while atomic: swapper/2/0/0x00000302 Call Trace: <IRQ> dump_stack_lvl     (lib/dump_stack.c:117 (discriminator 1)) dump_stack (lib/dump_stack.c:124) __schedule_bug     (kernel/sched/core.c:5943) schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33     kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207     kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84     kernel/sched/core.c:6804 kernel/sched/core.c:6818) schedule_timeout (kernel/time/timer.c:2160)     wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116     kernel/sched/completion.c:127 kernel/sched/completion.c:148) __wait_rcu_gp (include/linux/rcupdate.h:311     kernel/rcu/update.c:444) synchronize_rcu (kernel/rcu/tree.c:3609) mptcp_pm_nl_append_new_local_addr     (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id     (net/mptcp/pm_netlink.c:1164) mptcp_pm_get_local_id (net/mptcp/pm.c:420) subflow_check_req     (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflow_v4_route_req (net/mptcp/subflow.c:305)     tcp_conn_request (net/ipv4/tcp_input.c:7216) subflow_v4_conn_request (net/mptcp/subflow.c:651)     tcp_rcv_state_process (net/ipv4/tcp_input.c:6709) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934) tcp_v4_rcv     (net/ipv4/tcp_ipv4.c:2334) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))     ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver     (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)     ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580) ip_sublist_rcv     (net/ipv4/ip_input.c:640) ip_list_rcv (net/ipv4/ip_input.c:675) __netif_receive_skb_list_core     (net/core/dev.c:5583 net/core/dev.c:5631) netif_receive_skb_list_internal (net/core/dev.c:5685     net/core/dev.c:5774) napi_complete_done (include/linux/list.h:37 include/net/gro.h:449     include/net/gro.h:444 net/core/dev.c:6114) igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
    __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787) handle_softirqs     (kernel/softirq.c:553) __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)     irq_exit_rcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ>     This problem seems particularly prevalent if the user advertises an endpoint that has a different external     vs internal address. In the case where the external address is advertised and multiple connections already     exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the     first local_addr_list entries which have the internal address instead. Fix by skipping the replacement of     an existing implicit local address if called via mptcp_pm_nl_get_local_id. (CVE-2025-21938)

  - In the Linux kernel, the following vulnerability has been resolved: devlink: fix xa_alloc_cyclic() error     handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will     cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking     if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
    (CVE-2025-22017)

  - In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path     of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence     and then return. The code is waiting on m->fence which could be the local fence but this is only stable     under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit     762b7e95362170b3e13a8704f38d5e47eca4ba74) (CVE-2025-37869)

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

  - In the Linux kernel, the following vulnerability has been resolved: kunit: Fix potential null dereference     in kunit_device_driver_test() kunit_kzalloc() may return a NULL pointer, dereferencing it without NULL     check may lead to NULL dereference. Add a NULL check for test_state. (CVE-2024-56773)

  - In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: fix partial SETREGSET     for NT_ARM_FPMR Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable, and a SETREGSET     call with a length of zero will leave this uninitialized. Consequently an arbitrary value will be written     back to target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from the kernel stack. The     read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. Fix     this by initializing the temporary value before copying the regset from userspace, as for other regsets     (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing     contents of FPMR will be retained. Before this patch: | # ./fpmr-test | Attempting to write     NT_ARM_FPMR::fpmr = 0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read     NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d     | | Attempting to write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | |     Attempting to read NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr =     0xffff800083963d50 After this patch: | # ./fpmr-test | Attempting to write NT_ARM_FPMR::fpmr =     0x900d900d900d900d | SETREGSET(nt=0x40e, len=8) wrote 8 bytes | | Attempting to read NT_ARM_FPMR::fpmr |     GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d | | Attempting to     write NT_ARM_FPMR (zero length) | SETREGSET(nt=0x40e, len=0) wrote 0 bytes | | Attempting to read     NT_ARM_FPMR::fpmr | GETREGSET(nt=0x40e, len=8) read 8 bytes | Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d     (CVE-2024-57878)

  - In the Linux kernel, the following vulnerability has been resolved: mptcp: fix 'scheduling while atomic'     in mptcp_pm_nl_append_new_local_addr If multiple connection requests attempt to create an implicit mptcp     endpoint in parallel, more than one caller may end up in mptcp_pm_nl_append_new_local_addr because none     found the address in local_addr_list during their call to mptcp_pm_nl_get_local_id. In this case, the     concurrent new_local_addr calls may delete the address entry created by the previous caller. These deletes     use synchronize_rcu, but this is not permitted in some of the contexts where this function may be called.
    During packet recv, the caller may be in a rcu read critical section and have preemption disabled. An     example stack: BUG: scheduling while atomic: swapper/2/0/0x00000302 Call Trace: <IRQ> dump_stack_lvl     (lib/dump_stack.c:117 (discriminator 1)) dump_stack (lib/dump_stack.c:124) __schedule_bug     (kernel/sched/core.c:5943) schedule_debug.constprop.0 (arch/x86/include/asm/preempt.h:33     kernel/sched/core.c:5970) __schedule (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:207     kernel/sched/features.h:29 kernel/sched/core.c:6621) schedule (arch/x86/include/asm/preempt.h:84     kernel/sched/core.c:6804 kernel/sched/core.c:6818) schedule_timeout (kernel/time/timer.c:2160)     wait_for_completion (kernel/sched/completion.c:96 kernel/sched/completion.c:116     kernel/sched/completion.c:127 kernel/sched/completion.c:148) __wait_rcu_gp (include/linux/rcupdate.h:311     kernel/rcu/update.c:444) synchronize_rcu (kernel/rcu/tree.c:3609) mptcp_pm_nl_append_new_local_addr     (net/mptcp/pm_netlink.c:966 net/mptcp/pm_netlink.c:1061) mptcp_pm_nl_get_local_id     (net/mptcp/pm_netlink.c:1164) mptcp_pm_get_local_id (net/mptcp/pm.c:420) subflow_check_req     (net/mptcp/subflow.c:98 net/mptcp/subflow.c:213) subflow_v4_route_req (net/mptcp/subflow.c:305)     tcp_conn_request (net/ipv4/tcp_input.c:7216) subflow_v4_conn_request (net/mptcp/subflow.c:651)     tcp_rcv_state_process (net/ipv4/tcp_input.c:6709) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1934) tcp_v4_rcv     (net/ipv4/tcp_ipv4.c:2334) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))     ip_local_deliver_finish (include/linux/rcupdate.h:813 net/ipv4/ip_input.c:234) ip_local_deliver     (include/linux/netfilter.h:314 include/linux/netfilter.h:308 net/ipv4/ip_input.c:254)     ip_sublist_rcv_finish (include/net/dst.h:461 net/ipv4/ip_input.c:580) ip_sublist_rcv     (net/ipv4/ip_input.c:640) ip_list_rcv (net/ipv4/ip_input.c:675) __netif_receive_skb_list_core     (net/core/dev.c:5583 net/core/dev.c:5631) netif_receive_skb_list_internal (net/core/dev.c:5685     net/core/dev.c:5774) napi_complete_done (include/linux/list.h:37 include/net/gro.h:449     include/net/gro.h:444 net/core/dev.c:6114) igb_poll (drivers/net/ethernet/intel/igb/igb_main.c:8244) igb
    __napi_poll (net/core/dev.c:6582) net_rx_action (net/core/dev.c:6653 net/core/dev.c:6787) handle_softirqs     (kernel/softirq.c:553) __irq_exit_rcu (kernel/softirq.c:588 kernel/softirq.c:427 kernel/softirq.c:636)     irq_exit_rcu (kernel/softirq.c:651) common_interrupt (arch/x86/kernel/irq.c:247 (discriminator 14)) </IRQ>     This problem seems particularly prevalent if the user advertises an endpoint that has a different external     vs internal address. In the case where the external address is advertised and multiple connections already     exist, multiple subflow SYNs arrive in parallel which tends to trigger the race during creation of the     first local_addr_list entries which have the internal address instead. Fix by skipping the replacement of     an existing implicit local address if called via mptcp_pm_nl_get_local_id. (CVE-2025-21938)

  - In the Linux kernel, the following vulnerability has been resolved: devlink: fix xa_alloc_cyclic() error     handling In case of returning 1 from xa_alloc_cyclic() (wrapping) ERR_PTR(1) will be returned, which will     cause IS_ERR() to be false. Which can lead to dereference not allocated pointer (rel). Fix it by checking     if err is lower than zero. This wasn't found in real usecase, only noticed. Credit to Pierre.
    (CVE-2025-22017)

  - In the Linux kernel, the following vulnerability has been resolved: drm/xe: Use local fence in error path     of xe_migrate_clear The intent of the error path in xe_migrate_clear is to wait on locally generated fence     and then return. The code is waiting on m->fence which could be the local fence but this is only stable     under the job mutex leading to a possible UAF. Fix code to wait on local fence. (cherry picked from commit     762b7e95362170b3e13a8704f38d5e47eca4ba74) (CVE-2025-37869)

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: ALSA: usb: Fix UAF at delayed release     of MIDI2 EPs The recent fix for UAF in ump_to_endpoint() caused another UAF because it tries to     dereference the UMP endpoint object, but this might be executed at a delayed context where the endpoint     has been already released. Add private_free to clear the associated data for avoiding the further     dereference for delayed releases. (CVE-2026-74642)

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

ID	Name	Product	Family	Type	Severity
364689	AlmaLinux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1791800936)	Nessus	Alma Linux Local Security Checks	Local	high
364682	Rocky Linux 9.6 [TuxCare] Security Update: kernel / kernel-64k / kernel-64k-core / kernel-64k-debug / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1791800936)	Nessus	Rocky Linux Local Security Checks	Local	high
364137	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500374)	Nessus	Oracle Linux Local Security Checks	Local	high
343049	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-500248)	Nessus	Oracle Linux Local Security Checks	Local	high
338927	Linux Distros Unpatched Vulnerability : CVE-2026-74642	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-74642

medium

Tenable Plugins

high

high

high

high

medium