It Looks Like There's A Possible Data Corruption Bug For Btrfs Dating Back To 2009
Zygo Blaxell posted at the end of November, [PATCH] btrfs: fix hole read corruption for compressed inline extents. He explained there that the addition of zlib compression support for Btrfs produces data corruption when reading a file with a hole positioned after an inline extent due to returning uninitialized kernel memory rather than zero bytes.
Zygo went on to explain, "The offending holes appear in the wild and will appear during routine data integrity audits (e.g. comparing backups against their originals). They can also be created intentionally by fuzzing or crafting a filesystem image. Holes like these are not intended to occur in btrfs; however, I tested tagged kernels between v3.5 and the present, and found that all of them can create such holes. Whether we like them or not, this kind of hole is now part of the btrfs de-facto on-disk format, and we need to be able to read such holes without an infoleak or wrong data."
The patch adds just six lines of new code to Btrfs. He also explained more in a follow-up post. "The hole-creation bug is a very old, low-urgency issue. btrfs filesystems in the field have the buggy holes already, and have been creating new ones from 2009 to the present."
As of writing it doesn't appear the patch has been picked up by any stable kernel releases or mainline, so we'll see what comes of this matter in the days ahead and if any of the main upstream Btrfs developers have additional comment.
33 Comments
