Vulnerability-Lookup

GHSA-HQWF-4R5G-Q2H4

Vulnerability from github – Published: 2026-10-18 18:32 – Updated: 2026-10-18 18:32

Details

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---

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-98818"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-18T16:17:36Z",
    "severity": null
  },
  "details": "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": "GHSA-hqwf-4r5g-q2h4",
  "modified": "2026-10-18T18:32:04Z",
  "published": "2026-10-18T18:32:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98818"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/46545c86b54ffb969b6e3662942b4a6191619eaa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/af2fb3ee6679b517e2fdbd3ba16ec276a8b74312"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

CVE-2026-98818 (GCVE-0-2026-98818)

Vulnerability from cvelistv5 – Published: 2026-10-18 15:49 – Updated: 2026-10-19 09:26

Title

mm/slab: do not wake up kswapd in __kfree_rcu_sheaf()

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---

Severity

No CVSS data available.

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 6820 records in the last 180 days details

References

2 references

URL	Tags
https://git.kernel.org/stable/c/46545c86b54ffb969…
https://git.kernel.org/stable/c/af2fb3ee6679b517e…

Impacted products

2 products

Vendor	Product	Version
Linux	Linux	Affected: ec66e0d599520ab414db745544e25d80d0ac5054 , < 46545c86b54ffb969b6e3662942b4a6191619eaa (git) Affected: ec66e0d599520ab414db745544e25d80d0ac5054 , < af2fb3ee6679b517e2fdbd3ba16ec276a8b74312 (git)
Linux	Linux	Affected: 6.18 Unaffected: 0 , < 6.18 (semver) Unaffected: 7.2.10 , ≤ 7.2.* (semver) Unaffected: 7.3 , ≤ * (original_commit_for_fix)

Show details on NVD website

JSON

To clipboard

{
  "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"
}

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

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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.

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.

Action not permitted