Zram can walk off its table after a shrink reset
Brief
The race needs a concurrent reset, usually from admin controls, while writeback or the memory-tracking scan is in flight.
Notes
Landed on Linus in merge 18fbf5151d2c (mm-stable-2026-08-26-15-22, 2026-08-27).
894913e2d35c (Longlong Xia): writeback_store() used to sample disk size before dev_lock. A reset to a smaller size could replace the table while the store waited for the lock, then the scan used the stale upper bound. Bound calculation moves under the lock. Fixes: a939888ec38b. Cc: stable.
391f057f44a5 (same series): read_block_state() had the same pattern for memory tracking. Same fix. Fixes: c0265342bff4. Cc: stable.
Public text is an out-of-bounds slot access from a reset race, not a named CVE. Not a remote packet path. Do not fold into other mm-stable Fixes in the same pull (NUMA shmem, kmemleak, vmscan, and friends). Hyper-V merge 5e6ff28676dd in the same window did not score.
Commit range 894913e2d35c46ff19a77530907771ae57862b96..391f057f44a51cc9418da5cba78b014324174264