CVE-2026-68416 Affecting kernel-bootwrapper package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-CENTOS6-KERNELBOOTWRAPPER-18717131
- published12 Aug 2026
- disclosed10 Aug 2026
Introduced: 10 Aug 2026
NewCVE-2026-68416 (opens in a new tab)How to fix?
There is no fixed version for Centos:6 kernel-bootwrapper.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-bootwrapper package and not the kernel-bootwrapper package as distributed by Centos.
See How to fix? for Centos:6 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
mtd: fix double free and WARN_ON in add_mtd_device() error paths
When device_register() or mtd_nvmem_add() fails inside add_mtd_device() for a partition, the error handling triggers mtd_release() via put_device() or device_unregister(). mtd_release() calls release_mtd_partition() which frees the mtd_info structure. However, callers such as mtd_add_partition() and add_mtd_partitions() also call free_partition() in their error paths, resulting in a double free.
Additionally, release_mtd_partition() hits WARN_ON(!list_empty( &mtd->part.node)) because the partition node is still linked in the parent's partitions list when the release callback fires from the add_mtd_device() error path.
Fix this by overriding dev->type and dev->release before put_device() in the error paths, so that device_release() invokes a no-op function instead of mtd_release(). For the mtd_nvmem_add() failure case, device_unregister() is replaced with device_del() to separate the device removal from the final kobject reference drop, allowing the override to take effect before put_device() is called.
The callers' error paths (list_del + free_partition) remain the sole owners of mtd_info lifetime on add_mtd_device() failure, which is the expected contract.
The normal partition teardown path is not affected: del_mtd_device() goes through kref_put() -> mtd_device_release() -> device_unregister() with dev->type still set to &mtd_devtype, so mtd_release() -> release_mtd_partition() continues to work correctly for the regular removal case.
References
- https://access.redhat.com/security/cve/CVE-2026-68416
- https://git.kernel.org/stable/c/820f983d641937a787e841ee4b93501f69f5683e
- https://git.kernel.org/stable/c/9d4af746af8ce27eefc2338b2feaa1e01f28b6c3
- https://git.kernel.org/stable/c/e1e96aca1bdf391e2f49531c270ffc134e5b49a5
- https://git.kernel.org/stable/c/f98ae09c727dcf34f745c875661c64b642e4abfa
- https://git.kernel.org/stable/c/ffe21a3545b439e7b11578a701c22a847c149561