CVE-2021-47045

What it actually does

Null pointer dereference in lpfc_prep_els_iocb() when lpfc_issue_els_plogi() is called with a DID that has no matching ndlp structure, resulting in kernel crash.

Why it matters to the business

Systems using Emulex or Broadcom Fibre Channel HBAs may experience unexpected kernel panics, leading to downtime, data inaccessibility, and potential loss of storage connectivity until reboot or failover.

How an attack unfolds

An attacker with the ability to trigger ELS PLOGI operations against an invalid DID on a system with the vulnerable lpfc driver causes the kernel to dereference a null ndlp pointer during iocb preparation, crashing the system.

How to fix it

Apply the upstream kernel patch that adds a check to return error status when no valid ndlp is found before calling lpfc_prep_els_iocb; update to a fixed kernel version containing this change.

How to confirm the fix worked

Confirm kernel source contains the error return guard in lpfc_issue_els_plogi before lpfc_prep_els_iocb; test by attempting ELS operations against unknown DIDs and verify no crash occurs.

Typical attack path

1. Identify host with lpfc driver and Fibre Channel connectivity
2. Craft or intercept traffic that invokes lpfc_issue_els_plogi with nonexistent DID
3. Trigger lpfc_prep_els_iocb with null ndlp
4. Kernel panics due to null dereference

How to detect it

Review kernel logs for oops or panic messages referencing lpfc_prep_els_iocb or lpfc_issue_els_plogi; examine Fibre Channel ELS traffic logs for PLOGI attempts to unknown DIDs preceding crashes.

What your security team should do

• Prioritize kernel updates on all systems exposing lpfc Fibre Channel drivers
• Monitor vendor advisories for backported fixes in supported distributions
• Restrict local access and Fibre Channel zoning to reduce attack surface until patched