EUVD-2026-86924
GHSA-5wg8-22v7-6q2c
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLocal access to device running fbtft console
-
Exploitprintk in hardirq during fbcon render
-
ExecutionIRQ lock inversion on dirty_lock
-
ImpactCPU deadlock / system hang
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Proper locking
|
| Exploitation Conditions | Requires a system where the fbtft staging driver is bound to a small SPI TFT display used as the framebuffer console (fbcon) with deferred I/O enabled, such that fbtft_mkdirty() is reachable from the fbcon rendering path while printk() executes in hardirq context, concurrently with fbtft_deferred_io() taking par->dirty_lock in workqueue context with interrupts enabled. Limiting factors that reduce realistic risk: local-only vector (no remote reachability), the specific and relatively uncommon fbtft TFT-panel hardware/driver must be present and active as the console, and the inversion depends on precise hardirq timing rather than attacker-supplied data - it typically requires CONFIG_PROVE_LOCKING-observable conditions and concurrent console logging to materialize. |
| Impact | All signals point to this being a low-priority, defensively-relevant stability bug rather than a security emergency. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.5 MEDIUM) describes a local, availability-only impact with no confidentiality or integrity loss - consistent with CWE-667 (improper locking) and the described IRQ lock inversion that can deadlock a CPU. EPSS reinforces low real-world risk at 0.17% (5th percentile), there is no CISA KEV listing (not actively exploited) and no public exploit identified at time of analysis. The vuln.today decision label is 'this_month', i.e. routine patching, not act_now/emergency. One data conflict must be flagged: the input Tags list 'Information Disclosure', but the CVSS vector is explicitly C:N/I:N/A:H and the description is a deadlock/hang - there is no confidentiality impact, so the Information Disclosure tag is mislabeled and should be disregarded. Note also that the input CVSS uses AC:L, yet the described trigger is a timing-dependent hardirq interrupting a CPU holding dirty_lock, which is better characterized as high attack complexity. |
| Exploit ScenarioDerived | On an embedded/SBC system (e.g. the RK3566 board in the report) using the fbtft staging driver with a small SPI TFT panel as the console, kernel console output (printk) arriving in hardirq context during fbcon rendering can interrupt a CPU that holds par->dirty_lock, producing an IRQ lock-inversion deadlock that hangs the CPU. No public exploit code or PoC reference is provided, and the condition is a concurrency/timing fault rather than an attacker-supplied input, so it is far more likely to manifest as a spontaneous hang under logging load than as a deliberately weaponized attack. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 23, 2026
The Linux kernel's fbtft staging driver can deadlock because dirty_lock is taken in workqueue context with interrupts enabled while fbtft_mkdirty() is reachable from the fbcon rendering path during printk() in hardirq context, creating a lock inversion with console_owner. Affected systems are those using a small SPI TFT display bound to fbtft as the framebuffer console with deferred I/O; the flaw is local, timing-dependent, and not remotely reachable. Vendor fixes are available in Linux 6.12.111, 6.18.53, 7.2.7, and 7.3-rc2; no public exploit identified at time of analysis, and EPSS is 0.17%.
RemediationAI
Apply the vendor fix by updating to Linux 6.12.111, 6.18.53, 7.2.7, or 7.3-rc2, or by backporting the upstream stable commits 2a609e29efbba79f9abd68c4ec8a2bd7ecf291e7, f576944a59f31bcffff121117ebf452c5dd162b7, dcb48fde8003492256dee45815144aa5ed26ce7c, and f0c869df2c33793c8828acaab3e4a5e0176f9f00 from git.kernel.org; patch status is available from vendor. No vendor-documented workaround is supplied in the references, so the code fix is the complete remediation. If the update must be delayed, the practical compensating control is to avoid using an fbtft-bound SPI TFT as the system framebuffer console or to avoid loading the fbtft driver on systems that do not need it, which removes the fbcon rendering path involved but sacrifices TFT console output; this is not a substitute for the patch and does not address the underlying locking defect.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The fbtft driver is a Linux staging framebuffer driver for small SPI TFT panels. Its framebuffer deferred-I/O path uses par->dirty_lock to protect the dirty line range: fbtft_deferred_io() takes it from workqueue context with local interrupts enabled, while fbtft_mkdirty() can run from fbcon rendering inside printk() in hardirq context. Lockdep reported a possible IRQ lock inversion between dirty_lock and console_owner, because a hardirq can interrupt a CPU holding dirty_lock and re-enter console rendering that tries to take dirty_lock again; the fix makes fbtft_mkdirty() use spin_lock_irqsave() and fbtft_deferred_io() use spin_lock_irq(), keeping IRQ-off regions short. This is CWE-667 improper locking, with local access, high attack complexity, and availability-only impact per the assessed vector; the trigger is a specific hardware/driver-console configuration and hardirq timing, not attacker-supplied data.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Local-only driver bug with no network path (AV:L); the deadlock needs a hardirq to interrupt a CPU holding dirty_lock, a timing-dependent condition (AC:H); impact is a hang, availability-only (A:H, C/I:N).
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
4DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
staging: fbtft: make dirty_lock IRQ-safe
fbtft_mkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirty_lock is also taken by fbtft_deferred_io() in workqueue context with local interrupts enabled.
Lockdep reports a possible IRQ lock inversion involving dirty_lock and console_owner. A hardirq can interrupt a CPU holding dirty_lock and enter the console rendering path, which can attempt to acquire dirty_lock again.
The following lockdep report was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled:
WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (console_owner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirty_lock){+.+.}-{2:2}
CPU0 CPU1 ---- ---- lock(&par->dirty_lock); local_irq_disable(); lock(console_owner); lock(&par->dirty_lock); <Interrupt> lock(console_owner);
* DEADLOCK *
Use spin_lock_irqsave() for fbtft_mkdirty() and spin_lock_irq() for fbtft_deferred_io(). They only access the dirty line range, so the IRQ-off regions remain short.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
Exploit-DB