CVE-2026-89719 in Linux
Summary
by MITRE • 09/11/2026
In the Linux kernel, the following vulnerability has been resolved:
zram: fix out-of-bounds access in read_block_state()
read_block_state() calculates nr_pages before taking dev_lock. If the device is reset and reinitialized with a smaller disksize before lock acquisition, nr_pages still describes the old table. The subsequent loop can then call slot_lock() past the end of the newly allocated table.
Read disksize after acquiring dev_lock and checking that the device is initialized. The read lock then keeps the table and its bound stable for the duration of the scan.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/11/2026
The Linux kernel vulnerability identified in the zram subsystem involves a critical out-of-bounds memory access within the read_block_state function, stemming from a race condition during device state inspection. This flaw arises because the function calculates the number of pages to iterate over before acquiring the necessary synchronization lock that protects the underlying data structures. Specifically, nr_pages is derived based on the current disk size configuration without ensuring exclusive or shared access stability against concurrent modifications. In scenarios where an administrator resets and reinitializes the zram device with a smaller disksize while read_block_state is executing, the variable retains its value corresponding to the previous, larger allocation. Consequently, when the function proceeds to iterate through the block state table using this stale size metric, it attempts to access memory slots that no longer exist in the newly allocated, smaller table structure. This leads to a buffer over-read condition where slot_lock is invoked on invalid pointers beyond the bounds of the current device configuration, potentially causing kernel panics, data corruption, or unauthorized information disclosure depending on what resides at those out-of-bounds addresses.
From a technical perspective, this vulnerability represents a classic time-of-check-to-time-of-use (TOCTOU) race condition combined with improper locking granularity. The root cause lies in the ordering of operations within read_block_state; by reading disksize and calculating nr_pages prior to acquiring dev_lock, the code fails to guarantee that the table boundaries remain constant during the subsequent loop execution. This lack of atomicity allows a concurrent reset operation to shrink the allocated memory region while another thread is still operating under the assumption that the larger allocation exists. The vulnerability aligns with CWE-362, which describes concurrent access resulting in race conditions, and specifically touches upon CWE-125, Out-of-bounds Read, as the iteration logic accesses memory outside the valid array bounds. In terms of threat modeling, this could be leveraged by a local attacker who has permission to manipulate zram device parameters or trigger resets, potentially leading to denial of service through kernel crashes if the out-of-bounds access triggers a fault in protected memory regions.
The operational impact of this vulnerability is primarily centered on system stability and reliability rather than direct privilege escalation, although the consequences can be severe for availability. A successful exploitation attempt would likely result in an immediate kernel oops or panic, effectively crashing the host machine or container environment relying on zram functionality. This denial of service affects not only the local user but potentially other workloads sharing the same physical resources if the system becomes unresponsive. Furthermore, depending on the specific memory layout and what data happens to reside immediately after the allocated table in kernel space, there is a theoretical risk of leaking sensitive information from adjacent kernel structures into userspace via the read operation, although this would require precise timing and knowledge of internal kernel memory layouts. The vulnerability highlights the importance of strict synchronization protocols when dealing with dynamically sized resources that can be modified by privileged operations while being accessed by other threads.
To mitigate this vulnerability, the fix involves restructuring the execution flow within read_block_state to ensure data consistency through proper locking mechanisms. The recommended approach is to acquire dev_lock before reading the disksize and calculating nr_pages. By holding the lock during these initial steps, the code ensures that no concurrent reset or reinitialization can alter the table size while it is being inspected. Additionally, a check should be performed immediately after acquiring the lock to verify that the device remains initialized, preventing operations on stale or invalid state objects. This read lock maintains stability for the duration of the scan, ensuring that nr_pages accurately reflects the current allocation and that slot_lock calls remain within valid bounds. System administrators should ensure their Linux kernels are updated with patches addressing this specific zram issue to restore safe operation of compressed RAM devices under dynamic configuration changes.