CVE-2026-90043

The zram compressed-swap driver in the Linux kernel stores its per-slot lock as a bit inside a 64-bit word that doubles as two 32-bit fields (entry flags and last-access time). On 64-bit big-endian systems the lock bit lands in the access-time half of the word, so when access-time tracking (ZRAM_TRACK_ENTRY_ACTIME) is enabled, a normal access-time write from mark_slot_accessed() or slot_free() erases a held lock bit, letting another CPU acquire the same slot lock concurrently; conversely, an access-time value that happens to set that bit makes the slot appear locked forever. A local, low-privilege attacker could exploit the resulting race to corrupt zram slot state, and the CVSS vector indicates high potential impact on confidentiality, integrity, and availability, i.e., possible local privilege escalation or a persistent denial of service. Only systems running zram on 64-bit big-endian architectures (e.g., s390x, big-endian POWER, sparc64) with access-time tracking enabled are affected; little-endian platforms such as x86_64, ARM64, and Android are not. No public proof-of-concept or in-the-wild exploitation is known, and the issue is not in CISA's KEV catalog.

What to do: Apply the upstream kernel commit that shifts the slot-lock bit into the flags half of the word on big-endian 64-bit, or install your vendor's backported kernel update once published (the source data names no fixed version, so track vendor advisories). As an interim mitigation on affected big-endian hosts, avoid zram or do not enable access-time tracking (ZRAM_TRACK_ENTRY_ACTIME/writeback tracking), which is what clobbers the lock bit. Prioritize patching multi-tenant s390x/POWER/sparc systems, since exploitation requires only local low privileges.