CVE-2026-43124

What it actually does

This is a local denial-of-service flaw in the Linux kernel pstore/ramoops persistent RAM code. When persistent_ram_vmap() calls vmap() and the mapping fails, the function can incorrectly return a non-NULL pointer if the persistent RAM region has a non-page-aligned offset. That false success causes persistent_ram_buffer_map() to treat an invalid mapping as usable, and later accesses through prz->buffer can dereference an invalid kernel address. The likely result is a kernel oops, panic, or system crash. The issue does not provide confidentiality or integrity impact and is not known to enable privilege escalation or code execution.

Why it matters to the business

Affected Linux systems that use pstore/ramoops persistent crash logging can be crashed locally, causing service interruption, failed workloads, node reboots, and reduced reliability. The current exploitation signal is low: EPSS is 0.00128 with no 30-day increase, it is not listed in CISA KEV, is not associated with ransomware activity, and there is no known public exploit maturity in the supplied data. However, because this is a kernel availability issue, organizations running high-availability infrastructure or embedded/edge Linux devices that rely on persistent RAM logging should still include the fix in normal kernel maintenance cycles.

How an attack unfolds

An attacker needs local access with the ability to trigger conditions under which the pstore/ramoops persistent RAM mapping path is initialized or exercised. If vmap() fails during persistent RAM mapping and the region begins at a non-page-aligned offset, the vulnerable code can add the offset to a NULL mapping result and return a seemingly valid pointer. The kernel then proceeds as though the persistent RAM buffer was mapped successfully. When the pstore subsystem later reads or writes through that buffer pointer, it can touch an invalid address and crash the kernel. In practice, exploitation is expected to be reliability- and configuration-dependent because it requires the vulnerable pstore/ramoops path and a vmap() failure condition rather than a simple remote packet or unauthenticated request.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix for the pstore ram_core NULL-checking bug in persistent_ram_vmap(). No exact fixed package versions were provided in the input, so use the fixed kernel versions published by the relevant Linux distribution, appliance vendor, cloud image provider, or embedded board vendor. Prioritize systems with pstore/ramoops enabled, systems using persistent RAM crash logging, and systems where local users, containers, or workloads have a realistic path to influence kernel memory pressure or crash logging behavior. If immediate patching is not possible, consider disabling or removing pstore/ramoops persistent RAM configuration where operationally acceptable, restricting local shell access, limiting untrusted workloads, and monitoring for repeated kernel oops/panic events. Mitigations reduce exposure but do not correct the faulty kernel logic.

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or kernel source contains the fix that properly checks the raw vmap() return value before adding offset_in_page(start) in persistent_ram_vmap(). On managed distributions, verify the installed and booted kernel version is at or above the vendor-advisory fixed version. Confirm the host has rebooted into the patched kernel, not merely installed it. Check pstore/ramoops exposure by reviewing kernel configuration and boot parameters for CONFIG_PSTORE, CONFIG_PSTORE_RAM, ramoops, and persistent memory reservations. Functional validation can include confirming normal pstore/ramoops initialization without kernel warnings after reboot. Avoid intentionally inducing kernel memory-mapping failures on production systems because validation attempts may crash vulnerable hosts.

Typical attack path

1. Obtain local access to a Linux system running a vulnerable kernel with pstore/ramoops or persistent RAM support enabled or configured.
2. Identify or induce conditions that cause persistent_ram_vmap() to call vmap() for a non-page-aligned persistent RAM region.
3. Trigger or wait for vmap() failure, such as under memory pressure or during pstore/ramoops initialization or remapping activity.
4. Cause the kernel to continue with the incorrectly non-NULL buffer pointer returned by the vulnerable code.
5. Trigger access to the pstore persistent RAM buffer, resulting in an invalid kernel memory dereference.
6. System experiences a kernel oops, panic, reboot, or availability loss.

How to detect it

To determine whether this was already exploited, review host and centralized Linux telemetry for kernel oops, panic, unexpected reboot, watchdog reset, or crash-dump events that coincide with pstore/ramoops activity. Relevant sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output retained by log agents, kdump/vmcore records, pstore records under /sys/fs/pstore, hypervisor reset logs, and endpoint telemetry that records process activity before a kernel crash. Look for stack traces or warnings containing persistent_ram_vmap, persistent_ram_buffer_map, persistent_ram_init_ringbuffer, ramoops, pstore, vmap allocation failure, NULL pointer dereference, or unable to handle kernel paging request. Correlate these events with local user sessions, container activity, stress or memory-pressure tools, repeated failed allocations, or abnormal workloads immediately before the crash. Because the symptom is a kernel crash and not a unique malware artifact, detection should focus on repeated or correlated crash patterns rather than a single definitive indicator.

• persistent_ram_vmap
• persistent_ram_buffer_map
• persistent_ram_init_ringbuffer
• persistent_ram
• ramoops
• pstore
• vmap() failed
• vmap allocation failure
• Unable to handle kernel NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Unable to handle kernel paging request
• Kernel panic - not syncing
• Oops:
• /sys/fs/pstore
• /dev/pmsg0
• ramoops.mem_address
• ramoops.mem_size
• pstore.backend=ramoops

What your security team should do

• Inventory Linux systems and appliances that run kernels with pstore/ramoops or persistent RAM crash logging enabled.
• Prioritize patching for multi-user systems, shared compute nodes, container hosts, embedded devices, and high-availability infrastructure where a local denial of service has operational impact.
• Track distribution and vendor advisories for the exact fixed kernel builds, then confirm systems are rebooted into the patched kernel.
• Where patching is delayed, disable pstore/ramoops persistent RAM logging if it is not operationally required and the change is supported by the platform.
• Restrict local access and untrusted workload execution on vulnerable systems until patched.
• Monitor kernel logs, crash dumps, pstore records, and reboot telemetry for oops/panic events referencing pstore, ramoops, persistent_ram, vmap, or invalid kernel pointer dereferences.
• Treat repeated unexplained kernel crashes on systems with pstore/ramoops enabled as potentially suspicious, even though current public exploitation likelihood is low.