Abort triggered in run_next_block

[ruuda]

Running btrfs check on the attached minimal file system causes the following:

Opening filesystem to check...
Checking filesystem on /tmp/bad.btrfs
UUID: 99e50868-0bda-4d89-b0e4-7e8560312ef9
[1/7] checking root items
[2/7] checking extents
zsh: abort (core dumped)  btrfs check /tmp/bad.btrfs

Running under GDB shows that abort is called from run_next_block in check/main.c, so I suppose it is this abort.

Tested versions:

• v5.2.2 as shipped by Arch in 5.2.2-1
• v5.2.2 built from source (55a8c96)

Data to reproduce:

• 9b591a6c79d8a13a38b51c250414e5.zip

[adam900710]

Thanks for the report and minimal reproducer.
The reproducer is especially helpful.

It's a bug in original mode, which doesn't have enough check for bad extent item.
Fortunately lowmem mode can handle it without problem.

I'll take the case.

BTW, would you like to share the method to craft/fuzz such images?

[adam900710]

Another small tip.

I guess not that many developers check github issues frequently enough.
So it would be a pretty good practice to report such fuzzed images to btrfs mail list (even it's just a btrfs-progs bug report)

Thanks for your report again.

[ruuda]

I'll take the case.

Thanks for having a look!

BTW, would you like to share the method to craft/fuzz such images?

This was a hackday project, it consists of a few modifications to btrfs check to allow running it under AFL. So the code quality is terrible and it is all undocumented, but I can try to give an overview here.

There are two trees, 221e119807a that makes some modifications for fuzzing, and dc058cf1e0426 to help fix up the checksums.

• Because the minimal size of a btrfs file system is fairly large (compared to typical fuzz inputs), having the fuzzer mutate images directly is infeasible.
• Instead, I created a clean btrfs image at /tmp/base.btrfs. The modified check program then makes a copy of it, and it interprets the fuzz input from stdin as mutation instructions that it applies to the copy. A mutation instruction is just an offset and a byte to write at that offset. The throughput of this approach is very low (it could do about 20 iterations per second per core), but it was sufficient to find several crashes in two days of fuzzing.
• Disable checksum verification, as mutations invalidate the checksums.
• Then I ran the modified check program under AFL.
• There is also a small Python script to generate fuzz seeds, and one to normalize and minimize fuzz inputs. It can minimize a bit better than AFL because it only produces valid mutation instructions.
• When AFL found a crash, I used the second modified check program to replace the checksums with the expected checksums. It replaces one checksum at a time and then exits, so it may need to run a few times before the image is valid. In some cases it also just prints a sed command to run manually, as that was easier than locating the right offset.

So it would be a pretty good practice to report such fuzzed images to btrfs mail list (even it's just a btrfs-progs bug report)

Thanks for the heads-up, I’ll be sure to send a mail to the mailing list next time.

[adam900710]

@ruuda Some advice on the fuzzing part.

There were some discussion about a more generic way to fuzz fs images, but at least for btrfs, you could try to corrupt random bits of a btrfs tree block, then write it back to disk directly.

That means there are just two main parts:

• Select victim
• Do the fuzz

The latter part is pretty easy in fact. Only two functions are mainly involved:

• read_tree_block()
• write_tree_block()

After acquiring an extent buffer, you can do random bit sets/clear of its data member, as long as you're only accessing the range [data + 0, data + fs_info->nodesize), you can do whatever you want, and write back that eb with trans = NULL.

To find a victim, you need to grab a valid extent buffer.
There are two different ways:

• Grab a known exiting tree block using valid extent tree
• Grab a random eb, until read_tree_block() accept it

The former one needs to search extent tree, which needs some btrfs on-disk format knowledge (https://btrfs.wiki.kernel.org/index.php/Btree_Items)

The latter one is pretty simple, just get a random number in the range [0, U64MAX), and round down to sector size (4K for x86), but it's pretty inefficient (depending on fs size, it could be several kilo vs the whole U64/4K range).

Anyway, it would be pretty awesome if you could report more bugs to btrfs-progs or btrfs kernel module.

[marcosps]

@ruuda per @adam900710 patch this issue was fixed, correct? can we close this bug?

[ruuda]

I can confirm that btrfs-progs 5.6 no longer aborts on the attached input file.