CVE-2026-98431
UnknownSummary
The Linux kernel contains an ABBA deadlock between the mmap_lock and disassociation_lock in the RDMA/uverbs subsystem. A thread performing mmap/fork acquires locks in the order mmap_lock → disassociation_lock, while the thread executing uverbs_user_mmap_disassociate() acquires them in reverse order, leading to a potential deadlock. The issue was resolved by removing disassociation_lock and using the existing hw_destroy_rwsem instead.
Risk Assessment
A kernel deadlock can cause processes or the entire system to hang, especially during mmap/fork operations on RDMA devices and device removal. In production environments this may result in service unavailability and require a server restart.
Recommendation
Update the Linux kernel to a version containing the fix for CVE-2026-98431 (the commit that removes disassociation_lock and uses hw_destroy_rwsem). Until the update is applied, consider limiting mmap/fork operations on RDMA devices and monitor the system for lockdep warnings.
Other vulnerabilities in Linux kernel
See all- CVE-2026-98430Unknown
In the Linux kernel, the RDMA/efa management IRQ handler accesses both the admin completion queue and the async event queue. The driver registered the IRQ before constructing these queues and destroyed them before freeing the IRQ, so the handler's lifetime was not contained by the resources it accesses. The fix initializes the queues with interrupts masked, requests the IRQ, then switches to interrupt mode, and on removal resets the device and frees the IRQ before destroying the queues.
- CVE-2026-98429Unknown
In the Linux kernel, the RDMA/efa completion IRQ handler accesses the EQ state and DMA buffer. Its IRQ was registered before that state was initialized, while teardown released the buffer before free_irq() synchronized the handler. The fix initializes the EQ without arming it, registers the IRQ, then arms it, and reverses the resource order during teardown by freeing the IRQ before destroying the EQ.
- CVE-2026-98428Unknown
In the Linux kernel, the USB 6fire driver uses URBs embedded in different structs for PCM, MIDI and communication, which is a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. The fix converts those embedded URBs to ones properly allocated via usb_alloc_urb(), changing each embedded struct urb to a pointer and updating callers; resources are released in common destructors called at both the init error path and disconnect.
- CVE-2026-98427Unknown
In the Linux kernel, the CoDel scheduler's dropping loop in codel_dequeue() could fail to advance with very small interval values, draining the entire backlog under the qdisc lock in a single call. An unprivileged user could trigger a soft lockup this way. The fix ensures the control-law step is at least 1 tick and caps the dropping loop at 256 drops per codel_dequeue() call.
- CVE-2026-98426Unknown
In the Linux kernel, the mwifiex wifi driver's mwifiex_pcie_request_irq() registers each MSI-X vector with a per-index dev_id (&card->msix_ctx[i]). On a request_irq() failure the cleanup loop "for (j = 0; j < i; j++)" frees msix_entries[j].vector but passes the failed index's &card->msix_ctx[i] as the dev_id. Since free_irq() matches on (irq, dev_id), it fails to find the action registered with &card->msix_ctx[j]: the already-requested IRQ j is not freed (leaked) and free_irq() warns about freeing a non-existent IRQ. The fix uses &card->msix_ctx[j].
- CVE-2026-98425Unknown
In the Linux kernel, ieee80211_request_ibss_scan() in mac80211 warns when the regulatory domain leaves no allowed channel to scan. This can happen because the regdomain can change while IBSS is operating, and IBSS can continue to operate briefly during the 60s grace period until it is shut down. The fix removes the warning in this case.
- CVE-2026-98424Unknown
In the Linux kernel, cfg80211_switch_netns() in cfg80211 moves all interfaces, then moves the wiphy itself by setting its network namespace and renaming it, which makes sysfs move it. The rename can fail (only on allocation failures), leaving things mixed up and hitting a warning. The fix undoes the move and lets the change fail, and if undo fails it WARNs.
- CVE-2026-98423Unknown
In the Linux kernel, mac80211_hwsim checks ->started for frames coming from wmediumd, but the radio can be stopped after the check and before frame delivery, causing mac80211 to hit WARN_ON(!local->started). The fix expands the mutex for this case and synchronizes against it when the radio is stopped, and drops an error print that complicated the error path.
- CVE-2026-98422Unknown
In the Linux kernel, mac80211 AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface on ifup, but it is never decremented unless the AP is also brought down. Bringing the same AP_VLAN up again increments the counter again and eventually hits the WARN_ON_ONCE sanity check. The fix resets it on ifdown.
- CVE-2026-98421Unknown
In the Linux kernel, mac80211 requires that a TDLS setup confirm (WLAN_TDLS_SETUP_CONFIRM) be sent to an existing TDLS station. Otherwise, building the frame hits WARN_ON_ONCE(!sta || !ap_sta). The fix only accepts WLAN_TDLS_SETUP_CONFIRM when the station already exists as a TDLS station.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency Commit 51976c6cd786 ("RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages") introduced disassociation_lock to protect new mmap registrations against uverbs_user_mmap_disassociate(), but created an ABBA deadlock: Thread A (mmap / fork): mmap_lock -> disassociation_lock Thread B (disassociate): disassociation_lock -> mmap_lock Fix by removing disassociation_lock entirely and using the pre-existing hw_destroy_rwsem instead. hw_destroy_rwsem already provides the same protection: rdma_umap_open() and ib_uverbs_mmap() both use down_read_trylock() before registering a new VMA, so holding hw_destroy_rwsem in uverbs_user_mmap_disassociate() is sufficient to block new registrations. trylock is used in both mmap paths (not blocking down_read) because mmap_lock is already held on entry, and uverbs_user_mmap_disassociate() acquires mmap_lock internally — a blocking read would recreate the same deadlock. The only caller that was not taking hw_destroy_rwsem for write was rdma_user_mmap_disassociate(). Fix it to take the rwsem per-ufile while iterating under lists_mutex. This is safe because ib_uverbs_close() releases hw_destroy_rwsem entirely before acquiring lists_mutex, so the two locks are never held simultaneously. lockdep warning: [ 776.654252] ====================================================== [ 776.655214] WARNING: possible circular locking dependency detected [ 776.656167] 6.18.0for-upstream_debug_94e244d9ccab #1 Not tainted [ 776.657114] ------------------------------------------------------ [ 776.658087] devlink/14824 is trying to acquire lock: [ 776.658879] ffff88811170c800 (&mm->mmap_lock){++++}-{4:4}, at: uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs] [ 776.660479] [ 776.660479] but task is already holding lock: [ 776.661460] ffff888142d92b08 (&file->disassociation_lock){+.+.}-{4:4}, at: uverbs_user_mmap_disassociate+0x39/0x780 [ib_uverbs] [ 776.663177] [ 776.663177] which lock already depends on the new lock. [ 776.663177] [ 776.664525] [ 776.664525] the existing dependency chain (in reverse order) is: [ 776.665724] [ 776.665724] -> #2 (&file->disassociation_lock){+.+.}-{4:4}: [ 776.666887] __mutex_lock+0x16d/0x2330 [ 776.667633] rdma_umap_open+0x129/0x280 [ib_uverbs] [ 776.668489] dup_mmap+0xa40/0x1790 [ 776.669170] copy_process+0x5dd2/0x6170 [ 776.669933] kernel_clone+0xb6/0x610 [ 776.670636] __do_sys_clone+0xb5/0xf0 [ 776.671354] do_syscall_64+0x70/0x12e0 [ 776.672083] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.672940] [ 776.672940] -> #1 (&mm->mmap_lock/1){+.+.}-{4:4}: [ 776.673985] down_write_nested+0x90/0x1e0 [ 776.674751] dup_mmap+0x201/0x1790 [ 776.675448] copy_process+0x5dd2/0x6170 [ 776.676180] kernel_clone+0xb6/0x610 [ 776.676904] __do_sys_clone+0xb5/0xf0 [ 776.677615] do_syscall_64+0x70/0x12e0 [ 776.678351] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 776.679239] [ 776.679239] -> #0 (&mm->mmap_lock){++++}-{4:4}: [ 776.680253] __lock_acquire+0x18c6/0x2ec0 [ 776.681018] lock_acquire+0x10e/0x2e0 [ 776.681742] down_read+0x95/0x430 [ 776.682395] uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs] [ 776.683436] uverbs_destroy_ufile_hw+0x1ae/0x270 [ib_uverbs] [ 776.684416] ib_uverbs_remove_one+0x22b/0x420 [ib_uverbs] [ 776.685371] remove_client_context+0xa6/0xf0 [ib_core] [ 776.686342] disable_device+0x12b/0x240 [ib_core] [ 776.687249] __ib_unregister_device+0x269/0x460 [ib_core] [ 776.688233] ib_unregister_device+0x21/0x30 [ib_core] [ 776.689140] mlx5r_remove+0xd0/0x170 [mlx5_ib] [ 776.689999] device_release_driver_internal+0x3b2/0x5 ---truncated---
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

