A flaw was found in luksmeta. The read_header() 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 luksmeta_load() or luksmeta_wipe() 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.