CVE-2026-98818

Status: ReceivedUnscored—
Severity—Unscored
Exploitation probability0.16 %higher than 5% of CVEs
Active exploitationNonot in the CISA catalog
Public exploitNot knownno public code found

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:

Technical details traces, logs and code from the original report
  ======================================================
  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---

CVSS

NVD hasn't assigned a CVSS score to this CVE (common since the April 2026 policy change).

Exploitation probability (EPSS)

Probability of exploitation in the next 30 days
0.16 %
Percentile among all scored CVEs
5
Score date
10/20/2026

EPSS (Exploit Prediction Scoring System, FIRST) estimates how likely a vulnerability is to be exploited in the wild within 30 days. It complements CVSS (impact) and CISA KEV (confirmed exploitation).

Affected technologies (1)

⚠ AI-inferred from the description — NVD hasn't analyzed this CVE yet, these aren't verified CPEs.

References

Show 2 references

Raw JSON (NVD)

Show
{
  "id": "CVE-2026-98818",
  "cveTags": [],
  "metrics": {},
  "affected": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "affectedData": [
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "ec66e0d599520ab414db745544e25d80d0ac5054",
              "lessThan": "46545c86b54ffb969b6e3662942b4a6191619eaa",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "ec66e0d599520ab414db745544e25d80d0ac5054",
              "lessThan": "af2fb3ee6679b517e2fdbd3ba16ec276a8b74312",
              "versionType": "git"
            }
          ],
          "programFiles": [
            "mm/slub.c"
          ],
          "defaultStatus": "unaffected"
        },
        {
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "product": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.18"
            },
            {
              "status": "unaffected",
              "version": "0",
              "lessThan": "6.18",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "7.2.10",
              "versionType": "semver",
              "lessThanOrEqual": "7.2.*"
            },
            {
              "status": "unaffected",
              "version": "7.3",
              "versionType": "original_commit_for_fix",
              "lessThanOrEqual": "*"
            }
          ],
          "programFiles": [
            "mm/slub.c"
          ],
          "defaultStatus": "affected"
        }
      ]
    }
  ],
  "published": "2026-10-18T16:17:36.017",
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/46545c86b54ffb969b6e3662942b4a6191619eaa",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/af2fb3ee6679b517e2fdbd3ba16ec276a8b74312",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "vulnStatus": "Received",
  "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 (&p->pi_lock){-.-.}-{2:2}, at: _raw_spin_lock_irqsave+0x12/0x20\n\n  but task is already holding lock:\n  ffff8e57bffff1a0 (&pgdat->kswapd_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  -> #2 (&pgdat->kswapd_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  -> #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  -> #0 (&p->pi_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    &p->pi_lock --> kswapd_wakeup --> &pgdat->kswapd_wait\n\n   Possible unsafe locking scenario:\n\n         CPU0                    CPU1\n         ----                    ----\n    lock(&pgdat->kswapd_wait);\n                                 lock(kswapd_wakeup);\n                                 lock(&pgdat->kswapd_wait);\n    lock(&p->pi_lock);\n\n   *** DEADLOCK ***\n\n  3 locks held by git/6660:\n   #0: ffff8e519f0e9e20 (&type->i_mutex_dir_key#6){++++}-{4:4}, at: lookup_slow+0x2d/0x60\n   #1: ffffffff8a31c460 (kswapd_wakeup){-.-.}-\n---truncated---"
    }
  ],
  "lastModified": "2026-10-19T10:19:45.873",
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}