A flaw was found in luksmeta. The gap allocator used by luksmeta_save() to find free space in a LUKS1 header does not correctly bound where a new metadata entry may be written. When metadata slot 0 already holds an entry, find_gap() computes its upper write limit using slot 0's own byte offset instead of the true end of the free-space gap, allowing luksmeta_save() to write a new entry past the end of the gap into the start of the encrypted payload area and corrupt stored data. Separately, the overlap() placement check only detects a new entry that covers the start or end of an existing entry, and misses a new entry that falls entirely within an existing entry longer than two pages (8192 bytes); this allows a new entry to overwrite part of an existing one, corrupting it so that it can no longer be loaded. Both conditions require an attacker who already has root-level write access to a LUKS1-formatted device; LUKS2 is not affected. Exploitation does not grant additional privileges or disclose data; the impact is limited to data corruption.