CVE-2024-36027

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: do not flag ZEROOUT on non-dirty extent buffer<br /> <br /> Btrfs clears the content of an extent buffer marked as<br /> EXTENT_BUFFER_ZONED_ZEROOUT before the bio submission. This mechanism is<br /> introduced to prevent a write hole of an extent buffer, which is once<br /> allocated, marked dirty, but turns out unnecessary and cleaned up within<br /> one transaction operation.<br /> <br /> Currently, btrfs_clear_buffer_dirty() marks the extent buffer as<br /> EXTENT_BUFFER_ZONED_ZEROOUT, and skips the entry function. If this call<br /> happens while the buffer is under IO (with the WRITEBACK flag set,<br /> without the DIRTY flag), we can add the ZEROOUT flag and clear the<br /> buffer&amp;#39;s content just before a bio submission. As a result:<br /> <br /> 1) it can lead to adding faulty delayed reference item which leads to a<br /> FS corrupted (EUCLEAN) error, and<br /> <br /> 2) it writes out cleared tree node on disk<br /> <br /> The former issue is previously discussed in [1]. The corruption happens<br /> when it runs a delayed reference update. So, on-disk data is safe.<br /> <br /> [1] https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/<br /> <br /> The latter one can reach on-disk data. But, as that node is already<br /> processed by btrfs_clear_buffer_dirty(), that will be invalidated in the<br /> next transaction commit anyway. So, the chance of hitting the corruption<br /> is relatively small.<br /> <br /> Anyway, we should skip flagging ZEROOUT on a non-DIRTY extent buffer, to<br /> keep the content under IO intact.