CVE-2023-54058

What it actually does

Unconditional invocation of a potentially absent .remove callback in ffa_device_remove leads to a NULL pointer dereference and kernel oops during driver detach or module unload.

Why it matters to the business

Kernel crash and denial of service when unloading the arm_ffa driver or detaching devices, requiring system reboot and possible loss of ongoing operations on affected Linux systems.

How an attack unfolds

An attacker with local access triggers driver detachment or executes rmmod on the arm_ffa module; the unconditional call to a missing remove handler dereferences NULL, causing an immediate kernel fault.

How to fix it

Update the Linux kernel to commit 6a26c62625c59b8dd7f52c518cb4f60a63470a0e or a later stable release that adds the missing callback check before invoking ffa_drv->remove.

How to confirm the fix worked

Confirm the presence of the check for ffa_drv->remove before the call in ffa_device_remove and verify that module unload no longer produces a NULL dereference oops on test systems.

Typical attack path

1. Obtain local shell or sufficient privileges to unload kernel modules
2. Execute rmmod or trigger bus/driver removal for the arm_ffa driver
3. ffa_device_remove runs without checking for .remove callback
4. NULL pointer dereference occurs at EL1 resulting in kernel panic

How to detect it

Search kernel logs for Oops messages containing ffa_device_remove, device_release_driver_internal, and NULL pointer dereference at address 0; inspect rmmod or driver detach events around the timestamp of the crash.

What your security team should do

• Prioritize kernel upgrade on all systems exposing the arm_ffa driver
• Audit custom or out-of-tree FFA drivers to ensure a .remove callback is always registered when needed
• Monitor for kernel oops involving ffa_device_remove in production logs