CVE-2021-47258

What it actually does

Improper error handling after device_initialize() or dev_set_name() in scsi_host_alloc() causes device name memory to leak because kfree() is used instead of put_device(), bypassing scsi_host_dev_release() cleanup of IDA and kthread resources.

Why it matters to the business

Repeated SCSI host allocation failures under error conditions can gradually exhaust kernel memory, degrading system stability and availability in storage-heavy Linux environments without immediate operational impact.

How an attack unfolds

An attacker with local access triggers repeated SCSI host allocation paths that hit the error branch, causing the kernel to leak device name allocations without proper reference counting or resource release, eventually leading to memory pressure.

How to fix it

Update the Linux kernel to a version containing the fix that replaces kfree() with put_device() and removes special-casing of IDA and kthread removal in the error path of scsi_host_alloc().

How to confirm the fix worked

Confirm the running kernel source contains the corrected error handling that calls put_device() after dev_set_name() and relies on scsi_host_dev_release() for all cleanup; inspect kernel logs for absence of prior leak indicators under allocation stress.

Typical attack path

1. Obtain local code execution or trigger conditions that invoke scsi_host_alloc()
2. Force the allocation path into its error handling branch after dev_set_name()
3. Repeat to accumulate leaked device name memory allocations
4. Observe gradual kernel memory exhaustion affecting system performance

How to detect it

Review kernel logs and memory accounting for patterns of repeated scsi_host_alloc failures without corresponding device release; examine slab allocator statistics for growing device name allocations tied to SCSI host objects.

What your security team should do

• Prioritize kernel updates on systems with heavy SCSI/storage workloads
• Monitor kernel memory usage metrics for unexpected growth correlated with SCSI allocation events
• Apply the fix during the next maintenance window even without known active exploitation