CVE-2023-54100

What it actually does

Use-after-free in the qedi SCSI driver where qedi_remove() frees the scsi_host while pending delayed_work handlers (qedi_recovery_handler, qedi_board_disable_work) may still dereference it via iscsi_host_for_each_session.

Why it matters to the business

Systems using the QLogic QEDI iSCSI offload driver face kernel crashes, potential privilege escalation, or storage connectivity loss; the issue affects many Linux distributions and downstream products even though exploitation is currently uncommon.

How an attack unfolds

An attacker with local access triggers driver removal (qedi_remove) while a scheduled recovery or board-disable work item is still queued; once the host structure is freed the work handler runs and accesses the dangling pointer, leading to memory corruption.

How to fix it

Update the Linux kernel to a version containing commit fa19c533ab19161298f0780bcc6523af88f6fd20 or later; rebuild and reboot with the patched kernel. Where immediate patching is impossible, unload the qedi module or disable the affected hardware if operationally feasible.

How to confirm the fix worked

Verify the running kernel contains commit fa19c533ab19161298f0780bcc6523af88f6fd20 (or equivalent backport) via 'git log' or package changelog; confirm absence of the vulnerable sequence in drivers/scsi/qedi/qedi_main.c; test that qedi_remove cancels both work items before freeing the host.

Typical attack path

1. Obtain local code execution on a system using the qedi driver
2. Force or wait for qedi_schedule_recovery_handler or equivalent work scheduling
3. Trigger qedi_remove/__qedi_remove while the delayed work is pending
4. Allow the work handler to execute after iscsi_host_free/scsi_host_put has freed the structure
5. Exploit the resulting use-after-free for crash or code execution

How to detect it

Search kernel logs and audit trails for oops/panic messages referencing qedi_recovery_handler, qedi_board_disable_work, or iscsi_host_for_each_session around the time of qedi_remove; look for unexpected module unload events or hardware removal coinciding with crashes on systems that load qedi.

What your security team should do

• Apply the fixed kernel commit immediately on all systems exposing the qedi driver
• Prioritize patching of production storage servers and any systems listed in KEV-equivalent advisories
• Monitor EPSS trend and re-evaluate if score rises above 0.1
• Remove or blacklist the qedi module on systems that do not require QLogic offload
• Include the driver in regular kernel update and reboot automation