CVE-2026-98818 (GCVE-0-2026-98818)
Vulnerability from cvelistv5
Published
2026-10-18 15:49
Modified
2026-10-19 09:26
Severity ?
VLAI Severity ?
EPSS score ?
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
{
"containers": {
"cna": {
"affected": [
{
"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"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.2.10",
"versionStartIncluding": "6.18",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.3",
"versionStartIncluding": "6.18",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"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---"
}
],
"providerMetadata": {
"dateUpdated": "2026-10-19T09:26:11.267Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/46545c86b54ffb969b6e3662942b4a6191619eaa"
},
{
"url": "https://git.kernel.org/stable/c/af2fb3ee6679b517e2fdbd3ba16ec276a8b74312"
}
],
"title": "mm/slab: do not wake up kswapd in __kfree_rcu_sheaf()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-98818",
"datePublished": "2026-10-18T15:49:10.258Z",
"dateReserved": "2026-09-25T10:25:14.371Z",
"dateUpdated": "2026-10-19T09:26:11.267Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…