CVE-2026-43124: Linux Kernel pstore DOS Vulnerability

CVE-2026-43124 Overview

CVE-2026-43124 is a null pointer dereference vulnerability in the Linux kernel's pstore subsystem, specifically in the ram_core persistent RAM backend. The flaw resides in persistent_ram_vmap(), where the function fails to correctly propagate vmap() allocation failures when a non-zero offset is supplied. Adding offset_in_page(start) to a NULL return value produces a non-NULL but invalid pointer, causing persistent_ram_buffer_map() to incorrectly report success. Subsequent dereferences of prz->buffer may crash the kernel.

Critical Impact

A failed vmap() allocation causes the kernel to operate on an invalid pointer, leading to kernel crashes and denial of service on affected Linux systems using pstore RAM logging.

Affected Products

• Linux kernel (mainline) pstore/ram_core subsystem
• Linux stable kernel branches receiving the backported fix
• Distributions and embedded systems using pstore with RAM backend (commonly Android and ARM platforms)

Discovery Timeline

• 2026-05-06 - CVE CVE-2026-43124 published to NVD
• 2026-05-06 - Last updated in NVD database

Technical Details for CVE-2026-43124

Vulnerability Analysis

The Linux kernel's pstore (persistent store) subsystem records kernel logs and crash data into persistent storage backends. The ram_core backend uses a region of RAM mapped via vmap() for this purpose. In persistent_ram_vmap(), the kernel maps a sequence of pages and returns a pointer adjusted by the in-page offset of the requested start address.

When vmap() exhausts virtual memory or fails for any other reason, it returns NULL. The original code computed the return value as vaddr + offset_in_page(start) without checking the result of vmap(). If start is not page-aligned, the addition produces a small non-zero pointer that is neither NULL nor valid. The caller, persistent_ram_buffer_map(), treats any non-NULL return as success and stores the bogus pointer in prz->buffer.

Later accesses through prz->buffer dereference an unmapped low address, triggering an oops or panic in kernel context. This is a classic null pointer dereference [CWE-476] masked by pointer arithmetic.

Root Cause

The root cause is missing return-value validation. vmap() is documented to return NULL on failure, but persistent_ram_vmap() performs arithmetic on its result before any check. Adding a non-zero page offset to NULL yields a non-NULL pointer, defeating the simple if (!ptr) check expected by callers.

Attack Vector

The condition triggers when vmap() fails during pstore initialization or remapping, typically under heavy virtual memory pressure or fragmentation. The vulnerability is not remotely exploitable and requires conditions that exhaust kernel virtual address space. The practical impact is a denial of service through kernel crash rather than code execution or privilege escalation.

No verified public exploit code is available. The mechanism is described in the upstream commit references; see the Linux kernel stable commit for the patched logic.

Detection Methods for CVE-2026-43124

Indicators of Compromise

• Kernel oops or panic messages referencing persistent_ram_buffer_map or persistent_ram_vmap in dmesg or serial console output.
• Backtraces showing null pointer dereference at low virtual addresses inside fs/pstore/ram_core.c.
• Repeated boot failures on systems configured with ramoops after kernel updates or memory pressure events.

Detection Strategies

• Audit running kernel versions against the fixed commits listed in the upstream stable tree references.
• Inspect /sys/fs/pstore/ for missing or corrupt dmesg-ramoops records following crashes.
• Correlate kernel crash telemetry with workloads that allocate large vmalloc regions to identify exhaustion-triggered failures.

Monitoring Recommendations

• Forward kernel logs and crash dumps to a centralized logging platform and alert on pstore and ramoops panic signatures.
• Track /proc/vmallocinfo and /proc/meminfoVmallocUsed over time to identify systems approaching virtual memory exhaustion.
• Enable kdump or equivalent crash collection so that kernel oopses involving ram_core can be analyzed post-incident.

How to Mitigate CVE-2026-43124

Immediate Actions Required

• Apply the upstream Linux kernel patches that add proper NULL checking after the vmap() call in persistent_ram_vmap().
• Update to a stable kernel release that includes one of the referenced commits, such as 05363abc7625, 1da904e84de6, 2c99326dc1c7, or 49918dd52615.
• Reboot affected systems after patching to load the corrected pstore/ram_core code path.

Patch Information

The fix adds explicit validation of the vmap() return value before applying the page offset, ensuring persistent_ram_vmap() returns NULL on failure and that persistent_ram_buffer_map() correctly reports the error. Patched commits are available across stable branches via the Linux Kernel Stable Tree and additional backports referenced in the NVD entry.

Workarounds

• Disable ramoops or the pstore RAM backend in kernel configuration (CONFIG_PSTORE_RAM=n) on systems where persistent crash logging is not required.
• Reduce vmalloc pressure by tuning workloads that consume large amounts of kernel virtual address space, lowering the probability that vmap() fails.
• Limit pstore region size in device tree or ramoops.* module parameters to reduce the likelihood of allocation failure during initialization.

# Verify running kernel and pstore configuration
uname -r
zcat /proc/config.gz | grep -i pstore_ram
# Inspect existing pstore records and remove disabled ramoops if needed
ls -l /sys/fs/pstore/
# To disable ramoops at runtime (if loaded as a module)
sudo rmmod ramoops