CVE-2026-90043 in Linux
Summary
by MITRE • 09/16/2026
In the Linux kernel, the following vulnerability has been resolved:
zram: fix slot lock bit position on big-endian 64-bit
The slot lock is a bit operation on the whole __lock word, which flags and ac_time alias as two u32s. On little-endian the lock bit lands in the position ZRAM_ENTRY_LOCK reserves in flags, so the aliasing works out. On 64-bit big-endian it lands in ac_time instead: with ZRAM_TRACK_ENTRY_ACTIME enabled, storing the access time from mark_slot_accessed() or slot_free() wipes out the held lock bit, letting another CPU take the same slot lock; an access time value with that bit set makes the slot look locked forever.
Shift the lock bit into the flags half of the word on big-endian 64-bit.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in the Linux kernel's zram subsystem represents a critical endianness-related logic error affecting 64-bit architectures operating in big-endian mode. ZRAM is a compressed RAM block device that allows for memory compression, effectively increasing available system memory by compressing pages in place rather than swapping them to disk. The integrity of concurrent access to these compressed slots relies heavily on atomic bit operations used to manage slot locks. These locks prevent race conditions where multiple CPUs might attempt to read or write the same compressed data simultaneously, which would lead to data corruption and potential kernel panics.
The technical flaw stems from how the lock state is stored within a composite word that aliases two 32-bit unsigned integers: one representing flags and the other tracking access time (ac_time). On little-endian systems, the bit position reserved for the slot lock aligns correctly with the flags field, ensuring that operations modifying the access time do not interfere with the lock state. However, on big-endian 64-bit architectures, the byte ordering causes this same bit to land within the ac_time portion of the word rather than the intended flags section. This misalignment creates a dangerous side effect when specific kernel functions are invoked.
When functions such as mark_slot_accessed() or slot_free() execute, they update the access time field to record recent activity on a given slot. Because the lock bit resides in this same 32-bit word under big-endian conditions, writing new data to ac_time inadvertently overwrites the lock bit. This action effectively clears the lock without properly releasing it through the intended synchronization mechanisms. Consequently, another CPU thread can acquire what appears to be an unlocked slot and begin modifying or reading its contents while the original holder still believes it retains exclusive access.
The operational impact of this race condition is severe. If two CPUs write to the same compressed slot concurrently, data corruption occurs within the zram device, potentially leading to filesystem errors if zram is used as a swap partition or root file system component. Furthermore, if an access time value happens to have the lock bit set due to memory patterns or previous operations, the slot may appear permanently locked to other threads. This results in deadlocks where processes wait indefinitely for a resource that will never be released, causing system hangs and denial of service conditions.
This vulnerability aligns with CWE-682, Incorrect Calculation, as it involves improper handling of bit positions based on architecture-specific endianness rules. It also relates to CWE-367, Time-of-check Time-of-use (TOCTOU) race condition, because the lock state is checked and then modified in a manner that allows interleaving by other threads due to the corrupted state representation. From an ATT&CK perspective, while this is not directly exploitable for remote code execution without additional conditions, it facilitates local privilege escalation or denial of service through resource exhaustion and system instability if triggered repeatedly under load.
The resolution involves shifting the lock bit position so that it resides within the flags half of the word on big-endian 64-bit systems. This ensures that updates to access time do not inadvertently clear the lock state, preserving the atomicity guarantees required for safe concurrent access. System administrators and developers should ensure that kernel patches are applied promptly to affected distributions running on big-endian hardware such as certain PowerPC or ARM configurations. Regular security audits focusing on bit manipulation logic in low-level memory management components can help identify similar endianness-related flaws before they manifest in production environments.