CVE-2026-90278: md: wait for behind writes before destroying bitmap
In the Linux kernel, the following vulnerability has been resolved:
md: wait for behind writes before destroying bitmap
mdstop() destroyed the bitmap before calling mddevdetach(). That made mddevdetach() skip bitmapops->waitbehindwrites(), because the bitmap was already disconnected from mddev.
This was still safe for the legacy bitmap because bitmapdestroy() waits for behind writes itself. llbitmap keeps that wait in its ->waitbehindwrites() operation instead, while ->destroy() tears down the llbitmap storage. With the old ordering, RAID1 behind-write completions could still run after llbitmap storage had been freed.
Call mddevdetach() before mdbitmapdestroy() so the common detach path can wait for behind writes while the bitmap is still alive. Only destroy the bitmap after those users are gone.
Affected Software
Event History
Frequently Asked Questions
Which configurations are exposed to the unsafe teardown sequence?
The issue specifically affects RAID1 arrays using llbitmap where behind-write completions may still be pending when the array's bitmap is being destroyed. The legacy bitmap implementation is described as safe because its destroy operation waits for behind writes itself.
What condition triggers the use-after-free risk?
The risk arises when the bitmap is destroyed before the common detach path runs, because llbitmap storage can be torn down while RAID1 behind-write completions are still able to execute. The corrected ordering detaches the md device first so it waits for those writes before destroying the bitmap.