UBUNTU-CVE-2026-68416: Double Free
In the Linux kernel, the following vulnerability has been resolved: mtd: fix double free and WARNON in addmtddevice() error paths When deviceregister() or mtdnvmemadd() fails inside addmtddevice() for a partition, the error handling triggers mtdrelease() via putdevice() or deviceunregister(). mtdrelease() calls releasemtdpartition() which frees the mtdinfo structure. However, callers such as mtdaddpartition() and addmtdpartitions() also call freepartition() in their error paths, resulting in a double free. Additionally, releasemtdpartition() hits WARNON(!listempty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the addmtddevice() error path. Fix this by overriding dev->type and dev->release before putdevice() in the error paths, so that devicerelease() invokes a no-op function instead of mtdrelease(). For the mtdnvmemadd() failure case, deviceunregister() is replaced with devicedel() to separate the device removal from the final kobject reference drop, allowing the override to take effect before putdevice() is called. The callers' error paths (listdel + freepartition) remain the sole owners of mtdinfo lifetime on addmtddevice() failure, which is the expected contract. The normal partition teardown path is not affected: delmtddevice() goes through krefput() -> mtddevicerelease() -> deviceunregister() with dev->type still set to &mtddevtype, so mtdrelease() -> releasemtdpartition() continues to work correctly for the regular removal case.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 6.8.0-147.147 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70 - Upgrade
Upgrade
ubuntu/linux-aws-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-azure-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1017.17~24.04.1 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 6.8.0-1069.76 - Upgrade
Upgrade
ubuntu/linux-azure-fde-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1016.16~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79 - Upgrade
Upgrade
ubuntu/linux-gcp-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1014.14~24.04.1 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 6.8.0-1066.74 - Upgrade
Upgrade
ubuntu/linux-gkeopto a version that resolves this vulnerability.Fixed in 6.8.0-1052.56 - Upgrade
Upgrade
ubuntu/linux-hwe-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38~24.04.4 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 6.8.0-1067.68 - Upgrade
Upgrade
ubuntu/linux-lowlatencyto a version that resolves this vulnerability.Fixed in 6.8.0-147.147.1 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 6.8.0-1064.67 - Upgrade
Upgrade
ubuntu/linux-oracle-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1013.13~24.04.1 - Upgrade
Upgrade
ubuntu/linux-riscv-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1~24.04.1 - Upgrade
Upgrade
ubuntu/linux-bluefieldto a version that resolves this vulnerability.Fixed in 6.8.0-1033.38 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 6.8.1-1062.63 - Upgrade
Upgrade
ubuntu/linux-aws-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1067.70+fips1 - Upgrade
Upgrade
ubuntu/linux-azure-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linux-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-147.147+fips1 - Upgrade
Upgrade
ubuntu/linux-gcp-fipsto a version that resolves this vulnerability.Fixed in 6.8.0-1071.79+fips1 - Upgrade
Upgrade
ubuntu/linuxto a version that resolves this vulnerability.Fixed in 7.0.0-38.38 - Upgrade
Upgrade
ubuntu/linux-awsto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-azureto a version that resolves this vulnerability.Fixed in 7.0.0-1017.17 - Upgrade
Upgrade
ubuntu/linux-azure-fdeto a version that resolves this vulnerability.Fixed in 7.0.0-1016.16 - Upgrade
Upgrade
ubuntu/linux-gcpto a version that resolves this vulnerability.Fixed in 7.0.0-1014.14 - Upgrade
Upgrade
ubuntu/linux-gketo a version that resolves this vulnerability.Fixed in 7.0.0-1008.9 - Upgrade
Upgrade
ubuntu/linux-ibmto a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oem-7.0to a version that resolves this vulnerability.Fixed in 7.0.0-1015.15 - Upgrade
Upgrade
ubuntu/linux-oracleto a version that resolves this vulnerability.Fixed in 7.0.0-1013.13 - Upgrade
Upgrade
ubuntu/linux-realtimeto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Upgrade
Upgrade
ubuntu/linux-riscvto a version that resolves this vulnerability.Fixed in 7.0.0-38.38.1 - Configuration
In the device_register() failure paths, override dev->type and dev->release before calling put_device(), so device_release() invokes a no-op instead of mtd_release(). For the mtd_nvmem_add() failure case, use device_del() instead of device_unregister() before applying the override and dropping the final kobject reference.
Linux kernel MTD add_mtd_device() error paths device cleanup before put_device() = Override dev->type and dev->release with a no-op release function
Event History
Frequently Asked Questions
Which Ubuntu kernel packages are identified as affected?
The listed packages are ubuntu/linux-riscv, ubuntu/linux-realtime, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-azure-fde, ubuntu/linux-gke, ubuntu/linux-hwe-edge, and ubuntu/linux-gkeop.
What conditions trigger the faulty cleanup path?
The issue is triggered when device_register() or mtd_nvmem_add() fails while add_mtd_device() is adding an MTD partition. The resulting cleanup can release the partition's mtd_info structure before callers also free it.
How could an affected system indicate this problem has occurred?
Affected error paths can produce a double free and a WARN_ON indicating that the partition node remains linked in the parent partitions list. The warning originates from release_mtd_partition() when the partition node is not empty.