FKIE_CVE-2026-98431
Vulnerability from fkie_nvd - Published: 2026-10-14 14:17 - Updated: 2026-10-19 10:18
Severity
Summary
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---
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/infiniband/core/rdma_core.c",
"drivers/infiniband/core/uverbs_main.c",
"include/rdma/uverbs_types.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "426f54f20b79c5b164a0472ad3f6ba36afcd08c6",
"status": "affected",
"version": "51976c6cd786151b6a1bdf8b8b3334beac0ba99c",
"versionType": "git"
},
{
"lessThan": "a44a3f175eaee7e5aeb6a8fed381c4a0d5f49236",
"status": "affected",
"version": "51976c6cd786151b6a1bdf8b8b3334beac0ba99c",
"versionType": "git"
},
{
"status": "affected",
"version": "0598914a950ddfa694f410e482453cdbb9265515",
"versionType": "git"
},
{
"status": "affected",
"version": "86092a4e46d161d24f8106df082e24b8efe87382",
"versionType": "git"
},
{
"lessThan": "6.12",
"status": "affected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThan": "6.13",
"status": "affected",
"version": "6.12.2",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/infiniband/core/rdma_core.c",
"drivers/infiniband/core/uverbs_main.c",
"include/rdma/uverbs_types.h"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.13"
},
{
"lessThan": "6.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.3",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/uverbs: Fix mmap_lock/disassociation_lock circular dependency\n\nCommit 51976c6cd786 (\"RDMA/core: Provide rdma_user_mmap_disassociate()\nto disassociate mmap pages\") introduced disassociation_lock to protect\nnew mmap registrations against uverbs_user_mmap_disassociate(), but\ncreated an ABBA deadlock:\n\n Thread A (mmap / fork):\n mmap_lock -\u003e disassociation_lock\n\n Thread B (disassociate):\n disassociation_lock -\u003e mmap_lock\n\nFix by removing disassociation_lock entirely and using the pre-existing\nhw_destroy_rwsem instead. hw_destroy_rwsem already provides the same\nprotection: rdma_umap_open() and ib_uverbs_mmap() both use\ndown_read_trylock() before registering a new VMA, so holding hw_destroy_rwsem\nin uverbs_user_mmap_disassociate() is sufficient to block new registrations.\ntrylock is used in both mmap paths (not blocking down_read) because\nmmap_lock is already held on entry, and uverbs_user_mmap_disassociate()\nacquires mmap_lock internally \u2014 a blocking read would recreate the same\ndeadlock.\n\nThe only caller that was not taking hw_destroy_rwsem for write was\nrdma_user_mmap_disassociate(). Fix it to take the rwsem per-ufile while\niterating under lists_mutex. This is safe because ib_uverbs_close()\nreleases hw_destroy_rwsem entirely before acquiring lists_mutex, so the\ntwo locks are never held simultaneously.\n\nlockdep warning:\n\n [ 776.654252] ======================================================\n [ 776.655214] WARNING: possible circular locking dependency detected\n [ 776.656167] 6.18.0for-upstream_debug_94e244d9ccab #1 Not tainted\n [ 776.657114] ------------------------------------------------------\n [ 776.658087] devlink/14824 is trying to acquire lock:\n [ 776.658879] ffff88811170c800 (\u0026mm-\u003emmap_lock){++++}-{4:4}, at: uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs]\n [ 776.660479]\n [ 776.660479] but task is already holding lock:\n [ 776.661460] ffff888142d92b08 (\u0026file-\u003edisassociation_lock){+.+.}-{4:4}, at: uverbs_user_mmap_disassociate+0x39/0x780 [ib_uverbs]\n [ 776.663177]\n [ 776.663177] which lock already depends on the new lock.\n [ 776.663177]\n [ 776.664525]\n [ 776.664525] the existing dependency chain (in reverse order) is:\n [ 776.665724]\n [ 776.665724] -\u003e #2 (\u0026file-\u003edisassociation_lock){+.+.}-{4:4}:\n [ 776.666887] __mutex_lock+0x16d/0x2330\n [ 776.667633] rdma_umap_open+0x129/0x280 [ib_uverbs]\n [ 776.668489] dup_mmap+0xa40/0x1790\n [ 776.669170] copy_process+0x5dd2/0x6170\n [ 776.669933] kernel_clone+0xb6/0x610\n [ 776.670636] __do_sys_clone+0xb5/0xf0\n [ 776.671354] do_syscall_64+0x70/0x12e0\n [ 776.672083] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n [ 776.672940]\n [ 776.672940] -\u003e #1 (\u0026mm-\u003emmap_lock/1){+.+.}-{4:4}:\n [ 776.673985] down_write_nested+0x90/0x1e0\n [ 776.674751] dup_mmap+0x201/0x1790\n [ 776.675448] copy_process+0x5dd2/0x6170\n [ 776.676180] kernel_clone+0xb6/0x610\n [ 776.676904] __do_sys_clone+0xb5/0xf0\n [ 776.677615] do_syscall_64+0x70/0x12e0\n [ 776.678351] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n [ 776.679239]\n [ 776.679239] -\u003e #0 (\u0026mm-\u003emmap_lock){++++}-{4:4}:\n [ 776.680253] __lock_acquire+0x18c6/0x2ec0\n [ 776.681018] lock_acquire+0x10e/0x2e0\n [ 776.681742] down_read+0x95/0x430\n [ 776.682395] uverbs_user_mmap_disassociate+0x168/0x780 [ib_uverbs]\n [ 776.683436] uverbs_destroy_ufile_hw+0x1ae/0x270 [ib_uverbs]\n [ 776.684416] ib_uverbs_remove_one+0x22b/0x420 [ib_uverbs]\n [ 776.685371] remove_client_context+0xa6/0xf0 [ib_core]\n [ 776.686342] disable_device+0x12b/0x240 [ib_core]\n [ 776.687249] __ib_unregister_device+0x269/0x460 [ib_core]\n [ 776.688233] ib_unregister_device+0x21/0x30 [ib_core]\n [ 776.689140] mlx5r_remove+0xd0/0x170 [mlx5_ib]\n [ 776.689999] device_release_driver_internal+0x3b2/0x5\n---truncated---"
}
],
"id": "CVE-2026-98431",
"lastModified": "2026-10-19T10:18:49.857",
"metrics": {},
"published": "2026-10-14T14:17:54.887",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/426f54f20b79c5b164a0472ad3f6ba36afcd08c6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a44a3f175eaee7e5aeb6a8fed381c4a0d5f49236"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Received"
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.