It Looks Like There's A Possible Data Corruption Bug For Btrfs Dating Back To 2009
Written by Michael Larabel in Linux Storage on 11 December 2016 at 10:33 AM EST. 33 Comments
A Phoronix reader pointed out to us this weekend there's been another Btrfs file-system data corruption bug discovered that dates back to around 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.
Related News
About The Author
Author picture

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week