CVE-2026-80963

What it actually does

A NULL pointer dereference in the Linux kernel device-mapper statistics (dm-stats) cleanup path can crash the kernel. If per-CPU data allocation fails while creating or initializing dm-stats, dm_stat_free still iterates possible CPUs and frees histogram buffers without checking whether s->stat_percpu[cpu] is NULL, producing a kernel oops or panic (availability loss). The defect is a local denial-of-service condition in the error path, not memory corruption or privilege escalation.

Why it matters to the business

Successful triggering can take hosts offline via kernel oops or panic, interrupting workloads that rely on device-mapper (LVM, thin provisioning, multipath, encrypted volumes, container storage). Impact is availability-only. Exploit maturity is none, EPSS is very low (~0.0022 and flat over 30 days), and the CVE is not in CISA KEV and is not associated with ransomware. Urgency is routine patching rather than emergency response unless systems already run unpatched kernels under memory pressure with dm-stats in use.

How an attack unfolds

An attacker with the ability to create or manipulate device-mapper statistics (typically a local, privileged, or container-escape-adjacent user who can invoke dm-stats) arranges a failed per-CPU allocation—most plausibly under memory pressure—then forces the stats object to be torn down. The kernel follows the failure path into dm_stat_free, dereferences a NULL per-CPU pointer, and oopses or panics. No public exploit, named threat actor, or in-the-wild campaign is indicated; exploitation requires local influence over dm-stats and a failed allocation, so remote unauthenticated use is not implied.

How to fix it

Apply the upstream Linux kernel fix that NULL-checks s->stat_percpu[cpu] before freeing histograms in dm_stat_free, then reboot into the patched kernel. Obtain the patched kernel from your distribution’s stable/security updates (device-mapper / linux-image packages). No vendor-specific fixed version list was supplied; track distro advisories for the kernel that includes the dm-stats per-CPU free NULL check. If you cannot patch immediately, avoid creating dm-stats under low-memory conditions, restrict who can use dmsetup stats / related ioctls, and monitor for allocation failures and kernel oopses. There is no configuration-only complete mitigation.

How to confirm the fix worked

Confirm the running kernel includes the dm-stats NULL check in dm_stat_free (vendor changelog, git commit, or source review). After upgrade and reboot, uname -r should show the patched release. On remaining unpatched hosts, inventory use of dm-stats (dmsetup stats list or equivalent) and whether device-mapper is in the storage stack. Do not attempt to reproduce the allocation-failure crash on production systems.

Typical attack path

1. Obtain local access (or equivalent capability) on a host running a vulnerable Linux kernel with device-mapper statistics available.
2. Cause or wait for memory pressure so per-CPU allocation for a new dm-stats object can fail.
3. Create or initialize dm-stats such that dm_kvzalloc of per-CPU data fails and the error path calls dm_stat_free.
4. Kernel NULL-dereferences s->stat_percpu[cpu] while freeing histograms, producing oops/panic and host denial of service.

How to detect it

This is a kernel NULL-dereference DoS, not a payload-dropping exploit. Hunt historical kernel logs (journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore, ABRT/apport) for oops/panic around device-mapper statistics. Look for RIP/call traces involving dm_stat_free, dm-stats histogram free, and NULL pointer dereference after a failed per-CPU allocation. Correlate with dmsetup stats create/delete, low-memory (OOM) events, and device-mapper control ioctls. Absence of those oops signatures does not prove the bug was never hit if logs rotated or panic rebooted without kdump. No named APT or ransomware IOCs are associated.

• NULL pointer dereference
• dm_stat_free
• stat_percpu
• dm-stats
• histogram_alloc_size
• device-mapper
• Oops: 0000
• kernel BUG at
• Call Trace:
• dmsetup stats

What your security team should do

• Patch and reboot Linux hosts to a kernel that includes the dm-stats dm_stat_free NULL check; treat as standard kernel security maintenance given low EPSS and no KEV listing.
• Prioritize hosts that use device-mapper heavily (LVM, thin pools, crypt, multipath, container storage) and any that enable dm-stats.
• Restrict unprivileged or unnecessary access to dmsetup stats and related device-mapper control interfaces until patched.
• Watch kernel logs for dm-stats / dm_stat_free oopses; a crash on an unpatched kernel may indicate the bug was hit (not necessarily malicious).
• Track distribution kernel advisories because no canonical package version list was published with this record.