FKIE_CVE-2026-98818
Vulnerability from fkie_nvd - Published: 2026-10-18 16:17 - Updated: 2026-10-19 10:19
Severity
Summary
In the Linux kernel, the following vulnerability has been resolved:
mm/slab: do not wake up kswapd in __kfree_rcu_sheaf()
Since kfree_rcu() can be called under pi_lock (a raw spinlock in the
scheduler), kfree_rcu() itself should never allocate memory with
__GFP_KSWAPD_RECLAIM as waking up kswapd ends up acquiring pi_lock,
which leads to a deadlock.
Reproducing the issue even intentionally was not straightforward.
The set_cpus_allowed_force() path that is called under pi_lock is
exercised very rarely, and competing tasks that allocate memory will
most likely wake kswapd up.
Therefore the existence of the deadlock was verified with a modified
kernel that has a lockdep map for waking up kswapd:
======================================================
WARNING: possible circular locking dependency detected
7.2.0-rc1-slab-for-next+ #10 Not tainted
------------------------------------------------------
git/6660 is trying to acquire lock:
ffff8e524533c550 (&p->pi_lock){-.-.}-{2:2}, at: _raw_spin_lock_irqsave+0x12/0x20
but task is already holding lock:
ffff8e57bffff1a0 (&pgdat->kswapd_wait){....}-{3:3}, at: _raw_spin_lock_irqsave+0x12/0x20
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&pgdat->kswapd_wait){....}-{3:3}:
__lock_acquire+0x5a4/0xc50
lock_acquire.part.0+0xb7/0x240
lock_acquire+0x70/0x170
__raw_spin_lock_irqsave+0x44/0x80
_raw_spin_lock_irqsave+0x12/0x20
__wake_up_common_lock+0x31/0xa0
__wake_up+0x20/0x40
kswapd_wakeup_wake+0x7e/0x110
wakeup_kswapd+0x295/0x320
wake_all_kswapds+0xac/0x1a0
__alloc_pages_slowpath.constprop.0+0x282/0xf80
__alloc_frozen_pages_noprof+0x32a/0x360
alloc_slab_page+0x2e/0x160
allocate_slab+0x82/0x420
new_slab+0x52/0xb0
refill_objects+0x13d/0x190
refill_sheaf+0x5d/0xd0
__pcs_replace_empty_main+0x230/0xb10
[...]
-> #1 (kswapd_wakeup){-.-.}-{0:0}:
__lock_acquire+0x5a4/0xc50
lock_sync.part.0+0x75/0x100
lock_sync+0x36/0x70
might_wakeup_kswapd+0x61/0xa0
__kfree_rcu_sheaf+0x33/0xd90
kvfree_call_rcu+0x1d4/0x3b0
set_cpus_allowed_force+0x163/0x220
cpuset_cpus_allowed_fallback+0x18b/0x240
select_fallback_rq+0x1e6/0x250
[...]
-> #0 (&p->pi_lock){-.-.}-{2:2}:
check_prev_add+0xe6/0xe00
validate_chain+0x51e/0x6e0
__lock_acquire+0x5a4/0xc50
lock_acquire.part.0+0xb7/0x240
lock_acquire+0x70/0x170
__raw_spin_lock_irqsave+0x44/0x80
_raw_spin_lock_irqsave+0x12/0x20
try_to_wake_up+0x77/0xa90
default_wake_function+0x27/0x60
autoremove_wake_function+0x23/0xb0
__wake_up_common+0xb8/0x170
__wake_up_common_lock+0x51/0xa0
__wake_up+0x20/0x40
kswapd_wakeup_wake+0x7e/0x110
wakeup_kswapd+0x295/0x320
wake_all_kswapds+0xac/0x1a0
__alloc_pages_slowpath.constprop.0+0x282/0xf80
__alloc_frozen_pages_noprof+0x32a/0x360
alloc_slab_page+0x2e/0x160
allocate_slab+0x82/0x420
new_slab+0x52/0xb0
refill_objects+0x13d/0x190
refill_sheaf+0x5d/0xd0
__pcs_replace_empty_main+0x230/0xb10
[...]
other info that might help us debug this:
Chain exists of:
&p->pi_lock --> kswapd_wakeup --> &pgdat->kswapd_wait
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&pgdat->kswapd_wait);
lock(kswapd_wakeup);
lock(&pgdat->kswapd_wait);
lock(&p->pi_lock);
*** DEADLOCK ***
3 locks held by git/6660:
#0: ffff8e519f0e9e20 (&type->i_mutex_dir_key#6){++++}-{4:4}, at: lookup_slow+0x2d/0x60
#1: ffffffff8a31c460 (kswapd_wakeup){-.-.}-
---truncated---
References
Impacted products
| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/slub.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "46545c86b54ffb969b6e3662942b4a6191619eaa",
"status": "affected",
"version": "ec66e0d599520ab414db745544e25d80d0ac5054",
"versionType": "git"
},
{
"lessThan": "af2fb3ee6679b517e2fdbd3ba16ec276a8b74312",
"status": "affected",
"version": "ec66e0d599520ab414db745544e25d80d0ac5054",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/slub.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.18"
},
{
"lessThan": "6.18",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "7.2.*",
"status": "unaffected",
"version": "7.2.10",
"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\nmm/slab: do not wake up kswapd in __kfree_rcu_sheaf()\n\nSince kfree_rcu() can be called under pi_lock (a raw spinlock in the\nscheduler), kfree_rcu() itself should never allocate memory with\n__GFP_KSWAPD_RECLAIM as waking up kswapd ends up acquiring pi_lock,\nwhich leads to a deadlock.\n\nReproducing the issue even intentionally was not straightforward.\nThe set_cpus_allowed_force() path that is called under pi_lock is\nexercised very rarely, and competing tasks that allocate memory will\nmost likely wake kswapd up.\n\nTherefore the existence of the deadlock was verified with a modified\nkernel that has a lockdep map for waking up kswapd:\n\n ======================================================\n WARNING: possible circular locking dependency detected\n 7.2.0-rc1-slab-for-next+ #10 Not tainted\n ------------------------------------------------------\n git/6660 is trying to acquire lock:\n ffff8e524533c550 (\u0026p-\u003epi_lock){-.-.}-{2:2}, at: _raw_spin_lock_irqsave+0x12/0x20\n\n but task is already holding lock:\n ffff8e57bffff1a0 (\u0026pgdat-\u003ekswapd_wait){....}-{3:3}, at: _raw_spin_lock_irqsave+0x12/0x20\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u003e #2 (\u0026pgdat-\u003ekswapd_wait){....}-{3:3}:\n __lock_acquire+0x5a4/0xc50\n lock_acquire.part.0+0xb7/0x240\n lock_acquire+0x70/0x170\n __raw_spin_lock_irqsave+0x44/0x80\n _raw_spin_lock_irqsave+0x12/0x20\n __wake_up_common_lock+0x31/0xa0\n __wake_up+0x20/0x40\n kswapd_wakeup_wake+0x7e/0x110\n wakeup_kswapd+0x295/0x320\n wake_all_kswapds+0xac/0x1a0\n __alloc_pages_slowpath.constprop.0+0x282/0xf80\n __alloc_frozen_pages_noprof+0x32a/0x360\n alloc_slab_page+0x2e/0x160\n allocate_slab+0x82/0x420\n new_slab+0x52/0xb0\n refill_objects+0x13d/0x190\n refill_sheaf+0x5d/0xd0\n __pcs_replace_empty_main+0x230/0xb10\n [...]\n\n -\u003e #1 (kswapd_wakeup){-.-.}-{0:0}:\n __lock_acquire+0x5a4/0xc50\n lock_sync.part.0+0x75/0x100\n lock_sync+0x36/0x70\n might_wakeup_kswapd+0x61/0xa0\n __kfree_rcu_sheaf+0x33/0xd90\n kvfree_call_rcu+0x1d4/0x3b0\n set_cpus_allowed_force+0x163/0x220\n cpuset_cpus_allowed_fallback+0x18b/0x240\n select_fallback_rq+0x1e6/0x250\n\t [...]\n\n -\u003e #0 (\u0026p-\u003epi_lock){-.-.}-{2:2}:\n check_prev_add+0xe6/0xe00\n validate_chain+0x51e/0x6e0\n __lock_acquire+0x5a4/0xc50\n lock_acquire.part.0+0xb7/0x240\n lock_acquire+0x70/0x170\n __raw_spin_lock_irqsave+0x44/0x80\n _raw_spin_lock_irqsave+0x12/0x20\n try_to_wake_up+0x77/0xa90\n default_wake_function+0x27/0x60\n autoremove_wake_function+0x23/0xb0\n __wake_up_common+0xb8/0x170\n __wake_up_common_lock+0x51/0xa0\n __wake_up+0x20/0x40\n kswapd_wakeup_wake+0x7e/0x110\n wakeup_kswapd+0x295/0x320\n wake_all_kswapds+0xac/0x1a0\n __alloc_pages_slowpath.constprop.0+0x282/0xf80\n __alloc_frozen_pages_noprof+0x32a/0x360\n alloc_slab_page+0x2e/0x160\n allocate_slab+0x82/0x420\n new_slab+0x52/0xb0\n refill_objects+0x13d/0x190\n refill_sheaf+0x5d/0xd0\n __pcs_replace_empty_main+0x230/0xb10\n [...]\n\n other info that might help us debug this:\n\n Chain exists of:\n \u0026p-\u003epi_lock --\u003e kswapd_wakeup --\u003e \u0026pgdat-\u003ekswapd_wait\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(\u0026pgdat-\u003ekswapd_wait);\n lock(kswapd_wakeup);\n lock(\u0026pgdat-\u003ekswapd_wait);\n lock(\u0026p-\u003epi_lock);\n\n *** DEADLOCK ***\n\n 3 locks held by git/6660:\n #0: ffff8e519f0e9e20 (\u0026type-\u003ei_mutex_dir_key#6){++++}-{4:4}, at: lookup_slow+0x2d/0x60\n #1: ffffffff8a31c460 (kswapd_wakeup){-.-.}-\n---truncated---"
}
],
"id": "CVE-2026-98818",
"lastModified": "2026-10-19T10:19:45.873",
"metrics": {},
"published": "2026-10-18T16:17:36.017",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/46545c86b54ffb969b6e3662942b4a6191619eaa"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/af2fb3ee6679b517e2fdbd3ba16ec276a8b74312"
}
],
"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.