CVE-2026-53297: net: mana: Guard mana_remove against double invocation
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Guard manaremove against double invocation
If PM resume fails (e.g., manaattach() returns an error), manaprobe() calls manaremove(), which tears down the device and sets gd->gdmacontext = NULL and gd->driverdata = NULL.
However, a failed resume callback does not automatically unbind the driver. When the device is eventually unbound, manaremove() is invoked a second time. Without a NULL check, it dereferences gc->dev with gc == NULL, causing a kernel panic.
Add an early return if gdmacontext or driverdata is NULL so the second invocation is harmless. Move the dev = gc->dev assignment after the guard so it cannot dereference NULL.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify the mana_remove() (and/or the PM resume callback path that can call mana_remove after resume failure) to add an early return when gdma_context (gc) or driver_data is NULL, preventing a double invocation from dereferencing gc->dev when gc is NULL and triggering a kernel panic.
Linux kernel (net: mana) Add NULL guard in mana_remove/resume path = if gc == NULL return early; if driver_data == NULL return early (prevent dereference of gc->dev)
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
The issue is in the Linux kernel MANA network driver. It is triggered in the power-management resume and device-unbind path, rather than by ordinary network traffic.
What conditions are needed to trigger the kernel panic?
A PM resume must fail, such as when mana_attach() returns an error. That failure causes an initial cleanup, and a later driver unbind invokes cleanup again, leading to a NULL dereference in the unpatched code.
How can I recognize a potentially affected failure?
An affected system may panic when the MANA device driver is unbound after a failed resume operation. The failure results from dereferencing gc->dev after the prior cleanup has set the relevant driver context pointers to NULL.