CVE-2026-111555: Luksmeta: missing slot-range validation permits out-of-gap device i/o
A flaw was found in luksmeta. Improper boundary validation of metadata slots allows an attacker capable of supplying or modifying a disk header to redirect wipe or load operations outside the intended metadata area. An attacker could exploit this vulnerability by providing a crafted header with valid checksums to overwrite or zero out encrypted payload data, resulting in persistent data loss and corrupted storage. Exploitation typically requires privileged access to modify raw block devices or the ability to induce an administrator to process an untrusted disk image.
Other sources
A flaw was found in luksmeta. The readheader() function validates occupied slot offsets and lengths separately without ensuring that each complete range remains within the LUKS1 metadata gap. A crafted header with a valid CRC32C checksum can therefore direct subsequent luksmetaload() or luksmetawipe() operations outside the intended metadata area on the same opened device or image. The wipe operation can zero encrypted payload data, potentially causing persistent data loss or making filesystem contents inaccessible. A wrapping slot endpoint can also misposition the subsequent metadata-header rewrite. Exploitation on a deployed block device normally requires root or equivalent raw write access, which already permits direct storage corruption and substantially limits the additional capability gained. The command-line load path suppresses output when the data CRC check fails; no incremental confidentiality impact or privilege escalation has been established. Source review confirms that this parser defect remains after the allocator fix for CVE-2026-107565. The reviewed code path explicitly rejects LUKS2 devices.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Systems are exposed when luksmeta processes a crafted LUKS1 header on an opened device or disk image. Exploitation typically requires privileged raw block-device access, or the ability to persuade an administrator to process an untrusted disk image.
What must an attacker provide for exploitation to work?
The attacker needs a crafted disk header with a valid CRC32C checksum and slot offset or length values that cause the complete slot range to extend outside the LUKS1 metadata gap. The affected operations are luksmeta_load() and luksmeta_wipe().
What is the likely impact if exploitation succeeds?
A crafted header can redirect operations outside the metadata area on the same device or image. In particular, wiping can zero encrypted payload data, causing persistent data loss or making filesystem contents inaccessible; a wrapping slot endpoint can also misposition a later metadata-header rewrite.