CVE-2026-45950

What it actually does

Missing kfree on error paths after kzalloc of rctx->adata in starfive_aes_aead_do_one_req allows repeated allocations without corresponding frees when sg_copy_to_buffer or starfive_aes_hw_init fail.

Why it matters to the business

Local users can gradually exhaust kernel memory on systems using the affected StarFive AES crypto driver, leading to degraded performance or denial of service over time.

How an attack unfolds

An attacker with local access triggers the AEAD request path repeatedly, forcing the error conditions before cleanup so that each iteration leaks a small kernel allocation until memory pressure becomes noticeable.

How to fix it

Apply the upstream fix that adds kfree calls on the early error paths in starfive_aes_aead_do_one_req; rebuild and deploy the patched kernel on all affected systems.

How to confirm the fix worked

Inspect the starfive_aes_aead_do_one_req function for unconditional freeing of rctx->adata after the write_adata operations and confirm the added kfree statements exist on the sg_copy_to_buffer and starfive_aes_hw_init failure paths; monitor kernel memory statistics under load.

Typical attack path

1. Obtain local unprivileged access on a Linux system using the StarFive crypto driver
2. Repeatedly invoke AEAD operations that reach starfive_aes_aead_do_one_req
3. Force sg_copy_to_buffer or starfive_aes_hw_init to fail on each iteration
4. Observe cumulative kernel memory consumption without corresponding frees

How to detect it

Review kernel logs and slab allocator statistics for repeated allocations from the StarFive AES context without matching frees; correlate with process activity invoking AEAD operations.

What your security team should do

• Prioritize patching systems that expose the StarFive AES driver to local users
• Review kernel configurations to disable unused crypto drivers where feasible
• Monitor memory usage trends on affected hosts until patches are applied