The vulnerability originates from the fbtft driver in the Linux kernel where the function fbtft_mkdirty() can be invoked during printk processing in a hardirq context. Simultaneously, the dirty_lock used by fbtft_mkdirty() and the console_owner lock used during console rendering can be entered in different orders, creating a lock inversion scenario. If an interrupt occurs while the CPU holds dirty_lock, the interrupt handler may attempt to acquire console_owner and then dirty_lock again. This sequence can trigger a deadlock that prevents further console output or other kernel activities, effectively leading to a denial-of-service condition. Lockdep reports indicate that this situation can materialize, especially on systems with CONFIG_PROVE_LOCKING enabled.

The flaw is present in all versions of the Linux kernel that include the fbtft driver and the associated locking logic, regardless of distribution. The lock inversion was confirmed on an RK3566 platform, suggesting that any kernel rendering the same staging driver on ARM or similar architectures may be affected. Broadly, any installation that loads the fbtft driver and uses printk in a hardirq context is potentially impacted.

The risk is primarily a denial-of-service through a deadlock; there are no known remote exploit vectors. EPSS data is unavailable and the vulnerability is not listed in CISA’s KEV catalog, indicating that active exploitation has not been observed. An attacker would need to trigger the specific rendering condition, typically by generating console output during a hardirq, which may require privileged or local access to the system. The seriousness stems from the potential to halt console output, hindering troubleshooting and potentially crashing critical processes if the deadlock propagates.