Bug 2547930 (CVE-2026-107565)

Summary: CVE-2026-107565 luksmeta: Incomplete gap-boundary and overlap checks in LUKS1 metadata allocator allow data corruption
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: akhatavk, aos-team-art-private, asdas, dpaolell, jdelft, jupierce, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in luksmeta. A local attacker with administrative privileges can cause data corruption when saving metadata to a Linux Unified Key Setup (LUKS) device. Due to incorrect boundary calculations and flawed overlap detection, new metadata entries can be written beyond available free space or over existing records. This issue can corrupt stored encrypted payload data or existing metadata, potentially rendering the affected data inaccessible.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2547942    
Bug Blocks:    

Description OSIDB Bzimport 2026-10-08 12:14:32 UTC 
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.