CVE-2024-39495

What it actually does

Race condition in greybus allowing use-after-free: gb_interface_release calls kfree on intf while gb_interface_mode_switch_work may still execute and access the freed object via mutex_lock.

Why it matters to the business

Potential kernel instability, crashes, or local privilege escalation on Linux systems exposing greybus interfaces; low urgency given static low EPSS and no KEV listing, but affects core kernel stability across distributions.

How an attack unfolds

An attacker with local access triggers gb_interface_create and gb_interface_request_mode_switch to queue mode_switch_work, then invokes gb_interface_release to free intf before the work runs, leading to UAF when the scheduled work dereferences the freed structure.

How to fix it

Cancel pending mode_switch_work before kfree in gb_interface_release; update Linux kernel to commit 74cd0a421896b2e07eafe7da4275302bfecef201 or later stable equivalents.

How to confirm the fix worked

Inspect gb_interface_release source for work cancellation prior to kfree; verify presence of the referenced commit in kernel tree; test race conditions with concurrent create/release and mode switch operations.

Typical attack path

1. Create greybus interface and bind mode_switch_completion
2. Queue mode_switch_work via gb_interface_request_mode_switch
3. Invoke gb_interface_release to free the intf object while work is pending
4. Scheduled work executes and performs mutex_lock on the freed intf

How to detect it

Examine kernel logs and crash dumps for greybus interface mode switch activity followed by use-after-free warnings or panics; correlate with process activity creating and releasing greybus interfaces.

What your security team should do

• Prioritize kernel upgrades on systems using greybus or exposed to local attackers
• Review and restrict greybus driver loading where not required
• Monitor kernel logs for related oops/panics and schedule patch deployment within normal update cycles