CVE-2026-98420 - ksmbd: follow SMB2 session expiration semantics
CVE ID :CVE-2026-98420
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: ksmbd: follow SMB2 session expiration semantics ksmbd_session_register() destroys valid sessions after ten seconds of inactivity whenever a client starts another SessionSetup exchange. This confuses Session.IdleTime with Session.ExpirationTime. Windows can create additional authenticated sessions on an existing connection, so deleting the older session invalidates its tree connects and makes mapped drives fail with STATUS_NETWORK_NAME_DELETED. The session expiration rules require the server to change a valid session to expired only after its credential expiration time passes. A valid or expired session otherwise keeps its connection from being scavenged. Connections that have not negotiated a dialect, have no sessions, or have only InProgress sessions are disconnected after an implementation-specific timeout. Use the Windows-compatible 45 second value and run the expiration check periodically for both TCP and SMB Direct. Keep zero as an infinite credential expiration time, and count each Valid-to-Expired transition. Set expired sessions to InProgress when they reauthenticate. If authentication fails, remove the session from the global and per-connection tables immediately, including SMB3 multichannel connections. Retain protection against abandoned SessionId-zero exchanges by allowing only one InProgress authentication per connection. Additional exchanges fail with STATUS_INSUFFICIENT_RESOURCES, and stale InProgress sessions are reaped after the same 45 second setup timeout. This bounds the original unauthenticated memory-exhaustion path without evicting established sessions.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98420
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: ksmbd: follow SMB2 session expiration semantics ksmbd_session_register() destroys valid sessions after ten seconds of inactivity whenever a client starts another SessionSetup exchange. This confuses Session.IdleTime with Session.ExpirationTime. Windows can create additional authenticated sessions on an existing connection, so deleting the older session invalidates its tree connects and makes mapped drives fail with STATUS_NETWORK_NAME_DELETED. The session expiration rules require the server to change a valid session to expired only after its credential expiration time passes. A valid or expired session otherwise keeps its connection from being scavenged. Connections that have not negotiated a dialect, have no sessions, or have only InProgress sessions are disconnected after an implementation-specific timeout. Use the Windows-compatible 45 second value and run the expiration check periodically for both TCP and SMB Direct. Keep zero as an infinite credential expiration time, and count each Valid-to-Expired transition. Set expired sessions to InProgress when they reauthenticate. If authentication fails, remove the session from the global and per-connection tables immediately, including SMB3 multichannel connections. Retain protection against abandoned SessionId-zero exchanges by allowing only one InProgress authentication per connection. Additional exchanges fail with STATUS_INSUFFICIENT_RESOURCES, and stale InProgress sessions are reaped after the same 45 second setup timeout. This bounds the original unauthenticated memory-exhaustion path without evicting established sessions.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98421 - wifi: mac80211: require a peer station for TDLS setup confirm
CVE ID :CVE-2026-98421
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: require a peer station for TDLS setup confirm It's nonsense for the setup confirm to go to station that doesn't even exist, and it hits a warning when building the frame: WARN_ON_ONCE(!sta || !ap_sta) Only accept WLAN_TDLS_SETUP_CONFIRM when the station is already there as a TDLS station. Need to copy the call to ieee80211_tdls_prep_mgmt_packet() since the existing WLAN_TDLS_DISCOVERY_REQUEST already falls through to it.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98421
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: require a peer station for TDLS setup confirm It's nonsense for the setup confirm to go to station that doesn't even exist, and it hits a warning when building the frame: WARN_ON_ONCE(!sta || !ap_sta) Only accept WLAN_TDLS_SETUP_CONFIRM when the station is already there as a TDLS station. Need to copy the call to ieee80211_tdls_prep_mgmt_packet() since the existing WLAN_TDLS_DISCOVERY_REQUEST already falls through to it.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98422 - wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown
CVE ID :CVE-2026-98422
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same AP_VLAN up again will increment the counter again and eventually hit the sanity check: WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt != master->crypto_tx_tailroom_needed_cnt); Reset it on ifdown to avoid that.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98422
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same AP_VLAN up again will increment the counter again and eventually hit the sanity check: WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt != master->crypto_tx_tailroom_needed_cnt); Reset it on ifdown to avoid that.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98423 - wifi: mac80211_hwsim: don't hand frames to mac80211 while stopping
CVE ID :CVE-2026-98423
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: don't hand frames to mac80211 while stopping The code checks ->started for frames coming from wmediumd, but the radio can be stopped after the check and before frame delivery, causing mac80211 to hit the WARN_ON(!local->started). Expand the mutex for this case and synchronise against it when the radio is stopped to avoid being able to hit the warning with hwsim. Drop the error print that would've complicated the error path, it only triggers for allocation failures (already noisy) and malformed frames anyway.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98423
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211_hwsim: don't hand frames to mac80211 while stopping The code checks ->started for frames coming from wmediumd, but the radio can be stopped after the check and before frame delivery, causing mac80211 to hit the WARN_ON(!local->started). Expand the mutex for this case and synchronise against it when the radio is stopped to avoid being able to hit the warning with hwsim. Drop the error print that would've complicated the error path, it only triggers for allocation failures (already noisy) and malformed frames anyway.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98424 - wifi: cfg80211: undo netns switch if renaming the wiphy fails
CVE ID :CVE-2026-98424
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: undo netns switch if renaming the wiphy fails Once all the interfaces have been moved, cfg80211_switch_netns() moves the wiphy itself by setting its network namespace and then renaming it, which makes sysfs move it. The rename can fail (but only on allocation failures), leaving things mixed up and hitting the warning there. Ignoring it isn't great, undo the move and let the change fail in this case. If undo fails then WARN, then things would again be stuck in two different network namespaces.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98424
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: undo netns switch if renaming the wiphy fails Once all the interfaces have been moved, cfg80211_switch_netns() moves the wiphy itself by setting its network namespace and then renaming it, which makes sysfs move it. The rename can fail (but only on allocation failures), leaving things mixed up and hitting the warning there. Ignoring it isn't great, undo the move and let the change fail in this case. If undo fails then WARN, then things would again be stuck in two different network namespaces.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98425 - wifi: mac80211: don't warn when an IBSS has no channel to scan
CVE ID :CVE-2026-98425
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't warn when an IBSS has no channel to scan ieee80211_request_ibss_scan() warns when regulatory leaves no allowed channel, but that can happen as the regdomain can change while IBSS is operating, and it can continue to operate briefly during the 60s grace period until it's shut down. Just remove the warning in this case.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98425
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't warn when an IBSS has no channel to scan ieee80211_request_ibss_scan() warns when regulatory leaves no allowed channel, but that can happen as the regdomain can change while IBSS is operating, and it can continue to operate briefly during the 60s grace period until it's shut down. Just remove the warning in this case.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98426 - wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path
CVE ID :CVE-2026-98426
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path 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. free_irq() matches on (irq, dev_id), so 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. Use &card->msix_ctx[j].
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98426
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: fix IRQ leak using wrong index in MSI-X error path 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. free_irq() matches on (irq, dev_id), so 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. Use &card->msix_ctx[j].
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98427 - net/sched: codel: bound the dropping loop per dequeue call
CVE ID :CVE-2026-98427
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: net/sched: codel: bound the dropping loop per dequeue call The CoDel control law schedules the next drop one interval/sqrt(count) after the previous drop, using the configured interval (codel_params.interval). For very small intervals the scheduled step rounds down to zero, so the dropping loop in codel_dequeue() never advances and drains the entire backlog under the qdisc lock in one call - an unprivileged user can trigger a soft lockup this way. Fix in the shared codel code used by both codel and fq_codel: 1. Make the control-law step at least 1 tick so the dropping loop always moves forward. 2. Cap the dropping loop at CODEL_MAX_DROPS_PER_DEQUEUE (256) drops per codel_dequeue() call, resyncing drop_next to now when the cap is hit: the catch-up owed to the loop grows with the idle gap and the backlog, which no interval threshold can bound. This is a deliberate behaviour change after long idle gaps. The cap applies to fq_codel (4b549a2ef4be) and the mac80211 TXQ path (fixed interval, cap only). The target sojourn delay (codel_params.target) is not validated: it does not feed the control law, so a sub-tick value is aggressive rather than deadlock-prone. Conditions to recreate the bug: - tc qdisc add dev lo root handle 1: tbf rate 1kbit burst 2kb limit 1000000 - tc qdisc add dev lo parent 1:1 handle 10: codel interval 2us target 1ms noecn limit 1000000 (same for fq_codel) - unpatched kernel: tc accepts it; a UDP flood under the 1kbit tbf soft-lockups (watchdog: BUG: soft lockup) while one codel_dequeue() call drops the backlog under the qdisc lock - patched kernel: same setup, at most 256 drops per dequeue call, no soft lockup Testing: claim reproducer and interval 2us/3us variants run clean; tdc qdisc category passes (see the selftests patch).
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98427
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: net/sched: codel: bound the dropping loop per dequeue call The CoDel control law schedules the next drop one interval/sqrt(count) after the previous drop, using the configured interval (codel_params.interval). For very small intervals the scheduled step rounds down to zero, so the dropping loop in codel_dequeue() never advances and drains the entire backlog under the qdisc lock in one call - an unprivileged user can trigger a soft lockup this way. Fix in the shared codel code used by both codel and fq_codel: 1. Make the control-law step at least 1 tick so the dropping loop always moves forward. 2. Cap the dropping loop at CODEL_MAX_DROPS_PER_DEQUEUE (256) drops per codel_dequeue() call, resyncing drop_next to now when the cap is hit: the catch-up owed to the loop grows with the idle gap and the backlog, which no interval threshold can bound. This is a deliberate behaviour change after long idle gaps. The cap applies to fq_codel (4b549a2ef4be) and the mac80211 TXQ path (fixed interval, cap only). The target sojourn delay (codel_params.target) is not validated: it does not feed the control law, so a sub-tick value is aggressive rather than deadlock-prone. Conditions to recreate the bug: - tc qdisc add dev lo root handle 1: tbf rate 1kbit burst 2kb limit 1000000 - tc qdisc add dev lo parent 1:1 handle 10: codel interval 2us target 1ms noecn limit 1000000 (same for fq_codel) - unpatched kernel: tc accepts it; a UDP flood under the 1kbit tbf soft-lockups (watchdog: BUG: soft lockup) while one codel_dequeue() call drops the backlog under the qdisc lock - patched kernel: same setup, at most 256 drops per dequeue call, no soft lockup Testing: claim reproducer and interval 2us/3us variants run clean; tdc qdisc category passes (see the selftests patch).
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98428 - ALSA: usb: 6fire: Avoid embedded URBs
CVE ID :CVE-2026-98428
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: ALSA: usb: 6fire: Avoid embedded URBs The USB 6fire driver uses URBs embedded in different structs for PCM, MIDI and communication, and this is basically a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. For addressing the problem, this patch converts those embedded URBs to ones that are properly allocated via usb_alloc_urb(). The pcm_urb.packets[] is gone, as it's allocated by usb_alloc_urb(), hence it's found in urb.iso_frame_desc[] instead. The conversions are rather straightforward; each embedded struct urb is changed to a pointer, and its callers are updated accordingly. The resource for those structs are released in the common destructor functions (usb6fire_comm_free(), etc), which are called at both the init error path and the disconnect. No functional changes, only compile-tested.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98428
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: ALSA: usb: 6fire: Avoid embedded URBs The USB 6fire driver uses URBs embedded in different structs for PCM, MIDI and communication, and this is basically a buggy implementation nowadays; since a URB is managed with a refcount, this may lead to a UAF when the URB is released asynchronously. For addressing the problem, this patch converts those embedded URBs to ones that are properly allocated via usb_alloc_urb(). The pcm_urb.packets[] is gone, as it's allocated by usb_alloc_urb(), hence it's found in urb.iso_frame_desc[] instead. The conversions are rather straightforward; each embedded struct urb is changed to a pointer, and its callers are updated accordingly. The resource for those structs are released in the common destructor functions (usb6fire_comm_free(), etc), which are called at both the init error path and the disconnect. No functional changes, only compile-tested.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98429 - RDMA/efa: Keep EQ resources alive while IRQ is registered
CVE ID :CVE-2026-98429
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Keep EQ resources alive while IRQ is registered The 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. Initialize the EQ without arming it, register the IRQ, and then arm it. Reverse the resource order during teardown by freeing the IRQ before destroying the EQ.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98429
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Keep EQ resources alive while IRQ is registered The 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. Initialize the EQ without arming it, register the IRQ, and then arm it. Reverse the resource order during teardown by freeing the IRQ before destroying the EQ.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98430 - RDMA/efa: Keep admin queues alive while IRQ is registered
CVE ID :CVE-2026-98430
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Keep admin queues alive while IRQ is registered The 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. Initialize the queues with interrupts masked, request the IRQ, and then switch to interrupt mode. On removal, reset the device and free the IRQ before destroying the queues. Also reset the device before destroying the queues if IRQ registration fails, because the device already has their DMA addresses.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98430
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :In the Linux kernel, the following vulnerability has been resolved: RDMA/efa: Keep admin queues alive while IRQ is registered The 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. Initialize the queues with interrupts masked, request the IRQ, and then switch to interrupt mode. On removal, reset the device and free the IRQ before destroying the queues. Also reset the device before destroying the queues if IRQ registration fails, because the device already has their DMA addresses.
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-98431 - RDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency
CVE ID :CVE-2026-98431
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :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---
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-98431
Published : Oct. 14, 2026, 2:17 p.m. | 26 minutes ago
Description :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---
Severity: 0.0 | NA
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-86846 - Dpdk: dpdk: guest can trigger out-of-bounds write by controlling avail ring index in vhost-crypto
CVE ID :CVE-2026-86846
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :A flaw was found in DPDK lib/vhost vhost-crypto. A guest can supply an avail-ring descriptor index that is used without bounds checking, causing an out-of-bounds write in the host vhost-crypto backend.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-86846
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :A flaw was found in DPDK lib/vhost vhost-crypto. A guest can supply an avail-ring descriptor index that is used without bounds checking, causing an out-of-bounds write in the host vhost-crypto backend.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-86847 - Dpdk: dpdk: guest can trigger infinite loop in vhost-crypto writeback chain cleanup
CVE ID :CVE-2026-86847
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :A flaw was found in DPDK lib/vhost vhost-crypto. Write-back chain cleanup can follow an uninitialized next pointer when mapping a guest descriptor fails, causing the host vhost-crypto process to hang or crash.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-86847
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :A flaw was found in DPDK lib/vhost vhost-crypto. Write-back chain cleanup can follow an uninitialized next pointer when mapping a guest descriptor fails, causing the host vhost-crypto process to hang or crash.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-86848 - Dpdk: dpdk: time-of-check/time-of-use vulnerability allowing guest-triggered out-of-bounds write in vhost-crypto
CVE ID :CVE-2026-86848
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :A flaw was found in DPDK lib/vhost vhost-crypto. The indirect-descriptor snapshot double-fetches a guest descriptor next index, allowing a malicious guest to cause an out-of-bounds access in the host backend.
Severity: 8.8 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-86848
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :A flaw was found in DPDK lib/vhost vhost-crypto. The indirect-descriptor snapshot double-fetches a guest descriptor next index, allowing a malicious guest to cause an out-of-bounds access in the host backend.
Severity: 8.8 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-86849 - Dpdk: dpdk: integer overflow combined with missing validation leads to host buffer overflow in vhost-crypto
CVE ID :CVE-2026-86849
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :A flaw was found in DPDK lib/vhost vhost-crypto. Integer overflow in chain length checks, and missing length checks on the RSA path, can overflow a host buffer in the vhost-crypto backend.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-86849
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :A flaw was found in DPDK lib/vhost vhost-crypto. Integer overflow in chain length checks, and missing length checks on the RSA path, can overflow a host buffer in the vhost-crypto backend.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-86856 - Dpdk: dpdk: stack and heap buffer overflow in nfp vdpa driver
CVE ID :CVE-2026-86856
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :A flaw was found in the DPDK nfp vDPA driver. Stack and heap buffers sized for a single queue pair can be overflowed when more virtqueues are configured, leading to a host crash or memory corruption.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-86856
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :A flaw was found in the DPDK nfp vDPA driver. Stack and heap buffers sized for a single queue pair can be overflowed when more virtqueues are configured, leading to a host crash or memory corruption.
Severity: 6.5 | MEDIUM
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-88164 - Microsoft Office SharePoint Elevation of Privilege Vulnerability
CVE ID :CVE-2026-88164
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :Missing authorization in Microsoft Office SharePoint allows an authorized attacker to elevate privileges over a network.
Severity: 8.8 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-88164
Published : Oct. 14, 2026, 6:19 p.m. | 26 minutes ago
Description :Missing authorization in Microsoft Office SharePoint allows an authorized attacker to elevate privileges over a network.
Severity: 8.8 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-92150 - F´: GenericHub Malformed Buffer Assertion DoS
CVE ID :CVE-2026-92150
Published : Oct. 14, 2026, 6:19 p.m. | 25 minutes ago
Description :F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. Prior to 4.2.0, Svc::GenericHub fromBufferDriver_handler deserialization is vulnerable because the receive handler uses FW_ASSERT for externally influenced deserialization status and type validation and permits a command payload size subtraction to underflow. When an unauthenticated inter-processor hub peer sends a truncated buffer, an invalid HubType, or a header-only command-dispatch payload, malformed hub traffic aborts or resets the process, causing denial of service. This issue is fixed in version 4.2.0.
Severity: 7.5 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-92150
Published : Oct. 14, 2026, 6:19 p.m. | 25 minutes ago
Description :F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. Prior to 4.2.0, Svc::GenericHub fromBufferDriver_handler deserialization is vulnerable because the receive handler uses FW_ASSERT for externally influenced deserialization status and type validation and permits a command payload size subtraction to underflow. When an unauthenticated inter-processor hub peer sends a truncated buffer, an invalid HubType, or a header-only command-dispatch payload, malformed hub traffic aborts or resets the process, causing denial of service. This issue is fixed in version 4.2.0.
Severity: 7.5 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-92152 - F´: Unvalidated Port Index in GenericHub
CVE ID :CVE-2026-92152
Published : Oct. 14, 2026, 6:19 p.m. | 25 minutes ago
Description :F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. From 4.1.0 until 4.2.0, Svc::GenericHub output-port dispatch is vulnerable because the deserialized port field is passed to serialOut_out, bufferOut_out, eventOut_out, or tlmOut_out without an explicit range check. When a remote hub packet supplies a port index outside the configured output-port array, assert-enabled builds abort, while builds without assertions can access an output-port array out of bounds, corrupt heap memory, and potentially allow remote code execution. This issue is fixed in version 4.2.0.
Severity: 9.3 | CRITICAL
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-92152
Published : Oct. 14, 2026, 6:19 p.m. | 25 minutes ago
Description :F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. From 4.1.0 until 4.2.0, Svc::GenericHub output-port dispatch is vulnerable because the deserialized port field is passed to serialOut_out, bufferOut_out, eventOut_out, or tlmOut_out without an explicit range check. When a remote hub packet supplies a port index outside the configured output-port array, assert-enabled builds abort, while builds without assertions can access an output-port array out of bounds, corrupt heap memory, and potentially allow remote code execution. This issue is fixed in version 4.2.0.
Severity: 9.3 | CRITICAL
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE-2026-92154 - F´: File size bounds bypass in Svc::FileUplink via unsigned integer overflow in DATA packet validation
CVE ID :CVE-2026-92154
Published : Oct. 14, 2026, 6:19 p.m. | 25 minutes ago
Description :F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. Prior to 4.2.0, Svc::FileUplink handleDataPacket offset and size validation is vulnerable because the component checks byteOffset plus dataSize with wrapping U32 arithmetic and then seeks to the large attacker-controlled offset before writing. When a file-uplink DATA packet supplies a byteOffset and dataSize whose unsigned sum wraps below the declared file size, data can be written beyond the declared upload size, causing file integrity loss and potentially large sparse-file growth or resource exhaustion. This issue is fixed in version 4.2.0.
Severity: 8.1 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...
CVE ID :CVE-2026-92154
Published : Oct. 14, 2026, 6:19 p.m. | 25 minutes ago
Description :F´ (F Prime) is a framework that enables development and deployment of spaceflight and other embedded software applications. Prior to 4.2.0, Svc::FileUplink handleDataPacket offset and size validation is vulnerable because the component checks byteOffset plus dataSize with wrapping U32 arithmetic and then seeks to the large attacker-controlled offset before writing. When a file-uplink DATA packet supplies a byteOffset and dataSize whose unsigned sum wraps below the declared file size, data can be written beyond the declared upload size, causing file integrity loss and potentially large sparse-file growth or resource exhaustion. This issue is fixed in version 4.2.0.
Severity: 8.1 | HIGH
Visit the link for more details, such as CVSS details, affected products, timeline, and more...