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.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The broken slot lock lives in the zram block driver and is reached only through local I/O: zram_submit_bio() for read/write/discard and zram_slot_free_notify() from swap. It is not in a network protocol parser, Bluetooth/WiFi path, or a physical-device driver.
AC:L - On 64-bit big-endian kernels with CONFIG_ZRAM_TRACK_ENTRY_ACTIME, slot_free() zeros ac_time (the lock bit) immediately after slot_lock(), so exclusion is dropped on every free. An attacker who issues concurrent reads, writes, discards, or swap faults against the same zram page controls both sides of the race.
PR:L - zram_open() and zram_submit_bio() impose no capability check. In the highest-impact setup zram is already swap or mounted scratch storage, so an unprivileged local user can induce paging or file I/O that hits the slot lock; admin-only device creation is only an environmental prerequisite.
UI:N - After zram is configured as swap or writable storage, the attacker triggers the vulnerable path directly via memory pressure, page faults, madvise, or ordinary file I/O. No victim must mount a filesystem, open a crafted file, or otherwise participate.
S:U - Impact is corruption of in-kernel zram table entries and zsmalloc objects on the same host. That is a standard kernel compromise and does not cross a VM, IOMMU, or other separate security authority.
C:H - Clearing the held slot lock lets one CPU zs_free() a zsmalloc object while another still maps it in read_from_zspool()/zs_obj_read_begin(). That use-after-free of compressed-page heap objects can be reused for arbitrary kernel reads.
I:H - The same lost exclusion allows double-free of zsmalloc handles and torn updates of slot handle and flags, so a racing writer can free an object another CPU still uses or install a new handle over a live one, enabling arbitrary kernel writes and control-flow hijack.
A:H - Concurrent zs_free versus zs_obj_read_begin on the same handle can oops or panic the kernel, and an ac_time value that leaves the lock bit set makes later wait_on_bit_lock() sleep uninterruptibly forever on that slot.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The broken slot lock lives in the zram block driver and is reached only through local I/O: zram_submit_bio() for read/write/discard and zram_slot_free_notify() from swap. It is not in a network protocol parser, Bluetooth/WiFi path, or a physical-device driver.
AC:L - On 64-bit big-endian kernels with CONFIG_ZRAM_TRACK_ENTRY_ACTIME, slot_free() zeros ac_time (the lock bit) immediately after slot_lock(), so exclusion is dropped on every free. An attacker who issues concurrent reads, writes, discards, or swap faults against the same zram page controls both sides of the race.
PR:L - zram_open() and zram_submit_bio() impose no capability check. In the highest-impact setup zram is already swap or mounted scratch storage, so an unprivileged local user can induce paging or file I/O that hits the slot lock; admin-only device creation is only an environmental prerequisite.
UI:N - After zram is configured as swap or writable storage, the attacker triggers the vulnerable path directly via memory pressure, page faults, madvise, or ordinary file I/O. No victim must mount a filesystem, open a crafted file, or otherwise participate.
S:U - Impact is corruption of in-kernel zram table entries and zsmalloc objects on the same host. That is a standard kernel compromise and does not cross a VM, IOMMU, or other separate security authority.
C:H - Clearing the held slot lock lets one CPU zs_free() a zsmalloc object while another still maps it in read_from_zspool()/zs_obj_read_begin(). That use-after-free of compressed-page heap objects can be reused for arbitrary kernel reads.
I:H - The same lost exclusion allows double-free of zsmalloc handles and torn updates of slot handle and flags, so a racing writer can free an object another CPU still uses or install a new handle over a live one, enabling arbitrary kernel writes and control-flow hijack.
A:H - Concurrent zs_free versus zs_obj_read_begin on the same handle can oops or panic the kernel, and an ac_time value that leaves the lock bit set makes later wait_on_bit_lock() sleep uninterruptibly forever on that slot.
CVSS 3.1