CVE-2026-90238: media: amd: isp4: fix self-deadlock in isp4sd_pwron_and_init() error path
In the Linux kernel, the following vulnerability has been resolved:
media: amd: isp4: fix self-deadlock in isp4sdpwronandinit() error path
isp4sdpwronandinit() holds opsmutex via guard(mutex) and, on any init failure, jumps to errdeinit and calls isp4sdpwroffanddeinit(). That helper takes the same opsmutex, re-acquiring a non-recursive mutex already held by the current thread, so any init failure deadlocks.
Unwind the error path in stages instead, releasing only what each failure point acquired. This also avoids the issues that an unconditional teardown would hit at the earlier failures, such as a runtime-PM underflow from pmruntimeresumeandget() and MMIO access while the device is unpowered.
Event History
Frequently Asked Questions
When can this deadlock be triggered?
It is triggered when isp4sd_pwron_and_init() encounters any initialization failure after it has acquired ops_mutex. The error path then calls a teardown helper that attempts to acquire the same non-recursive mutex again.
What are the operational consequences of an affected error path?
The current thread can deadlock during device initialization failure handling. The prior unconditional teardown can also cause a runtime-PM underflow at early failure points or access MMIO while the device is unpowered.
Is normal successful initialization affected?
The described deadlock is specific to initialization failures and their cleanup path. The provided information does not indicate that successful initialization follows the problematic error path.