CVE-2024-50153

What it actually does

Null pointer dereference in target_alloc_device() when memory allocation for device queues fails; dev->transport is uninitialized so the subsequent free_device() call via dev->transport dereferences NULL.

Why it matters to the business

Local denial of service that can crash the kernel on systems exposing the SCSI target subsystem, leading to unplanned downtime and potential loss of storage services.

How an attack unfolds

An attacker with local access triggers the error path in target_alloc_device() by forcing a queue allocation failure during virtual LUN0 setup or similar init, causing the kernel to dereference an uninitialized pointer and panic.

How to fix it

Upgrade the Linux kernel to version 5.10.229 or later (or the equivalent backport that contains the fix using hba->backend->ops->free_device()). Reboot after the update.

How to confirm the fix worked

Confirm the running kernel version is at or above the fixed release; attempt to load target_core_mod and initialize a virtual LUN0 while monitoring for KASAN reports or null-deref crashes.

Typical attack path

1. Obtain local shell on a Linux system using the target_core_mod SCSI target driver
2. Trigger device allocation that reaches the queue allocation failure branch inside target_alloc_device()
3. Observe kernel panic from the NULL dereference in the subsequent free path

How to detect it

Search kernel logs and KASAN reports for the signature of the null-ptr-deref inside target_alloc_device+0xbc4; correlate with calls to core_dev_setup_virtual_lun0 during module initialization.

What your security team should do

• Apply the kernel update to 5.10.229+ immediately on all affected hosts
• Restrict local access to systems that expose the SCSI target subsystem until patched
• Monitor kernel logs for target_alloc_device related crashes as a temporary detection measure