CVE-2026-98094: Linux kernel · staging: fbtft: make dirty_lock IRQ-safe
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in f576944a59f31bcffff121117ebf452c5dd162b7 : update Linux kernel when convenient.
Data as of 26 Oct 2026, 17:16 UTC
Rated Medium by Threat Radar's AI analysis · CVSS not yet scored by NVD
- EPSS
- 0.09% chance of exploitation in 30 days – higher than 0% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in f576944a59f31bcffff121117ebf452c5dd162b7, f2451e18826eb6a33ea51419f39bdd2eb99fa1ea, f0c869df2c33793c8828acaab3e4a5e0176f9f00 +5
Exploitation evidence
Disclosed: evidence found.
CVE published 25 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
AI-suggested
A fix is available and has been applied in the Linux kernel source as indicated by the fixed commit hashes. Users and administrators should update to a Linux kernel version that includes these fixes. No additional mitigation steps are required beyond applying the official patch.
Description
CVE-2026-98094 is a Linux kernel vulnerability in the staging fbtft driver where the dirty_lock is not IRQ-safe, leading to a potential deadlock due to lock inversion between dirty_lock and console_owner. This occurs because fbtft_mkdirty() can be called in hardirq context while dirty_lock is also taken in workqueue context with interrupts enabled. The issue was observed on RK3566 systems with CONFIG_PROVE_LOCKING enabled and has been fixed by making dirty_lock IRQ-safe using spin_lock_irqsave() and spin_lock_irq().
References
- git.kernel.org/stable/c/0843298b159599ee7bc6d14800efdb4bc7349706 (opens in a new tab)
- git.kernel.org/stable/c/a323066337ed85c38decfc7f6bbf42f27605dff1 (opens in a new tab)
- git.kernel.org/stable/c/f2451e18826eb6a33ea51419f39bdd2eb99fa1ea (opens in a new tab)
- git.kernel.org/stable/c/10cc145b873670438d3b105133dffdae70822db6 (opens in a new tab)
- git.kernel.org/stable/c/2a609e29efbba79f9abd68c4ec8a2bd7ecf291e7 (opens in a new tab)
- git.kernel.org/stable/c/f0c869df2c33793c8828acaab3e4a5e0176f9f00 (opens in a new tab)
- git.kernel.org/stable/c/dcb48fde8003492256dee45815144aa5ed26ce7c (opens in a new tab)
- git.kernel.org/stable/c/f576944a59f31bcffff121117ebf452c5dd162b7 (opens in a new tab)