CVE-2026-90043: Linux Kernel ZRAM Race Condition Vulnerability

CVE-2026-90043 Overview

CVE-2026-90043 is a race condition in the Linux kernel zram block device driver. The flaw affects big-endian 64-bit systems where the slot lock bit is placed in the wrong half of the __lock word. The flags and ac_time fields alias as two u32 values, and on big-endian 64-bit architectures the lock bit lands inside ac_time instead of flags. Writing an access time value can wipe out the held lock bit, allowing another CPU to acquire the same slot lock concurrently. Conversely, an access time value with that bit set makes the slot appear locked forever.

Critical Impact
A local attacker with the ability to trigger zram slot access on big-endian 64-bit kernels can corrupt lock state, causing data corruption, denial of service, or memory safety violations.

Affected Products

Linux kernel builds with zram enabled on 64-bit big-endian architectures
Kernel configurations with ZRAM_TRACK_ENTRY_ACTIME enabled
Distributions shipping affected upstream kernel versions prior to the referenced stable commits

Discovery Timeline

2026-09-16 - CVE-2026-90043 published to the National Vulnerability Database (NVD)
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-90043

Vulnerability Analysis

The zram driver implements a per-slot lock as an atomic bit operation on a 64-bit __lock word. That word aliases with two u32 fields: flags and ac_time. The ZRAM_ENTRY_LOCK constant defines the bit position used by bit_spin_lock() style primitives against __lock.

On little-endian 64-bit systems, ZRAM_ENTRY_LOCK falls inside the flags half of the word, so bit operations against __lock and field-level writes to ac_time do not overlap. On big-endian 64-bit systems, the byte order inverts the alignment. The lock bit lands inside the ac_time half of the aliased word.

When ZRAM_TRACK_ENTRY_ACTIME is enabled, mark_slot_accessed() and slot_free() write the current jiffies value into ac_time. That write overwrites the lock bit while another CPU still holds the slot lock. A second CPU can then acquire the same lock, producing a race condition on the compressed slot state.

Root Cause

The root cause is a byte-order dependent aliasing bug between an atomic bit position and a field write. The lock bit definition assumes little-endian layout of the union between __lock, flags, and ac_time. No compile-time or runtime shim adjusts the bit index for big-endian 64-bit builds, so the lock and access-time storage collide.

Attack Vector

Exploitation requires local access on a big-endian 64-bit Linux system running an affected kernel with zram and ZRAM_TRACK_ENTRY_ACTIME enabled. A local user can drive concurrent zram slot reads, writes, and frees to trigger the overlapping updates. Successful races corrupt slot metadata, which can escalate into use-after-free or double-free conditions in the compressed memory allocator. See the upstream fix commit a8b5875 and the companion commit 052b6b2 for the patched bit-shift logic.

// No public proof-of-concept code is available for this CVE.
// The fix shifts the lock bit into the flags half of the __lock word
// when building for 64-bit big-endian targets.

Detection Methods for CVE-2026-90043

Indicators of Compromise

Kernel log messages referencing zram slot state inconsistencies, decompression failures, or BUG_ON traces in zram_drv.c
Unexpected system hangs where a zram slot appears permanently locked, blocking swap or block I/O on /dev/zram*
Kernel panics or oops entries citing zsmalloc, zs_map_object, or slot free paths under memory pressure

Detection Strategies

Inventory running kernels for big-endian 64-bit architectures (for example ppc64, s390x) and confirm whether CONFIG_ZRAM and ZRAM_TRACK_ENTRY_ACTIME are enabled
Compare installed kernel commit hashes against the stable fix commits a8b58757 and 052b6b2d
Correlate zram driver stack traces from dmesg with periods of heavy swap or compressed memory activity

Monitoring Recommendations

Forward kernel logs to a centralized logging pipeline and alert on zram, zsmalloc, and bit_spin_lock warnings
Track kernel version and configuration drift across big-endian fleets to identify unpatched hosts
Monitor for repeated soft lockup or hung task warnings tied to processes performing zram-backed I/O

How to Mitigate CVE-2026-90043

Immediate Actions Required

Apply the upstream stable kernel patches from commits a8b5875741d4 and 052b6b2d5fe9 to any big-endian 64-bit build
Prioritize patching on s390x, ppc64, and other big-endian 64-bit systems where zram is in production use
Restrict local shell access on affected hosts until patched kernels are deployed

Patch Information

The fix shifts the slot lock bit into the flags half of the __lock word on 64-bit big-endian builds so that writes to ac_time no longer clear the lock bit. Rebuild and deploy kernels containing the stable commit a8b5875 and the stable commit 052b6b2. Distribution vendors should pick up both commits in their respective stable branches.

Workarounds

Disable ZRAM_TRACK_ENTRY_ACTIME in the kernel configuration to eliminate writes to ac_time from mark_slot_accessed() and slot_free()
Unload the zram module and disable zram-backed swap on affected big-endian 64-bit hosts until patches land
Migrate workloads from big-endian 64-bit hosts to little-endian architectures where the aliasing does not trigger the race

bash

# Temporarily disable zram-backed swap and unload the module
sudo swapoff /dev/zram0
sudo zramctl --reset /dev/zram0
sudo modprobe -r zram