CVE-2021-47427

What it actually does

Use-after-free on iscsi_task object during abort handling when an already-completed task is detected, caused by incorrect goto to common put/cleanup path after reference count adjustments.

Why it matters to the business

Low immediate risk given stable low exploit probability, long public disclosure period, and absence from known exploitation lists; however, successful local or adjacent triggers on iSCSI-enabled systems can cause kernel crashes, service disruption, or potential privilege escalation in storage-heavy environments.

How an attack unfolds

An attacker with the ability to initiate or influence iSCSI sessions triggers an abort operation on a task that has already completed; the flawed reference handling path frees the task structure and then accesses it again during cleanup, resulting in memory corruption.

How to fix it

Apply the upstream fix that removes the erroneous goto and relocates the connection reference acquisition to after task validity checks; update to a Linux kernel version containing the revert of the faulty abort logic.

How to confirm the fix worked

Inspect kernel source or running kernel for the corrected abort handler sequence (iscsi_get_conn after task validity check); confirm absence of the d39df158518c commit pattern that introduced the goto; run iSCSI abort stress tests in a lab environment.

Typical attack path

1. Establish or hijack an iSCSI session to a target
2. Issue SCSI commands that create active tasks
3. Force or time an abort handler invocation on a task that has already completed
4. Trigger the incorrect goto path that performs put after free
5. Reuse the dangling task pointer for memory corruption or crash

How to detect it

Review kernel logs for iSCSI abort-related oops or use-after-free warnings; correlate with iSCSI session teardown events; no public exploit artifacts are known.

What your security team should do

• Prioritize kernel updates on systems exposing iSCSI targets or initiators
• Monitor EPSS and KEV status for any future increase in activity
• Limit iSCSI exposure to trusted networks only
• Enable kernel hardening features such as slab freelist randomization