* Carefully crafted BTRFS-image causes kernel to crash @ 2015-04-20 23:04 Lukas Lueg 2015-04-21 3:16 ` Qu Wenruo 0 siblings, 1 reply; 9+ messages in thread From: Lukas Lueg @ 2015-04-20 23:04 UTC (permalink / raw) To: linux-btrfs [-- Attachment #1: Type: text/plain, Size: 3165 bytes --] See also https://bugzilla.kernel.org/show_bug.cgi?id=96971 I've identified some problems in the btrfs code and attached a btrfs-image which causes the userland tools to crash and the kernel to immediately freeze once the filesystem get's mounted and one of the files is accessed. Putting the image onto a usb-drive gives you a freeze-on-a-stick :-) "btrfs check" crashes due to a SIGFPE in count_csum_range(). The culprit is struct btrfs_root->fs_info->super_copy->csum_size being 0, which goes unchecked before entering a division. I was not able to identify where the kernel crashes (system goes down the tubes), yet the problem is probably the same. "btrfs version" is v3.19.1; bug is also present in latest git (kdave and unstable) as of 2015/04/21 Full gdb output: gdb btrfs GNU gdb (GDB) Fedora 7.8.2-38.fc21 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from btrfs...Reading symbols from /usr/lib/debug/usr/sbin/btrfs.debug...done. done. (gdb) run check btrfs_fukked.bin Starting program: /usr/sbin/btrfs check btrfs_fukked.bin [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Checking filesystem on btrfs_fukked.bin UUID: cdd8684f-9eb1-40a4-91ec-1ed7c3cb444c checking extents checking free space cache checking fs roots Program received signal SIGFPE, Arithmetic exception. count_csum_range (root=<optimized out>, root=<optimized out>, found=<synthetic pointer>, len=7385088, start=7471104) at cmds-check.c:1455 1455 csum_end = key.offset + (size / csum_size) * root->sectorsize; (gdb) bt #0 count_csum_range (root=<optimized out>, root=<optimized out>, found=<synthetic pointer>, len=7385088, start=7471104) at cmds-check.c:1455 #1 process_file_extent (active_node=0x7fffffffd710, key=0x7fffffffd680, slot=11, eb=<optimized out>, root=0x894b10) at cmds-check.c:1551 #2 process_one_leaf (wc=0x7fffffffd6c0, eb=<optimized out>, root=0x894b10) at cmds-check.c:1617 #3 walk_down_tree (level=<synthetic pointer>, wc=0x7fffffffd6c0, path=0x7fffffffd7f0, root=0x894b10) at cmds-check.c:1742 #4 check_fs_root (wc=0x7fffffffd6c0, root_cache=0x7fffffffdb20, root=0x894b10) at cmds-check.c:3380 #5 check_fs_roots (root_cache=root_cache@entry=0x7fffffffdb20, root=0x894b10) at cmds-check.c:3516 #6 0x0000000000428aea in cmd_check (argc=<optimized out>, argv=<optimized out>) at cmds-check.c:9465 #7 0x000000000040e5a2 in main (argc=2, argv=0x7fffffffdeb0) at btrfs.c:245 (gdb) p csum_size $2 = 0 [-- Attachment #2: btrfs_fukked.bin.gz --] [-- Type: application/x-gzip, Size: 25237 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Carefully crafted BTRFS-image causes kernel to crash 2015-04-20 23:04 Carefully crafted BTRFS-image causes kernel to crash Lukas Lueg @ 2015-04-21 3:16 ` Qu Wenruo 2015-04-21 9:38 ` Russell Coker 2015-04-21 15:17 ` Zygo Blaxell 0 siblings, 2 replies; 9+ messages in thread From: Qu Wenruo @ 2015-04-21 3:16 UTC (permalink / raw) To: Lukas Lueg, linux-btrfs -------- Original Message -------- Subject: Carefully crafted BTRFS-image causes kernel to crash From: Lukas Lueg <lukas.lueg@gmail.com> To: <linux-btrfs@vger.kernel.org> Date: 2015年04月21日 07:04 > See also https://bugzilla.kernel.org/show_bug.cgi?id=96971 > > > I've identified some problems in the btrfs code and attached a > btrfs-image which causes the userland tools to crash and the kernel to > immediately freeze once the filesystem get's mounted and one of the > files is accessed. Putting the image onto a usb-drive gives you a > freeze-on-a-stick :-) > > "btrfs check" crashes due to a SIGFPE in count_csum_range(). The > culprit is struct btrfs_root->fs_info->super_copy->csum_size being 0, > which goes unchecked before entering a division. > I was not able to identify where the kernel crashes (system goes down > the tubes), yet the problem is probably the same. Thanks for the bug report. Although we may add extra check for such problem to improve robustness, but IMHO it's not a real world problem. For normal case, csum will not be zero for sure. And even for corrupted superblock, sb csum will prevent btrfs from using it. This problem will only happen, as your mentioned, by a specially crafted image or a known bug which btrfs will still use corruped sb even sb csum dismatches. Thanks, Qu > > "btrfs version" is v3.19.1; bug is also present in latest git (kdave > and unstable) as of 2015/04/21 > > > Full gdb output: > > gdb btrfs > GNU gdb (GDB) Fedora 7.8.2-38.fc21 > Copyright (C) 2014 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from btrfs...Reading symbols from > /usr/lib/debug/usr/sbin/btrfs.debug...done. > done. > (gdb) run check btrfs_fukked.bin > Starting program: /usr/sbin/btrfs check btrfs_fukked.bin > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Checking filesystem on btrfs_fukked.bin > UUID: cdd8684f-9eb1-40a4-91ec-1ed7c3cb444c > checking extents > checking free space cache > checking fs roots > > Program received signal SIGFPE, Arithmetic exception. > count_csum_range (root=<optimized out>, root=<optimized out>, > found=<synthetic pointer>, len=7385088, start=7471104) at cmds-check.c:1455 > 1455 csum_end = key.offset + (size / csum_size) * root->sectorsize; > (gdb) bt > #0 count_csum_range (root=<optimized out>, root=<optimized out>, > found=<synthetic pointer>, len=7385088, start=7471104) at cmds-check.c:1455 > #1 process_file_extent (active_node=0x7fffffffd710, key=0x7fffffffd680, > slot=11, eb=<optimized out>, root=0x894b10) at cmds-check.c:1551 > #2 process_one_leaf (wc=0x7fffffffd6c0, eb=<optimized out>, root=0x894b10) > at cmds-check.c:1617 > #3 walk_down_tree (level=<synthetic pointer>, wc=0x7fffffffd6c0, > path=0x7fffffffd7f0, root=0x894b10) at cmds-check.c:1742 > #4 check_fs_root (wc=0x7fffffffd6c0, root_cache=0x7fffffffdb20, root=0x894b10) > at cmds-check.c:3380 > #5 check_fs_roots (root_cache=root_cache@entry=0x7fffffffdb20, root=0x894b10) > at cmds-check.c:3516 > #6 0x0000000000428aea in cmd_check (argc=<optimized out>, > argv=<optimized out>) at cmds-check.c:9465 > #7 0x000000000040e5a2 in main (argc=2, argv=0x7fffffffdeb0) at btrfs.c:245 > (gdb) p csum_size > $2 = 0 > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Carefully crafted BTRFS-image causes kernel to crash 2015-04-21 3:16 ` Qu Wenruo @ 2015-04-21 9:38 ` Russell Coker 2015-04-21 11:44 ` Austin S Hemmelgarn 2015-04-21 15:17 ` Zygo Blaxell 1 sibling, 1 reply; 9+ messages in thread From: Russell Coker @ 2015-04-21 9:38 UTC (permalink / raw) To: Qu Wenruo; +Cc: Lukas Lueg, linux-btrfs On Tue, 21 Apr 2015, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote: > Although we may add extra check for such problem to improve robustness, > but IMHO it's not a real world problem. Some of the ReiserFS developers gave a similar reaction to some of my bug reports. ReiserFS wasn't the most robust filesystem. I think that it should be EXECTED that a kernel will have to occasionally deal with filesystem images that are created by hostile parties. Userspace crash and kernel freeze is not a suitable way of dealing with it. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Carefully crafted BTRFS-image causes kernel to crash 2015-04-21 9:38 ` Russell Coker @ 2015-04-21 11:44 ` Austin S Hemmelgarn 2016-08-29 17:11 ` David Sterba 0 siblings, 1 reply; 9+ messages in thread From: Austin S Hemmelgarn @ 2015-04-21 11:44 UTC (permalink / raw) To: russell, Qu Wenruo; +Cc: Lukas Lueg, linux-btrfs [-- Attachment #1: Type: text/plain, Size: 955 bytes --] On 2015-04-21 05:38, Russell Coker wrote: > On Tue, 21 Apr 2015, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote: >> Although we may add extra check for such problem to improve robustness, >> but IMHO it's not a real world problem. > > Some of the ReiserFS developers gave a similar reaction to some of my bug > reports. ReiserFS wasn't the most robust filesystem. > > I think that it should be EXECTED that a kernel will have to occasionally deal > with filesystem images that are created by hostile parties. Userspace crash > and kernel freeze is not a suitable way of dealing with it. > And that kind of reaction is why ReiserFS isn't taken very seriously in an enterprise environment. Just because something shouldn't be possible in a 'real world' environment, doesn't mean it won't happen; never underestimate the ability of hardware to fail in new and unexpected ways, or the ability of administrators to make stupid mistakes. [-- Attachment #2: S/MIME Cryptographic Signature --] [-- Type: application/pkcs7-signature, Size: 2967 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Carefully crafted BTRFS-image causes kernel to crash 2015-04-21 11:44 ` Austin S Hemmelgarn @ 2016-08-29 17:11 ` David Sterba 0 siblings, 0 replies; 9+ messages in thread From: David Sterba @ 2016-08-29 17:11 UTC (permalink / raw) To: Austin S Hemmelgarn; +Cc: russell, Qu Wenruo, Lukas Lueg, linux-btrfs On Tue, Apr 21, 2015 at 07:44:12AM -0400, Austin S Hemmelgarn wrote: > On 2015-04-21 05:38, Russell Coker wrote: > > On Tue, 21 Apr 2015, Qu Wenruo <quwenruo@cn.fujitsu.com> wrote: > >> Although we may add extra check for such problem to improve robustness, > >> but IMHO it's not a real world problem. > > > > Some of the ReiserFS developers gave a similar reaction to some of my bug > > reports. ReiserFS wasn't the most robust filesystem. > > > > I think that it should be EXECTED that a kernel will have to occasionally deal > > with filesystem images that are created by hostile parties. Userspace crash > > and kernel freeze is not a suitable way of dealing with it. > > > And that kind of reaction is why ReiserFS isn't taken very seriously in > an enterprise environment. > > Just because something shouldn't be possible in a 'real world' > environment, doesn't mean it won't happen; never underestimate the > ability of hardware to fail in new and unexpected ways, or the ability > of administrators to make stupid mistakes. I agree, given the high number of random memory bitflips that I've seen in past years, that were stored to the disk with valid checksums. Whether it's a real-world or potentially a hw problem IMO adjusts the priority, but the issues should be fixed if possible. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Carefully crafted BTRFS-image causes kernel to crash 2015-04-21 3:16 ` Qu Wenruo 2015-04-21 9:38 ` Russell Coker @ 2015-04-21 15:17 ` Zygo Blaxell 2015-04-22 0:28 ` Qu Wenruo 1 sibling, 1 reply; 9+ messages in thread From: Zygo Blaxell @ 2015-04-21 15:17 UTC (permalink / raw) To: Qu Wenruo; +Cc: Lukas Lueg, linux-btrfs [-- Attachment #1: Type: text/plain, Size: 5156 bytes --] On Tue, Apr 21, 2015 at 11:16:44AM +0800, Qu Wenruo wrote: > -------- Original Message -------- > Subject: Carefully crafted BTRFS-image causes kernel to crash > From: Lukas Lueg <lukas.lueg@gmail.com> > To: <linux-btrfs@vger.kernel.org> > Date: 2015年04月21日 07:04 > > >See also https://bugzilla.kernel.org/show_bug.cgi?id=96971 > > > > > >I've identified some problems in the btrfs code and attached a > >btrfs-image which causes the userland tools to crash and the kernel to > >immediately freeze once the filesystem get's mounted and one of the > >files is accessed. Putting the image onto a usb-drive gives you a > >freeze-on-a-stick :-) > > > >"btrfs check" crashes due to a SIGFPE in count_csum_range(). The > >culprit is struct btrfs_root->fs_info->super_copy->csum_size being 0, > >which goes unchecked before entering a division. > >I was not able to identify where the kernel crashes (system goes down > >the tubes), yet the problem is probably the same. > Thanks for the bug report. > > Although we may add extra check for such problem to improve robustness, > but IMHO it's not a real world problem. It depends on context. If your real world involves putting hostile USB sticks into your computer (e.g. you are a lawyer and your day job involves receiving electronic documents from hostile and sometimes technically sophisticated opponents), then this is definitely a real world problem. It needs to be treated as a security vulnerability (a minor one, given the requirement for physical access and no data loss except for the kernel crash), maybe assigned a CVE, and fixed with some urgency. If your real world involves running racks of machines with no USB ports in a locked data center then this issue is irrelevant noise. Other btrfs issues are *much* more likely to crash the kernel before this one. ;) > For normal case, csum will not be zero for sure. > And even for corrupted superblock, sb csum will prevent btrfs from using it. > > This problem will only happen, as your mentioned, by a specially > crafted image or a known bug which btrfs will still use corruped sb > even sb csum dismatches. > > Thanks, > Qu > > > >"btrfs version" is v3.19.1; bug is also present in latest git (kdave > >and unstable) as of 2015/04/21 > > > > > >Full gdb output: > > > >gdb btrfs > >GNU gdb (GDB) Fedora 7.8.2-38.fc21 > >Copyright (C) 2014 Free Software Foundation, Inc. > >License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > >This is free software: you are free to change and redistribute it. > >There is NO WARRANTY, to the extent permitted by law. Type "show copying" > >and "show warranty" for details. > >This GDB was configured as "x86_64-redhat-linux-gnu". > >Type "show configuration" for configuration details. > >For bug reporting instructions, please see: > ><http://www.gnu.org/software/gdb/bugs/>. > >Find the GDB manual and other documentation resources online at: > ><http://www.gnu.org/software/gdb/documentation/>. > >For help, type "help". > >Type "apropos word" to search for commands related to "word"... > >Reading symbols from btrfs...Reading symbols from > >/usr/lib/debug/usr/sbin/btrfs.debug...done. > >done. > >(gdb) run check btrfs_fukked.bin > >Starting program: /usr/sbin/btrfs check btrfs_fukked.bin > >[Thread debugging using libthread_db enabled] > >Using host libthread_db library "/lib64/libthread_db.so.1". > >Checking filesystem on btrfs_fukked.bin > >UUID: cdd8684f-9eb1-40a4-91ec-1ed7c3cb444c > >checking extents > >checking free space cache > >checking fs roots > > > >Program received signal SIGFPE, Arithmetic exception. > >count_csum_range (root=<optimized out>, root=<optimized out>, > > found=<synthetic pointer>, len=7385088, start=7471104) at cmds-check.c:1455 > >1455 csum_end = key.offset + (size / csum_size) * root->sectorsize; > >(gdb) bt > >#0 count_csum_range (root=<optimized out>, root=<optimized out>, > > found=<synthetic pointer>, len=7385088, start=7471104) at cmds-check.c:1455 > >#1 process_file_extent (active_node=0x7fffffffd710, key=0x7fffffffd680, > > slot=11, eb=<optimized out>, root=0x894b10) at cmds-check.c:1551 > >#2 process_one_leaf (wc=0x7fffffffd6c0, eb=<optimized out>, root=0x894b10) > > at cmds-check.c:1617 > >#3 walk_down_tree (level=<synthetic pointer>, wc=0x7fffffffd6c0, > > path=0x7fffffffd7f0, root=0x894b10) at cmds-check.c:1742 > >#4 check_fs_root (wc=0x7fffffffd6c0, root_cache=0x7fffffffdb20, root=0x894b10) > > at cmds-check.c:3380 > >#5 check_fs_roots (root_cache=root_cache@entry=0x7fffffffdb20, root=0x894b10) > > at cmds-check.c:3516 > >#6 0x0000000000428aea in cmd_check (argc=<optimized out>, > > argv=<optimized out>) at cmds-check.c:9465 > >#7 0x000000000040e5a2 in main (argc=2, argv=0x7fffffffdeb0) at btrfs.c:245 > >(gdb) p csum_size > >$2 = 0 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Carefully crafted BTRFS-image causes kernel to crash 2015-04-21 15:17 ` Zygo Blaxell @ 2015-04-22 0:28 ` Qu Wenruo 2015-04-29 19:50 ` Lukas Lueg 0 siblings, 1 reply; 9+ messages in thread From: Qu Wenruo @ 2015-04-22 0:28 UTC (permalink / raw) To: Zygo Blaxell; +Cc: Lukas Lueg, linux-btrfs -------- Original Message -------- Subject: Re: Carefully crafted BTRFS-image causes kernel to crash From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org> To: Qu Wenruo <quwenruo@cn.fujitsu.com> Date: 2015年04月21日 23:17 > On Tue, Apr 21, 2015 at 11:16:44AM +0800, Qu Wenruo wrote: >> -------- Original Message -------- >> Subject: Carefully crafted BTRFS-image causes kernel to crash >> From: Lukas Lueg <lukas.lueg@gmail.com> >> To: <linux-btrfs@vger.kernel.org> >> Date: 2015年04月21日 07:04 >> >>> See also https://bugzilla.kernel.org/show_bug.cgi?id=96971 >>> >>> >>> I've identified some problems in the btrfs code and attached a >>> btrfs-image which causes the userland tools to crash and the kernel to >>> immediately freeze once the filesystem get's mounted and one of the >>> files is accessed. Putting the image onto a usb-drive gives you a >>> freeze-on-a-stick :-) >>> >>> "btrfs check" crashes due to a SIGFPE in count_csum_range(). The >>> culprit is struct btrfs_root->fs_info->super_copy->csum_size being 0, >>> which goes unchecked before entering a division. >>> I was not able to identify where the kernel crashes (system goes down >>> the tubes), yet the problem is probably the same. >> Thanks for the bug report. >> >> Although we may add extra check for such problem to improve robustness, >> but IMHO it's not a real world problem. > > It depends on context. > > If your real world involves putting hostile USB sticks into your computer > (e.g. you are a lawyer and your day job involves receiving electronic > documents from hostile and sometimes technically sophisticated opponents), > then this is definitely a real world problem. It needs to be treated as a > security vulnerability (a minor one, given the requirement for physical > access and no data loss except for the kernel crash), maybe assigned a > CVE, and fixed with some urgency. Oh, I forgot the hostile USB case. And for that case, I think is is worthy to fix. For kernel, IIRC, there is a function to check superblock validation, so just one or two new lines to check csum size. And for btrfs-progs, we can add such function too. I'll send the patch recently BUT I also want to show the fact that, BTRFS is still under heavy development for its features and stability, so robustness may not be the primary concern yet. (More daily operation can cause problems, see fstests, run with old kernels and you should get a lot of hangs) Although any such report is still welcomed and I'll try to fix them if I have spare time. Thanks, Qu > > If your real world involves running racks of machines with no USB ports > in a locked data center then this issue is irrelevant noise. Other btrfs > issues are *much* more likely to crash the kernel before this one. ;) > >> For normal case, csum will not be zero for sure. >> And even for corrupted superblock, sb csum will prevent btrfs from using it. >> >> This problem will only happen, as your mentioned, by a specially >> crafted image or a known bug which btrfs will still use corruped sb >> even sb csum dismatches. >> >> Thanks, >> Qu >>> >>> "btrfs version" is v3.19.1; bug is also present in latest git (kdave >>> and unstable) as of 2015/04/21 >>> >>> >>> Full gdb output: >>> >>> gdb btrfs >>> GNU gdb (GDB) Fedora 7.8.2-38.fc21 >>> Copyright (C) 2014 Free Software Foundation, Inc. >>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> >>> This is free software: you are free to change and redistribute it. >>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>> and "show warranty" for details. >>> This GDB was configured as "x86_64-redhat-linux-gnu". >>> Type "show configuration" for configuration details. >>> For bug reporting instructions, please see: >>> <http://www.gnu.org/software/gdb/bugs/>. >>> Find the GDB manual and other documentation resources online at: >>> <http://www.gnu.org/software/gdb/documentation/>. >>> For help, type "help". >>> Type "apropos word" to search for commands related to "word"... >>> Reading symbols from btrfs...Reading symbols from >>> /usr/lib/debug/usr/sbin/btrfs.debug...done. >>> done. >>> (gdb) run check btrfs_fukked.bin >>> Starting program: /usr/sbin/btrfs check btrfs_fukked.bin >>> [Thread debugging using libthread_db enabled] >>> Using host libthread_db library "/lib64/libthread_db.so.1". >>> Checking filesystem on btrfs_fukked.bin >>> UUID: cdd8684f-9eb1-40a4-91ec-1ed7c3cb444c >>> checking extents >>> checking free space cache >>> checking fs roots >>> >>> Program received signal SIGFPE, Arithmetic exception. >>> count_csum_range (root=<optimized out>, root=<optimized out>, >>> found=<synthetic pointer>, len=7385088, start=7471104) at cmds-check.c:1455 >>> 1455 csum_end = key.offset + (size / csum_size) * root->sectorsize; >>> (gdb) bt >>> #0 count_csum_range (root=<optimized out>, root=<optimized out>, >>> found=<synthetic pointer>, len=7385088, start=7471104) at cmds-check.c:1455 >>> #1 process_file_extent (active_node=0x7fffffffd710, key=0x7fffffffd680, >>> slot=11, eb=<optimized out>, root=0x894b10) at cmds-check.c:1551 >>> #2 process_one_leaf (wc=0x7fffffffd6c0, eb=<optimized out>, root=0x894b10) >>> at cmds-check.c:1617 >>> #3 walk_down_tree (level=<synthetic pointer>, wc=0x7fffffffd6c0, >>> path=0x7fffffffd7f0, root=0x894b10) at cmds-check.c:1742 >>> #4 check_fs_root (wc=0x7fffffffd6c0, root_cache=0x7fffffffdb20, root=0x894b10) >>> at cmds-check.c:3380 >>> #5 check_fs_roots (root_cache=root_cache@entry=0x7fffffffdb20, root=0x894b10) >>> at cmds-check.c:3516 >>> #6 0x0000000000428aea in cmd_check (argc=<optimized out>, >>> argv=<optimized out>) at cmds-check.c:9465 >>> #7 0x000000000040e5a2 in main (argc=2, argv=0x7fffffffdeb0) at btrfs.c:245 >>> (gdb) p csum_size >>> $2 = 0 >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Carefully crafted BTRFS-image causes kernel to crash 2015-04-22 0:28 ` Qu Wenruo @ 2015-04-29 19:50 ` Lukas Lueg 2015-04-30 6:45 ` Duncan 0 siblings, 1 reply; 9+ messages in thread From: Lukas Lueg @ 2015-04-29 19:50 UTC (permalink / raw) To: Qu Wenruo; +Cc: linux-btrfs Hi, a patch was posted by Qu which should fix the issue, I did not check though. To give some context: Testing the userland tools to some depths comes back with around 13 percent of all execution paths in around 40 million runs to result in a segmentation fault, an uncatched divide-by-zero or self-destruction due to a heap buffer overflow catched by glibc. That is to be compared with zero crashes in the ext2fs userland tools. I'll pull in Qu's patch once there are patches for the other problems that were already posted and continue testing then. Best regards Lukas 2015-04-22 2:28 GMT+02:00 Qu Wenruo <quwenruo@cn.fujitsu.com>: > > > -------- Original Message -------- > Subject: Re: Carefully crafted BTRFS-image causes kernel to crash > From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org> > To: Qu Wenruo <quwenruo@cn.fujitsu.com> > Date: 2015年04月21日 23:17 > >> On Tue, Apr 21, 2015 at 11:16:44AM +0800, Qu Wenruo wrote: >>> >>> -------- Original Message -------- >>> Subject: Carefully crafted BTRFS-image causes kernel to crash >>> From: Lukas Lueg <lukas.lueg@gmail.com> >>> To: <linux-btrfs@vger.kernel.org> >>> Date: 2015年04月21日 07:04 >>> >>>> See also https://bugzilla.kernel.org/show_bug.cgi?id=96971 >>>> >>>> >>>> I've identified some problems in the btrfs code and attached a >>>> btrfs-image which causes the userland tools to crash and the kernel to >>>> immediately freeze once the filesystem get's mounted and one of the >>>> files is accessed. Putting the image onto a usb-drive gives you a >>>> freeze-on-a-stick :-) >>>> >>>> "btrfs check" crashes due to a SIGFPE in count_csum_range(). The >>>> culprit is struct btrfs_root->fs_info->super_copy->csum_size being 0, >>>> which goes unchecked before entering a division. >>>> I was not able to identify where the kernel crashes (system goes down >>>> the tubes), yet the problem is probably the same. >>> >>> Thanks for the bug report. >>> >>> Although we may add extra check for such problem to improve robustness, >>> but IMHO it's not a real world problem. >> >> >> It depends on context. >> >> If your real world involves putting hostile USB sticks into your computer >> (e.g. you are a lawyer and your day job involves receiving electronic >> documents from hostile and sometimes technically sophisticated opponents), >> then this is definitely a real world problem. It needs to be treated as a >> security vulnerability (a minor one, given the requirement for physical >> access and no data loss except for the kernel crash), maybe assigned a >> CVE, and fixed with some urgency. > > Oh, I forgot the hostile USB case. > > And for that case, I think is is worthy to fix. > For kernel, IIRC, there is a function to check superblock validation, > so just one or two new lines to check csum size. > > And for btrfs-progs, we can add such function too. > > I'll send the patch recently > > BUT I also want to show the fact that, BTRFS is still under heavy > development for its features and stability, so robustness may not be the > primary concern yet. > (More daily operation can cause problems, see fstests, run with old > kernels and you should get a lot of hangs) > Although any such report is still welcomed and I'll try to fix them if I > have spare time. > > Thanks, > Qu > >> >> If your real world involves running racks of machines with no USB ports >> in a locked data center then this issue is irrelevant noise. Other btrfs >> issues are *much* more likely to crash the kernel before this one. ;) >> >>> For normal case, csum will not be zero for sure. >>> And even for corrupted superblock, sb csum will prevent btrfs from using >>> it. >>> >>> This problem will only happen, as your mentioned, by a specially >>> crafted image or a known bug which btrfs will still use corruped sb >>> even sb csum dismatches. >>> >>> Thanks, >>> Qu >>>> >>>> >>>> "btrfs version" is v3.19.1; bug is also present in latest git (kdave >>>> and unstable) as of 2015/04/21 >>>> >>>> >>>> Full gdb output: >>>> >>>> gdb btrfs >>>> GNU gdb (GDB) Fedora 7.8.2-38.fc21 >>>> Copyright (C) 2014 Free Software Foundation, Inc. >>>> License GPLv3+: GNU GPL version 3 or later >>>> <http://gnu.org/licenses/gpl.html> >>>> This is free software: you are free to change and redistribute it. >>>> There is NO WARRANTY, to the extent permitted by law. Type "show >>>> copying" >>>> and "show warranty" for details. >>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>> Type "show configuration" for configuration details. >>>> For bug reporting instructions, please see: >>>> <http://www.gnu.org/software/gdb/bugs/>. >>>> Find the GDB manual and other documentation resources online at: >>>> <http://www.gnu.org/software/gdb/documentation/>. >>>> For help, type "help". >>>> Type "apropos word" to search for commands related to "word"... >>>> Reading symbols from btrfs...Reading symbols from >>>> /usr/lib/debug/usr/sbin/btrfs.debug...done. >>>> done. >>>> (gdb) run check btrfs_fukked.bin >>>> Starting program: /usr/sbin/btrfs check btrfs_fukked.bin >>>> [Thread debugging using libthread_db enabled] >>>> Using host libthread_db library "/lib64/libthread_db.so.1". >>>> Checking filesystem on btrfs_fukked.bin >>>> UUID: cdd8684f-9eb1-40a4-91ec-1ed7c3cb444c >>>> checking extents >>>> checking free space cache >>>> checking fs roots >>>> >>>> Program received signal SIGFPE, Arithmetic exception. >>>> count_csum_range (root=<optimized out>, root=<optimized out>, >>>> found=<synthetic pointer>, len=7385088, start=7471104) at >>>> cmds-check.c:1455 >>>> 1455 csum_end = key.offset + (size / csum_size) * root->sectorsize; >>>> (gdb) bt >>>> #0 count_csum_range (root=<optimized out>, root=<optimized out>, >>>> found=<synthetic pointer>, len=7385088, start=7471104) at >>>> cmds-check.c:1455 >>>> #1 process_file_extent (active_node=0x7fffffffd710, key=0x7fffffffd680, >>>> slot=11, eb=<optimized out>, root=0x894b10) at cmds-check.c:1551 >>>> #2 process_one_leaf (wc=0x7fffffffd6c0, eb=<optimized out>, >>>> root=0x894b10) >>>> at cmds-check.c:1617 >>>> #3 walk_down_tree (level=<synthetic pointer>, wc=0x7fffffffd6c0, >>>> path=0x7fffffffd7f0, root=0x894b10) at cmds-check.c:1742 >>>> #4 check_fs_root (wc=0x7fffffffd6c0, root_cache=0x7fffffffdb20, >>>> root=0x894b10) >>>> at cmds-check.c:3380 >>>> #5 check_fs_roots (root_cache=root_cache@entry=0x7fffffffdb20, >>>> root=0x894b10) >>>> at cmds-check.c:3516 >>>> #6 0x0000000000428aea in cmd_check (argc=<optimized out>, >>>> argv=<optimized out>) at cmds-check.c:9465 >>>> #7 0x000000000040e5a2 in main (argc=2, argv=0x7fffffffdeb0) at >>>> btrfs.c:245 >>>> (gdb) p csum_size >>>> $2 = 0 >>>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Carefully crafted BTRFS-image causes kernel to crash 2015-04-29 19:50 ` Lukas Lueg @ 2015-04-30 6:45 ` Duncan 0 siblings, 0 replies; 9+ messages in thread From: Duncan @ 2015-04-30 6:45 UTC (permalink / raw) To: linux-btrfs Lukas Lueg posted on Wed, 29 Apr 2015 21:50:23 +0200 as excerpted: > To give some context: Testing the userland tools to some depths comes > back with around 13 percent of all execution paths in around 40 million > runs to result in a segmentation fault, an uncatched divide-by-zero or > self-destruction due to a heap buffer overflow catched by glibc. That is > to be compared with zero crashes in the ext2fs userland tools. In a field of 40 million trinity fuzz tester runs, one out of eight btrfs- tools userspace runs crashed due to some abnormality, compared to 0 crashes for e2fsprogs. That's _very_ impressive for e2fs. I'm sure it's because people have been doing just that, beating on it with trinity and the like, for awhile, and the problems have been fixed already, but that makes it no less impressive. It takes both work and loving care to get to that point, and this demonstrates just how much of that it gets, to get to the _zero_ crash (in tens of millions of runs) point. Meanwhile, one of eight for btrfs-progs. Of course the focus has so far been pretty much on just getting the tools and basic functionality, so there's a reason, but it has a _long_ way to go from one of eight to _zero_ of 40-million! Just one more demonstration of the fact that btrfs really isn't and can't be called stable yet, even if from about a year ago they _have_ pretty well stripped all the warnings telling people that. Of course userspace is only the half of it, but _zero_ fuzzer crashes in 40 million runs... userspace or kernelspace regardless, that's quite some work showing off there, and they have a right to be proud of it. Btrfs would be so lucky! But your beating on it and Qu's fixup patches are a start at getting us there. Thanks! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-08-29 17:12 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-20 23:04 Carefully crafted BTRFS-image causes kernel to crash Lukas Lueg 2015-04-21 3:16 ` Qu Wenruo 2015-04-21 9:38 ` Russell Coker 2015-04-21 11:44 ` Austin S Hemmelgarn 2016-08-29 17:11 ` David Sterba 2015-04-21 15:17 ` Zygo Blaxell 2015-04-22 0:28 ` Qu Wenruo 2015-04-29 19:50 ` Lukas Lueg 2015-04-30 6:45 ` Duncan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.