CVE-2026-98094: staging: fbtft: make dirty_lock IRQ-safe
In the Linux kernel, the following vulnerability has been resolved:
staging: fbtft: make dirtylock IRQ-safe
fbtftmkdirty() can be reached from the fbcon rendering path while processing printk() in hardirq context. Meanwhile, dirtylock is also taken by fbtftdeferredio() in workqueue context with local interrupts enabled.
Lockdep reports a possible IRQ lock inversion involving dirtylock and consoleowner. A hardirq can interrupt a CPU holding dirtylock and enter the console rendering path, which can attempt to acquire dirtylock again.
The following lockdep report was observed on an RK3566 system with CONFIGPROVELOCKING enabled:
WARNING: possible irq lock inversion dependency detected swapper/2/0 just changed the state of lock: (consoleowner){-...}-{0:0} but this lock took another, HARDIRQ-unsafe lock in the past: (&par->dirtylock){+.+.}-{2:2}
CPU0 CPU1 ---- ---- lock(&par->dirtylock); localirqdisable(); lock(consoleowner); lock(&par->dirtylock); <Interrupt> lock(consoleowner);
DEADLOCK
Use spinlockirqsave() for fbtftmkdirty() and spinlockirq() for fbtftdeferredio(). They only access the dirty line range, so the IRQ-off regions remain short.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this locking issue?
Systems using the Linux kernel fbtft staging framebuffer driver are exposed when its dirty-lock handling can run both through framebuffer console rendering and deferred I/O workqueue processing. The reported lockdep warning was observed on an RK3566 system with CONFIG_PROVE_LOCKING enabled, but the affected code path is in the fbtft driver.
What conditions can trigger the deadlock?
The issue requires fbtft_mkdirty() to be reached from the fbcon rendering path while printk() is processed in hardirq context, concurrent with fbtft_deferred_io() holding the same dirty_lock in workqueue context. A hard interrupt can then enter console rendering and attempt to acquire dirty_lock while it is already held.
How can I tell whether a system is encountering this issue?
With CONFIG_PROVE_LOCKING enabled, lockdep can report a possible IRQ lock inversion dependency involving par->dirty_lock and console_owner, including a HARDIRQ-unsafe dirty_lock warning and a potential deadlock indication.
What mitigation is described if an update cannot be applied immediately?
The provided data does not describe a runtime workaround. The resolution is to make dirty_lock IRQ-safe by using spin_lock_irqsave() in fbtft_mkdirty() and spin_lock_irq() in fbtft_deferred_io().