CVE-2026-98094

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); 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.