Linux EDAC/mc - error path ordering in edac_mc_alloc(): When a private-data allocation fails in edac_mc_alloc()

Impact

When a private-data allocation fails in edac_mc_alloc(), the error path unwinds in the wrong order and touches memory it has already released. EDAC is the memory error-detection and correction subsystem - the thing telling you which DIMM is going bad on a node full of expensive HBM-adjacent DRAM - so a defect in its allocation path costs you both stability and the RAS visibility you were relying on.

Who can reach it

Local, on the EDAC allocation error path - hit under memory pressure rather than by an attacker.

What to do

Distro kernel update plus reboot; no firmware step. Worth taking on any fleet where you drive node retirement off EDAC data.

References

Related entries

• Linux iommu/vt-d (dev-IOTLB flush in scalable mode): The scalable-mode half of the device-IOTLB invalidation problem —CVE-2026-43130 · Linux iommu/vt-d (dev-IOTLB flush in scalable mode)Medium
• Linux iommu/vt-d (dev-IOTLB flush for passed-through PCIe devices): The Intel IOMMU driver skips device-IOTLBCVE-2026-43161 · Linux iommu/vt-d (dev-IOTLB flush for passed-through PCIe devices)Medium
• Linux kernel CephFS client: stale xattr blob size hits a BUG_ON and panics the nodeCVE-2026-52961 · Linux kernel CephFS client (__ceph_build_xattrs_blob)Medium
• Linux amd-pstate - memory leak in amd_pstate_epp_cpu_init(): On failure to set the energy-performance preferenceCVE-2026-53121 · Linux amd-pstate - memory leak in amd_pstate_epp_cpu_init()Medium
• Linux iommu/amd - devid bounds check in __rlookup_amd_iommu(): The AMD IOMMU driver looked up device IDs withoutCVE-2026-53283 · Linux iommu/amd - devid bounds check in __rlookup_amd_iommu()Medium
• Linuxfabrik monitoring plugins: sudo-authorized checks read arbitrary root-readable files via --testCVE-2026-73974 · Linuxfabrik Monitoring Plugins / linuxfabrik-lib (lib.lftest.test --test path handling)Medium