CVE-2026-31689: Linux Kernel Use-After-Free Vulnerability

CVE-2026-31689 Overview

A vulnerability has been discovered in the Linux kernel's EDAC (Error Detection and Correction) memory controller subsystem. The flaw exists in the edac_mc_alloc() function where improper initialization ordering in the error path can lead to calling kobject_put() on an uninitialized kobject. When the mci->pvt_info allocation fails, the error handling path calls put_device() which invokes the device's release function before device_initialize() has been called, resulting in operations on uninitialized memory structures.

Critical Impact

This vulnerability can cause kernel warnings and potential system instability when EDAC memory controller initialization fails, particularly affecting systems using AMD64 EDAC modules.

Affected Products

• Linux kernel versions with vulnerable EDAC/mc subsystem
• Systems using amd64_edac kernel module
• Linux kernel 7.0.0-rc1 and potentially other versions

Discovery Timeline

• 2026-04-27 - CVE CVE-2026-31689 published to NVD
• 2026-04-27 - Last updated in NVD database

Technical Details for CVE-2026-31689

Vulnerability Analysis

The vulnerability resides in the error handling logic within the edac_mc_alloc() function of the EDAC core module. The fundamental issue is an incorrect ordering of initialization operations. When memory allocation for mci->pvt_info fails, the code attempts to clean up by calling put_device(). However, the device_initialize() call that sets up the device structure—including the critical release function pointer—is positioned after the failing allocation in the code flow.

This means when the error path is triggered before device_initialize() is called, the subsequent put_device() call attempts to operate on a device that has not been properly initialized. The kobject subsystem correctly detects this inconsistency and generates a warning indicating that kobject_put() is being called on an uninitialized object. This manifests in kernel log messages showing the kobject has a null name and is not properly initialized.

Root Cause

The root cause is improper ordering of initialization and cleanup operations in the edac_mc_alloc() function. The code performs memory allocations before calling device_initialize(), but the error handling path assumes the device has already been initialized. This creates a condition where put_device() can be called on an uninitialized device structure, violating the expected lifecycle of kernel device objects.

Attack Vector

This vulnerability is primarily triggered during system initialization or when loading EDAC kernel modules, specifically when memory allocation fails during the EDAC memory controller setup process. The attack vector requires the ability to cause memory allocation failures during the EDAC initialization sequence. While this is typically a local denial-of-service scenario rather than a remote exploit, it can result in kernel warnings, potential NULL pointer dereferences, and system instability. The vulnerability was discovered during code review of another EDAC patch.

The kernel stack trace shows the issue occurring in the following call chain:

edac_mc_alloc+0xbe/0xe0 [edac_core]
amd64_edac_init+0x7a4/0xff0 [amd64_edac]
do_one_initcall

The fix involves reordering the code to ensure device_initialize() is called before any code path that might invoke put_device(), ensuring the device structure and release function pointer are properly initialized.

Detection Methods for CVE-2026-31689

Indicators of Compromise

• Kernel warning messages containing kobject: '(null)': is not initialized, yet kobject_put() is being called
• Warnings from lib/kobject.c:734 related to kobject_put operations
• Stack traces showing edac_mc_alloc in the call chain during system boot or module loading
• EDAC module initialization failures logged in dmesg or system logs

Detection Strategies

• Monitor kernel logs (dmesg) for kobject initialization warnings during boot and module loading
• Implement alerting on EDAC-related kernel warnings in centralized logging systems
• Use kernel tracing tools to monitor edac_mc_alloc() function calls and their return values
• Deploy kernel auditing to track EDAC module load events and associated errors

Monitoring Recommendations

• Configure syslog monitoring to alert on EDAC-related kernel warnings
• Implement system health checks that validate EDAC module initialization status
• Monitor for unusual patterns of memory allocation failures during kernel module initialization
• Review /var/log/kern.log and journalctl -k for related warning messages after system boots

How to Mitigate CVE-2026-31689

Immediate Actions Required

• Update to a patched Linux kernel version that includes the fix for the initialization ordering
• Review system logs for any evidence of this vulnerability being triggered
• Consider temporarily blacklisting EDAC modules on affected systems if patches are not immediately available
• Test kernel updates in a staging environment before production deployment

Patch Information

The Linux kernel maintainers have released patches to fix this vulnerability by reordering the calling sequence so that device_initialize() is called before any potential error path that could trigger put_device(). Multiple commits have been published to the stable kernel branches:

• Kernel Git Commit 51520e0
• Kernel Git Commit 7582564
• Kernel Git Commit 87ce8ae
• Kernel Git Commit aae9597
• Kernel Git Commit d20e98c
• Kernel Git Commit d3de72e

Apply the appropriate patch for your kernel version from the Linux kernel stable branches.

Workarounds

• Temporarily disable or blacklist EDAC modules if memory error reporting is not critical to operations
• Monitor systems for signs of exploitation while awaiting patch deployment
• Ensure systems have adequate memory available to reduce likelihood of allocation failures during initialization

# Temporarily blacklist EDAC modules as a workaround
echo "blacklist edac_core" >> /etc/modprobe.d/edac-blacklist.conf
echo "blacklist amd64_edac" >> /etc/modprobe.d/edac-blacklist.conf
# Rebuild initramfs if modules are loaded early in boot
update-initramfs -u