CVE-2023-53449

What it actually does

Potential memory leak in dasd_eckd_init() where dasd_reserve_req allocation is not freed on error paths before subsequent dasd_vol_info_req allocation fails.

Why it matters to the business

On s390 systems using DASD storage, repeated initialization failures could slowly exhaust kernel memory, leading to degraded performance or crashes over time; low prevalence reduces overall urgency.

How an attack unfolds

An attacker with local access could attempt to trigger repeated dasd_eckd_init failures to cause memory exhaustion, though the bug is not a direct remote code execution or privilege escalation vector and no widespread exploitation is observed.

How to fix it

Update the Linux kernel to include commit ee986d80acdef710a886be404308188ea11000c8 which ensures dasd_reserve_req is freed on all error paths in dasd_eckd_init().

How to confirm the fix worked

Inspect dasd_eckd_init() source to confirm both allocations are released before every error return; verify updated kernel boots without memleak warnings on DASD initialization.

Typical attack path

1. Obtain local access to s390 Linux system
2. Trigger conditions causing dasd_eckd_init error after first allocation
3. Repeat to accumulate unfreed memory

How to detect it

Examine kernel logs and dmesg for repeated dasd initialization failures; use slabinfo or kmemleak tools to detect unfreed dasd_reserve_req objects.

What your security team should do

• Apply the referenced kernel commit or distribution backport immediately on s390 systems
• Review kernel memory usage trends on affected hosts
• Prioritize patching if DASD devices are in use despite low EPSS