CVE-2024-36924

What it actually does

Potential deadlock in the lpfc SCSI driver when lpfc_worker_wake_up() is invoked while hbalock is held, because lpfc_work_done() inside it also acquires the same lock.

Why it matters to the business

Linux systems using Emulex Fibre Channel adapters may experience kernel hangs or crashes under concurrent I/O workloads, leading to storage outages and downtime. Low public exploit activity reduces immediate risk but still requires prompt patching on affected servers.

How an attack unfolds

An attacker with local access triggers concurrent lpfc operations that hold hbalock while calling lpfc_worker_wake_up(), causing the worker thread to deadlock when it attempts to reacquire the lock inside lpfc_work_done().

How to fix it

Upgrade the Linux kernel to a version containing commit 6503c39398506cadda9f4c81695a9655ca5fb4fd. Rebuild and reboot with the patched kernel; apply distribution backports if available.

How to confirm the fix worked

Confirm the fix commit is present in the running kernel source tree or verify updated package versions from the Linux distribution. Test lpfc driver under load to ensure no deadlock occurs.

Typical attack path

1. Gain local access or control a process that interacts with lpfc devices
2. Craft concurrent I/O or interrupt sequences that acquire hbalock
3. Invoke lpfc_worker_wake_up() while the lock is held
4. Trigger deadlock in the kernel worker thread

How to detect it

Inspect kernel logs for deadlock or hung-task messages referencing lpfc_worker_wake_up, hbalock, or lpfc_work_done; correlate with Fibre Channel I/O activity.

What your security team should do

• Apply the kernel patch containing commit 6503c39398506cadda9f4c81695a9655ca5fb4fd as soon as possible
• Prioritize systems with lpfc adapters in production storage environments
• Monitor kernel logs for hung tasks or deadlock warnings involving lpfc
• Validate the fix in a staging environment before broad deployment