In the Linux kernel, the following vulnerability has been resolved:
zram: fix slot write race condition
Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this:
CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock()
compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock
Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope.
| Software | From | Fixed in |
|---|---|---|
| linux / linux_kernel | 6.14 | 6.16.9 |
| linux / linux_kernel | 6.17-rc1 | 6.17-rc1.x |
| linux / linux_kernel | 6.17-rc2 | 6.17-rc2.x |
| linux / linux_kernel | 6.17-rc3 | 6.17-rc3.x |
| linux / linux_kernel | 6.17-rc4 | 6.17-rc4.x |
| linux / linux_kernel | 6.17-rc5 | 6.17-rc5.x |
| linux / linux_kernel | 6.17-rc6 | 6.17-rc6.x |