Comment 12 for bug 617885

Seth (bugs-sehe) wrote :

debian/patches/02-btrfs.patch is to blame, attaching a fix that works for me.

Disabling it (by removing the patch or passing --disable-btrfs to configure) might also remove the problem.
Attaching steps to reproduce in next post.

============== contains a glaring in the 'new' Btrfs detection code:

1139 if ( Glib::ustring( buf+64, strlen(BTRFS_SIGNATURE) ) == BTRFS_SIGNATURE)

buf is at that point either NULL or freed (valgrind confirms this). However, simply fixing it into buf_btrfs does not remove all of the problem... so:

$ sudo apt-get install libglibmm-2.4-dbg
(gdb) break
(gdb) dir ../glibmm2.4-2.25.5/glib/glibmm
(gdb) run /dev/loop0

thave some more insight: GLib::ustring is interpreting the 'random' (i.e. unknown, tainted) data in buffer read from the block device as a supposedly legal utf8 sequence. That borks some of the time (hey my random blocks don't always contain utf8 characters at the exact offset +64, sorry). It seems a lot wiser to substitute a strncmp or even memcmp with that?

My patch below fixes just that, and it works for my disks.

A signature is a signature by it's nature and it might even be used to detect endianness and stuff like that, so interpreting it as utf8 is a bit like playing with fire.

Perhaps GLib::ustring should handle invalid utf sequences robustly. I don't know whether the real bug is in glibmm (throwing because of improper UTF sequences might be ok, but callling a std::string(0) constructor is probably _not_ be intended). Also, this calls to review a lot more ustring operations on raw input buffers, because things could blow up in more places where it is being used on unknown data (raw input buffers).