CVE-2026-31689

What it actually does

This is a local Linux kernel availability flaw in the EDAC memory-controller allocation path. If allocation of the EDAC private data structure fails during edac_mc_alloc(), the error path can call put_device() before device_initialize() has initialized the embedded device object and release callback. That incorrect initialization order can trigger kobject warnings and potentially a kernel crash or service-impacting failure during EDAC driver initialization, such as amd64_edac loading. The flaw does not provide confidentiality or integrity impact based on the published vector, but it can affect system availability.

Why it matters to the business

A user or process with local access may be able to destabilize affected Linux systems by triggering a kernel error path, potentially causing crashes or outages on servers that load affected EDAC components. The risk is currently lower than internet-facing remote vulnerabilities because exploitation requires local privileges, EPSS is very low, there is no known public exploit maturity, and it is not listed in CISA KEV; however, affected kernels in production or multi-user environments should still be updated during normal kernel patch cycles because successful exploitation can interrupt critical workloads.

How an attack unfolds

An attacker first obtains local execution with low privileges on an affected Linux system. They then attempt to create conditions where EDAC memory-controller initialization occurs while memory allocation for mci->pvt_info fails, for example by inducing memory pressure or otherwise exercising EDAC module initialization paths. When the allocation failure occurs, the vulnerable kernel follows the incorrect cleanup path and calls put_device() on a device object that has not yet been initialized. This can result in kobject warnings and may escalate to a kernel oops, panic, or other availability-impacting failure depending on kernel configuration, module loading behavior, and panic-on-warning or crash policies. There is no indication from the provided data that the issue enables privilege escalation or data theft.

How to fix it

Upgrade the Linux kernel to a version that includes the EDAC/mc fix that initializes the device before any error path can call put_device(). No exact fixed package versions were provided, so use the fixed kernel versions or vendor advisories from the relevant Linux distribution, appliance vendor, cloud image provider, or kernel source branch. Prioritize updates for multi-user systems, systems where untrusted users can run code, and servers configured to panic on kernel warnings or oopses. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted workload execution, preventing unnecessary EDAC module loading where operationally acceptable, and monitoring for memory-pressure abuse or EDAC initialization failures. Mitigations should be treated as temporary because the reliable fix is the corrected kernel initialization ordering.

How to confirm the fix worked

Confirm the running kernel contains the upstream or vendor backport for the EDAC/mc edac_mc_alloc() initialization-order fix. Validate by checking the installed kernel package changelog or vendor security advisory for CVE-2026-31689 or the EDAC/mc fix description. After patching and rebooting into the corrected kernel, verify the active kernel with uname -r and confirm that EDAC-related modules load without kobject warnings. Review kernel logs using journalctl -k, dmesg, or centralized syslog for absence of warnings mentioning kobject_put(), edac_mc_alloc(), edac_core, or amd64_edac during boot and module initialization. Where safe in a test environment, reproduce EDAC driver initialization under controlled low-memory conditions to confirm the vulnerable warning or crash no longer occurs.

Typical attack path

1. Gain local code execution on an affected Linux system with low privileges.
2. Identify whether EDAC components such as edac_core or amd64_edac are present and can be initialized or reinitialized.
3. Create memory pressure or other resource-exhaustion conditions to increase the chance that mci->pvt_info allocation fails during edac_mc_alloc().
4. Trigger EDAC memory-controller initialization, such as by causing a relevant EDAC driver/module path to load.
5. Cause the vulnerable error path to call put_device() before device_initialize() has completed.
6. Observe or rely on the resulting kernel warning, oops, panic, or driver initialization failure to create denial of service.

How to detect it

Look for signs of EDAC initialization failure, kobject misuse warnings, kernel oopses, panics, or abnormal reboots around the time EDAC modules load. Useful log sources include journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump records, kdump/vmcore metadata, module-loading audit logs, and EDR telemetry showing local processes creating memory pressure shortly before kernel warnings. Search for the specific stack trace elements and warning strings published with the issue, especially kobject_put(), edac_mc_alloc(), amd64_edac_init(), edac_core, amd64_edac, and messages stating that a kobject is not initialized. Correlate those events with local user activity, module load events, resource-exhaustion behavior, unexplained service interruption, or host reboot. Because there are no known named threat actors, no KEV listing, and no known exploit maturity in the provided data, detection should focus on kernel artifacts and suspicious local triggering behavior rather than external network indicators.

• kobject: '(null)': is not initialized, yet kobject_put() is being called
• WARNING: lib/kobject.c:734 at kobject_put
• RIP: 0010:kobject_put
• edac_mc_alloc
• amd64_edac_init
• [edac_core]
• [amd64_edac]
• MCE: In-kernel MCE decoding enabled.
• do_one_initcall
• systemd-udevd

What your security team should do

• Inventory Linux systems running kernels that include EDAC memory-controller support, especially servers using amd64_edac or other EDAC drivers.
• Patch affected systems through the normal kernel update process and reboot into the fixed kernel; prioritize shared, multi-user, high-availability, and untrusted-workload environments.
• Check vendor advisories for exact fixed kernel package versions because no fixed versions were supplied in the input data.
• Temporarily restrict local access and untrusted workload execution on unpatched systems where feasible.
• Review kernel logs and SIEM telemetry for kobject_put(), edac_mc_alloc(), edac_core, and amd64_edac warnings or crashes that may indicate attempted triggering or accidental exposure.
• Assess systems configured with panic_on_warn, panic_on_oops, or aggressive crash policies, because warning paths may translate into full outages.
• Do not treat low EPSS or non-KEV status as a reason to ignore the issue; treat it as lower emergency priority but still patch because the impact is system availability.