CVE-2025-21671

What it actually does

Use-after-free on the zram table pointer when zram_meta_alloc fails early without nulling the pointer, allowing zram_meta_free to dereference freed memory on subsequent device reset of an uninitialized zram instance.

Why it matters to the business

Systems relying on zram for compressed memory swapping or block storage face risk of kernel instability, crashes, or local privilege escalation, increasing downtime and potential compromise on servers, containers, or embedded devices; high ecosystem prevalence in Linux distributions amplifies exposure.

How an attack unfolds

An attacker with local access creates a zram device, forces an early allocation failure in zram_meta_alloc, then issues a reset on the failed device so that zram_meta_free accesses the dangling table pointer, enabling memory corruption that can be chained for privilege escalation similar to other recent kernel UAFs used by threat actors.

How to fix it

Upgrade to fixed kernel versions containing commit fe3de867f94819ba0f28e035c0b0182150147d95 or apply equivalent stable patches; for ofono on Debian 13/14 update to version 2.14-1 or later; disable zram on untrusted multi-tenant systems until patched.

How to confirm the fix worked

Confirm kernel source or binary contains the referenced commit, verify zram_meta_alloc now properly nulls the table pointer on failure, and test device reset paths on intentionally failed zram allocations.

Typical attack path

1. Obtain local user or container access on a Linux system using zram
2. Trigger zram device creation that causes early failure in zram_meta_alloc
3. Issue device reset on the uninitialized zram instance
4. Trigger zram_meta_free to dereference the freed table pointer
5. Leverage resulting memory corruption for kernel code execution or escalation

How to detect it

Review kernel logs for zram allocation failure messages followed by unexpected resets or oops traces involving zram_meta_free; correlate with process creation of zram devices by unprivileged users; inspect for patterns matching other recent kernel privilege escalation attempts.

What your security team should do

• Prioritize patching all Linux kernels to the fixed commit within 48 hours given kernel privilege escalation patterns
• Audit zram usage in production workloads and disable where not essential
• Monitor for related kernel UAF exploitation attempts by threat actors targeting similar CVEs
• Update ofono packages to 2.14-1 on Debian 13 and 14 systems