CVE-2026-53156

What it actually does

This is a use-after-free flaw in the Linux kernel nvmem core error-handling paths. In certain failure conditions, the kernel may drop the final reference to an nvmem device, freeing the associated structure and resources, and then continue to access that freed nvmem structure before returning an error. Depending on timing, allocator behavior, kernel configuration, and attacker control over the triggering path, this can result in kernel memory corruption, denial of service through a kernel crash, or potentially privilege escalation if the freed memory can be reallocated and shaped with attacker-controlled data. Exploit maturity is currently reported as none, EPSS is very low, and the issue is not listed in CISA KEV.

Why it matters to the business

Systems running affected Linux kernel builds may be exposed to kernel instability or, in a worst-case scenario, local privilege escalation. The most likely operational impact is an unexpected kernel panic or reboot when vulnerable nvmem registration or error paths are triggered, which can disrupt workloads, embedded devices, appliances, or infrastructure that depends on nvmem-backed configuration, calibration, identity, or firmware data. Because there is no current KEV listing, no known ransomware association, and low EPSS, this should generally be prioritized as a routine kernel maintenance issue unless the organization operates untrusted local workloads, supports user-loadable kernel modules, or uses hardware/device-tree configurations that exercise nvmem providers frequently.

How an attack unfolds

An attacker first needs a way to reach the vulnerable nvmem core error path. In practical terms, this is most plausible from a local position with the ability to influence kernel device registration, load or interact with a vulnerable nvmem provider driver, trigger probe failures, or manipulate device configuration in environments where that is possible. The attacker causes an nvmem device setup or related operation to fail at a point where the kernel calls the device put routine and frees the underlying object. The flawed path then continues using the freed nvmem structure. If the freed memory has not been reused, the result may be a simple crash. If the attacker can repeatedly trigger the condition and influence kernel heap reuse, the stale pointer access may be shaped into controlled memory corruption. Successful exploitation could allow denial of service and, under favorable conditions, elevation from local code execution to kernel-level privileges. No public exploit maturity is indicated in the supplied data.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the nvmem core use-after-free error paths. Because no exact affected product list or fixed package versions were supplied, remediation should be based on the Linux distribution, appliance vendor, or kernel source tree used in the environment. Apply vendor kernel security updates as they become available, or backport the upstream nvmem core patch that ensures the nvmem device reference is released only as the final operation before returning an error. If immediate patching is not possible, reduce exposure by preventing untrusted users from loading kernel modules, restricting access to device-management interfaces, disabling unnecessary nvmem provider drivers where operationally safe, limiting physical or administrative access to device-tree/firmware configuration, and using kernel hardening features such as module signing, lockdown mode, SELinux/AppArmor, and panic/reboot monitoring.

How to confirm the fix worked

Confirm the running kernel includes the corrected nvmem core code path where the reference release is performed as the last step before returning from affected error paths. Validate through distribution package metadata, vendor security advisories, kernel changelogs, or source inspection of the nvmem core fix. On hosts, compare the running kernel version from uname or package inventory against the vendor-fixed kernel release. Where feasible in non-production testing, exercise nvmem provider registration and failure paths with kernel debugging enabled and confirm there are no KASAN, KFENCE, slab, refcount, or use-after-free reports. Also verify that mitigations are in place if patching is deferred: unprivileged module loading disabled, module signing enforced where applicable, and no unnecessary nvmem-related drivers are exposed.

Typical attack path

1. Gain local code execution or another capability that can influence Linux kernel device, driver, or nvmem-related operations.
2. Identify an nvmem provider or device path that can be made to fail during registration, probing, or cleanup.
3. Trigger the vulnerable error path so the nvmem object reference is released and the object may be freed.
4. Race or shape kernel heap reuse so the freed memory is accessed after being reclaimed, or repeatedly trigger the path to cause a kernel fault.
5. Achieve a denial-of-service condition through kernel panic, or in a more advanced scenario, convert memory corruption into kernel privilege escalation.

How to detect it

Look for evidence that the vulnerable nvmem error path was triggered, especially kernel crash artifacts and memory-safety diagnostics. Relevant sources include kernel logs, system journals, dmesg output, crash dumps, kdump/vmcore files, hypervisor console logs for guests, endpoint telemetry that captures kernel panics, and CI or test logs with KASAN/KFENCE enabled. Search for nvmem-related probe or registration failures followed by use-after-free, general protection fault, page fault, slab corruption, refcount, or panic messages. On systems with kernel debugging enabled, KASAN reports referencing nvmem core routines are strong indicators. Because no public exploit strings, malware artifacts, network signatures, or threat actors are provided, detection should focus on local kernel fault telemetry rather than network indicators. Repeated crashes involving nvmem after local device-management activity, module loading, driver probing, or hardware configuration changes should be investigated for possible exploitation attempts or regression testing of the flaw.

• KASAN: use-after-free
• BUG: KASAN: use-after-free
• KFENCE: use-after-free
• use-after-free in nvmem
• nvmem: core
• __nvmem_device_put
• nvmem_device_put
• nvmem_register
• nvmem_unregister
• general protection fault
• kernel BUG at
• kernel panic
• Oops:
• slab-use-after-free
• refcount_t: underflow
• Unable to handle kernel NULL pointer dereference
• /proc/vmcore
• /var/crash
• /sys/kernel/debug/kasan

What your security team should do

• Inventory Linux kernels and vendor appliances that include or depend on the kernel nvmem subsystem, prioritizing embedded, hardware-centric, virtualization host, and appliance-like deployments.
• Apply vendor kernel updates or backport the upstream nvmem core fix during the next normal patch cycle; accelerate if untrusted local users or workloads can influence kernel devices or load modules.
• Confirm kernel module loading is restricted to trusted administrators and enforce module signing or kernel lockdown where supported.
• Monitor for kernel crashes, KASAN reports, slab allocator warnings, and nvmem-related probe failures that could indicate attempted triggering or instability.
• If production systems cannot be patched promptly, disable unused nvmem provider drivers only after confirming there is no operational dependency.
• Track distribution advisories for exact fixed versions because the supplied data does not include product-specific package versions.
• Treat any repeatable nvmem-related kernel panic or use-after-free report as a high-priority incident requiring forensic preservation and kernel update validation.