REDHAT-BUG-2547930: Medium severity Luksmeta luksmeta vulnerability
A flaw was found in luksmeta. The gap allocator used by luksmetasave() 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, findgap() computes its upper write limit using slot 0's own byte offset instead of the true end of the free-space gap, allowing luksmetasave() 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.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Only LUKS1-formatted devices are affected. LUKS2 is not affected.
What level of access does an attacker need?
An attacker must already have root-level write access to the LUKS1-formatted device. The issue does not provide additional privileges or disclose data.
What is the practical impact of successful exploitation?
Successful exploitation can corrupt data by writing into the encrypted payload area or overwriting existing metadata entries. Corrupted metadata entries may no longer be loadable.