CVE-2026-89552

What it actually does

The vulnerability leaves a charp kernel parameter set to NULL when kmalloc fails in param_set_charp because the old value is freed before the replacement allocation succeeds, leading to a subsequent NULL pointer dereference (e.g., strcmp in zswap_setup).

Why it matters to the business

Attackers with parameter modification rights can trigger kernel panics and denial of service, disrupting system availability; the issue affects core kernel parameter handling across Linux distributions.

How an attack unfolds

An attacker with privileges to write module parameters via sysfs triggers param_set_charp for a compressor setting; an allocation failure leaves the parameter NULL, and later zswap initialization dereferences it causing a crash.

How to fix it

Apply a kernel patch or upgrade to a version that allocates and copies the replacement value before releasing the prior one in param_set_charp; rebuild and reboot with the fixed kernel.

How to confirm the fix worked

Confirm the kernel source contains the corrected param_set_charp logic that performs allocation before replacement, and test parameter updates under memory pressure to ensure no NULL dereference occurs.

Typical attack path

1. Obtain ability to modify kernel module parameters through sysfs or kernfs interfaces
2. Issue a parameter update that causes kmalloc to fail in param_set_charp
3. Force a subsequent code path (such as zswap_enabled_param_set) that dereferences the now-NULL parameter

How to detect it

Inspect kernel logs for BUG: kernel NULL pointer dereference messages with RIP in strcmp and call traces through zswap_setup or param_attr_store; correlate with prior -ENOMEM returns from parameter stores.

What your security team should do

• Prioritize kernel updates containing the allocation-order fix
• Restrict unprivileged access to sysfs parameter stores where feasible
• Monitor kernel logs for oops involving strcmp or zswap_setup