* kasan behavior when built with unsupported compiler @ 2017-03-07 15:35 Nikolay Borisov 2017-03-07 15:54 ` Dmitry Vyukov 2017-03-07 16:23 ` Andrey Ryabinin 0 siblings, 2 replies; 16+ messages in thread From: Nikolay Borisov @ 2017-03-07 15:35 UTC (permalink / raw) To: aryabinin; +Cc: glider, Dmitry Vyukov, LKML Hello, I've been chasing a particular UAF as reported by kasan (https://www.spinics.net/lists/kernel/msg2458136.html). However, one thing which I took notice of rather lately is that I was building my kernel with gcc 4.7.4 which is not supported by kasan as indicated by the following string: scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: -fsanitize=kernel-address is not supported by compiler Nevertheless, the kernel compiles and when I boot it I see the kasan splats as per the referenced thread. If, however, I build the kernel with a newer compiler version 5.4.0 kasan no longer complains. At this point I'm wondering whether the splats can be due to old compiler being used e.g. false positives or are they genuine splats and gcc 5 somehow obfuscates them ? Clearly despite the warning about not being able to use CONFIG_KASAN it is still working since I'm seeing the splats. Is this valid behavior ? Regards, Nikolay ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-07 15:35 kasan behavior when built with unsupported compiler Nikolay Borisov @ 2017-03-07 15:54 ` Dmitry Vyukov 2017-03-07 16:05 ` Alexander Potapenko ` (2 more replies) 2017-03-07 16:23 ` Andrey Ryabinin 1 sibling, 3 replies; 16+ messages in thread From: Dmitry Vyukov @ 2017-03-07 15:54 UTC (permalink / raw) To: Nikolay Borisov Cc: Andrey Ryabinin, Alexander Potapenko, LKML, kasan-dev, Kees Cook On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov <n.borisov.lkml@gmail.com> wrote: > Hello, > > I've been chasing a particular UAF as reported by kasan > (https://www.spinics.net/lists/kernel/msg2458136.html). However, one > thing which I took notice of rather lately is that I was building my > kernel with gcc 4.7.4 which is not supported by kasan as indicated by > the following string: > > scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: > -fsanitize=kernel-address is not supported by compiler > > > Nevertheless, the kernel compiles and when I boot it I see the kasan > splats as per the referenced thread. If, however, I build the kernel > with a newer compiler version 5.4.0 kasan no longer complains. > > > At this point I'm wondering whether the splats can be due to old > compiler being used e.g. false positives or are they genuine splats and > gcc 5 somehow obfuscates them ? Clearly despite the warning about not > being able to use CONFIG_KASAN it is still working since I'm seeing the > splats. Is this valid behavior ? Hi, Re the message that kasan is not supported while it's still enabled in the end. I think it's an issue related to gcc plugins. Originally kasan was supported with 5.0+ thus the message. However, later we extended this support to 4.5+ with gcc plugins. However, that confusing message from build system was not fixed. So yes, it's confusing and it's something to fix, but mostly you can just ignore it. Re false positives with 4.7. By default I would assume that it is true positive. Should be easy to check with manual printfs. Re why 5.4 does not detect it. Difficult to say. If you confirm that it's a real bug and provide repro instructions, then I can recheck it with latest gcc. If it's a real bug and the latest gcc does not detect it, then we need to look more closely at it. I afraid 5.4 won't be fixed. It's also possible that it's a false positive in the old compiler (I think there were some bugs). If so, I would recommend switching to a newer compiler. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-07 15:54 ` Dmitry Vyukov @ 2017-03-07 16:05 ` Alexander Potapenko 2017-03-07 17:33 ` Nikolay Borisov 2017-03-07 16:26 ` Andrey Ryabinin 2017-03-08 8:10 ` Nikolay Borisov 2 siblings, 1 reply; 16+ messages in thread From: Alexander Potapenko @ 2017-03-07 16:05 UTC (permalink / raw) To: Dmitry Vyukov Cc: Nikolay Borisov, Andrey Ryabinin, LKML, kasan-dev, Kees Cook On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov <dvyukov@google.com> wrote: > On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov > <n.borisov.lkml@gmail.com> wrote: >> Hello, >> >> I've been chasing a particular UAF as reported by kasan >> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one >> thing which I took notice of rather lately is that I was building my >> kernel with gcc 4.7.4 which is not supported by kasan as indicated by >> the following string: >> >> scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: >> -fsanitize=kernel-address is not supported by compiler >> >> >> Nevertheless, the kernel compiles and when I boot it I see the kasan >> splats as per the referenced thread. If, however, I build the kernel >> with a newer compiler version 5.4.0 kasan no longer complains. >> >> >> At this point I'm wondering whether the splats can be due to old >> compiler being used e.g. false positives or are they genuine splats and >> gcc 5 somehow obfuscates them ? Clearly despite the warning about not >> being able to use CONFIG_KASAN it is still working since I'm seeing the >> splats. Is this valid behavior ? > > > Hi, > > Re the message that kasan is not supported while it's still enabled in the end. > I think it's an issue related to gcc plugins. Originally kasan was > supported with 5.0+ thus the message. However, later we extended this > support to 4.5+ with gcc plugins. However, that confusing message from > build system was not fixed. So yes, it's confusing and it's something > to fix, but mostly you can just ignore it. > > Re false positives with 4.7. By default I would assume that it is true > positive. Should be easy to check with manual printfs. > > Re why 5.4 does not detect it. Difficult to say. > If you confirm that it's a real bug and provide repro instructions, > then I can recheck it with latest gcc. If it's a real bug and the > latest gcc does not detect it, then we need to look more closely at > it. I afraid 5.4 won't be fixed. > It's also possible that it's a false positive in the old compiler (I > think there were some bugs). If so, I would recommend switching to a > newer compiler. I wonder if there's actual KASAN instrumentation in the kernel in question built with GCC 4.7. If there's none, there's little point in investigating this further, as the tool is anyway barely usable. Note that the report originates from something like copy_to_user() (or hard to tell the exact place - Nikolay, could you please symbolize the report?), i.e. it could be triggered even without KASAN instrumentation. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-07 16:05 ` Alexander Potapenko @ 2017-03-07 17:33 ` Nikolay Borisov 2017-03-07 17:51 ` Alexander Potapenko 0 siblings, 1 reply; 16+ messages in thread From: Nikolay Borisov @ 2017-03-07 17:33 UTC (permalink / raw) To: Alexander Potapenko, Dmitry Vyukov Cc: Andrey Ryabinin, LKML, kasan-dev, Kees Cook On 7.03.2017 18:05, Alexander Potapenko wrote: > On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov <dvyukov@google.com> wrote: >> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov >> <n.borisov.lkml@gmail.com> wrote: >>> Hello, >>> >>> I've been chasing a particular UAF as reported by kasan >>> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one >>> thing which I took notice of rather lately is that I was building my >>> kernel with gcc 4.7.4 which is not supported by kasan as indicated by >>> the following string: >>> >>> scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: >>> -fsanitize=kernel-address is not supported by compiler >>> >>> >>> Nevertheless, the kernel compiles and when I boot it I see the kasan >>> splats as per the referenced thread. If, however, I build the kernel >>> with a newer compiler version 5.4.0 kasan no longer complains. >>> >>> >>> At this point I'm wondering whether the splats can be due to old >>> compiler being used e.g. false positives or are they genuine splats and >>> gcc 5 somehow obfuscates them ? Clearly despite the warning about not >>> being able to use CONFIG_KASAN it is still working since I'm seeing the >>> splats. Is this valid behavior ? >> >> >> Hi, >> >> Re the message that kasan is not supported while it's still enabled in the end. >> I think it's an issue related to gcc plugins. Originally kasan was >> supported with 5.0+ thus the message. However, later we extended this >> support to 4.5+ with gcc plugins. However, that confusing message from >> build system was not fixed. So yes, it's confusing and it's something >> to fix, but mostly you can just ignore it. >> >> Re false positives with 4.7. By default I would assume that it is true >> positive. Should be easy to check with manual printfs. >> >> Re why 5.4 does not detect it. Difficult to say. >> If you confirm that it's a real bug and provide repro instructions, >> then I can recheck it with latest gcc. If it's a real bug and the >> latest gcc does not detect it, then we need to look more closely at >> it. I afraid 5.4 won't be fixed. >> It's also possible that it's a false positive in the old compiler (I >> think there were some bugs). If so, I would recommend switching to a >> newer compiler. > > I wonder if there's actual KASAN instrumentation in the kernel in > question built with GCC 4.7. > If there's none, there's little point in investigating this further, > as the tool is anyway barely usable. > Note that the report originates from something like copy_to_user() (or > hard to tell the exact place - Nikolay, could you please symbolize the > report?), i.e. it could be triggered even without KASAN > instrumentation. Of course there is kasan instrumentation, otherwise I won't see kasan reports, no ? I bisected this to commit 1771c6e1a567ea0ba2cc which adds user memory access API instrumentation. Here is a symbolized report: ================================================================== BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr ffff88006a22560e Read of size 20 by task systemd/1 ============================================================================= BUG kmalloc-96 (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1 [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 [< inline >] slab_alloc_node mm/slub.c:2538 [< inline >] slab_alloc mm/slub.c:2580 [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 [< inline >] kmalloc include/linux/slab.h:483 [< inline >] kzalloc include/linux/slab.h:622 [< none >] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447 [< none >] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Freed in ext4_ext_map_blocks+0x7f9/0x23e0 age=1 cpu=2 pid=1 [< none >] __slab_free+0x31b/0x440 mm/slub.c:2657 [< inline >] slab_free mm/slub.c:2810 [< none >] kfree+0x27f/0x2d0 mm/slub.c:3662 [< none >] ext4_ext_map_blocks+0x7f9/0x23e0 fs/ext4/extents.c:4619 [< none >] ext4_map_blocks+0x3b4/0x5b0 fs/ext4/inode.c:529 [< none >] ext4_getblk+0x54/0x1a0 fs/ext4/inode.c:929 [< none >] ext4_bread+0x13/0x90 fs/ext4/inode.c:979 [< none >] __ext4_read_dirblock+0x3f/0x380 fs/ext4/namei.c:99 [< none >] htree_dirblock_to_tree+0x48/0x190 fs/ext4/namei.c:959 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Slab 0xffffea0001a88900 objects=20 used=17 fp=0xffff88006a224e10 flags=0x4080 INFO: Object 0xffff88006a2255e0 @offset=5600 fp=0x45b282a2484c60d4 Bytes b4 ffff88006a2255d0: 02 00 00 00 01 00 00 00 c9 ac fb ff 00 00 00 00 ................ Object ffff88006a2255e0: d4 60 4c 48 a2 82 b2 45 18 8a 82 6a 00 88 ff ff .`LH...E...j.... Object ffff88006a2255f0: 38 51 22 6a 00 88 ff ff 88 8b 82 6a 00 88 ff ff 8Q"j.......j.... Object ffff88006a225600: 00 00 00 00 00 00 00 00 28 03 08 00 14 01 66 62 ........(.....fb Object ffff88006a225610: 64 65 76 2d 62 6c 61 63 6b 6c 69 73 74 2e 63 6f dev-blacklist.co Object ffff88006a225620: 6e 66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nf.............. Object ffff88006a225630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 2 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #171 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 ffff88006cd97c58 ffffffff8146bd4c ffff8800000946c0 ffff88006a2255e0 ffff88006cd97c88 ffffffff81198d96 ffff8800000946c0 ffffea0001a88900 ffff88006a2255e0 0000000000000000 ffff88006cd97cb0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 [< inline >] print_address_description mm/kasan/report.c:180 [< inline >] kasan_report_error mm/kasan/report.c:276 [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 [<ffffffff811a0041>] kasan_check_read+0x11/0x20 mm/kasan/kasan.c:304 [< inline >] copy_to_user ./arch/x86/include/asm/uaccess.h:760 [<ffffffff811ccc08>] filldir+0xc8/0x170 fs/readdir.c:195 [< inline >] dir_emit include/linux/fs.h:3134 [<ffffffff8124af38>] call_filldir+0x88/0x140 fs/ext4/dir.c:510 [< inline >] ext4_dx_readdir fs/ext4/dir.c:586 [<ffffffff8124b934>] ext4_readdir+0x714/0x950 fs/ext4/dir.c:121 [<ffffffff811ccd2d>] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [<ffffffff811ccf71>] SyS_getdents+0x91/0x120 fs/readdir.c:212 [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 Memory state around the buggy address: ffff88006a225500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a225580: fc fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 >ffff88006a225600: 00 00 00 00 05 fc fc fc fc fc fc fc fc fc fc fc ^ ffff88006a225680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a225700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc 00 00 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-07 17:33 ` Nikolay Borisov @ 2017-03-07 17:51 ` Alexander Potapenko 2017-03-07 20:24 ` Nikolay Borisov 0 siblings, 1 reply; 16+ messages in thread From: Alexander Potapenko @ 2017-03-07 17:51 UTC (permalink / raw) To: Nikolay Borisov Cc: Dmitry Vyukov, Andrey Ryabinin, LKML, kasan-dev, Kees Cook On Tue, Mar 7, 2017 at 6:33 PM, Nikolay Borisov <n.borisov.lkml@gmail.com> wrote: > > > On 7.03.2017 18:05, Alexander Potapenko wrote: >> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov <dvyukov@google.com> wrote: >>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov >>> <n.borisov.lkml@gmail.com> wrote: >>>> Hello, >>>> >>>> I've been chasing a particular UAF as reported by kasan >>>> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one >>>> thing which I took notice of rather lately is that I was building my >>>> kernel with gcc 4.7.4 which is not supported by kasan as indicated by >>>> the following string: >>>> >>>> scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: >>>> -fsanitize=kernel-address is not supported by compiler >>>> >>>> >>>> Nevertheless, the kernel compiles and when I boot it I see the kasan >>>> splats as per the referenced thread. If, however, I build the kernel >>>> with a newer compiler version 5.4.0 kasan no longer complains. >>>> >>>> >>>> At this point I'm wondering whether the splats can be due to old >>>> compiler being used e.g. false positives or are they genuine splats and >>>> gcc 5 somehow obfuscates them ? Clearly despite the warning about not >>>> being able to use CONFIG_KASAN it is still working since I'm seeing the >>>> splats. Is this valid behavior ? >>> >>> >>> Hi, >>> >>> Re the message that kasan is not supported while it's still enabled in the end. >>> I think it's an issue related to gcc plugins. Originally kasan was >>> supported with 5.0+ thus the message. However, later we extended this >>> support to 4.5+ with gcc plugins. However, that confusing message from >>> build system was not fixed. So yes, it's confusing and it's something >>> to fix, but mostly you can just ignore it. >>> >>> Re false positives with 4.7. By default I would assume that it is true >>> positive. Should be easy to check with manual printfs. >>> >>> Re why 5.4 does not detect it. Difficult to say. >>> If you confirm that it's a real bug and provide repro instructions, >>> then I can recheck it with latest gcc. If it's a real bug and the >>> latest gcc does not detect it, then we need to look more closely at >>> it. I afraid 5.4 won't be fixed. >>> It's also possible that it's a false positive in the old compiler (I >>> think there were some bugs). If so, I would recommend switching to a >>> newer compiler. >> >> I wonder if there's actual KASAN instrumentation in the kernel in >> question built with GCC 4.7. >> If there's none, there's little point in investigating this further, >> as the tool is anyway barely usable. >> Note that the report originates from something like copy_to_user() (or >> hard to tell the exact place - Nikolay, could you please symbolize the >> report?), i.e. it could be triggered even without KASAN >> instrumentation. > > Of course there is kasan instrumentation, otherwise I won't see kasan reports, no ? Not necessarily. There's KASAN instrumentation inserted by the compiler, and KASAN instrumentation added manually to the places the compiler can't instrument. > I bisected this to commit 1771c6e1a567ea0ba2cc which adds user memory access API Commit 1771c6e1a567ea0ba2cc added exactly these calls to check_memory_region() you are seeing. If there is any other instrumentation inserted by the compiler, it's possible that it may catch accesses to the same object (if something else except copy_to_user() is being done). Otherwise the only thing you can do to investigate this bug with GCC 4.7 is to bisect further by rolling to earlier revisions and applying 1771c6e1a567ea0ba2cc on top of them. I won't be surprised though if at some point the bisection may stop for a different reason. > instrumentation. Here is a symbolized report: > > ================================================================== > BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr ffff88006a22560e > Read of size 20 by task systemd/1 > ============================================================================= > BUG kmalloc-96 (Not tainted): kasan: bad access detected > ----------------------------------------------------------------------------- > > Disabling lock debugging due to kernel taint > INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1 > [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 > [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 > [< inline >] slab_alloc_node mm/slub.c:2538 > [< inline >] slab_alloc mm/slub.c:2580 > [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 > [< inline >] kmalloc include/linux/slab.h:483 > [< inline >] kzalloc include/linux/slab.h:622 > [< none >] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447 > [< none >] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001 > [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 > [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 > [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 > [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 > [< inline >] SYSC_getdents fs/readdir.c:230 > [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 > [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 > > INFO: Freed in ext4_ext_map_blocks+0x7f9/0x23e0 age=1 cpu=2 pid=1 > [< none >] __slab_free+0x31b/0x440 mm/slub.c:2657 > [< inline >] slab_free mm/slub.c:2810 > [< none >] kfree+0x27f/0x2d0 mm/slub.c:3662 > [< none >] ext4_ext_map_blocks+0x7f9/0x23e0 fs/ext4/extents.c:4619 > [< none >] ext4_map_blocks+0x3b4/0x5b0 fs/ext4/inode.c:529 > [< none >] ext4_getblk+0x54/0x1a0 fs/ext4/inode.c:929 > [< none >] ext4_bread+0x13/0x90 fs/ext4/inode.c:979 > [< none >] __ext4_read_dirblock+0x3f/0x380 fs/ext4/namei.c:99 > [< none >] htree_dirblock_to_tree+0x48/0x190 fs/ext4/namei.c:959 > [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 > [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 > [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 > [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 > [< inline >] SYSC_getdents fs/readdir.c:230 > [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 > [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 > INFO: Slab 0xffffea0001a88900 objects=20 used=17 fp=0xffff88006a224e10 flags=0x4080 > INFO: Object 0xffff88006a2255e0 @offset=5600 fp=0x45b282a2484c60d4 > > Bytes b4 ffff88006a2255d0: 02 00 00 00 01 00 00 00 c9 ac fb ff 00 00 00 00 ................ > Object ffff88006a2255e0: d4 60 4c 48 a2 82 b2 45 18 8a 82 6a 00 88 ff ff .`LH...E...j.... > Object ffff88006a2255f0: 38 51 22 6a 00 88 ff ff 88 8b 82 6a 00 88 ff ff 8Q"j.......j.... > Object ffff88006a225600: 00 00 00 00 00 00 00 00 28 03 08 00 14 01 66 62 ........(.....fb > Object ffff88006a225610: 64 65 76 2d 62 6c 61 63 6b 6c 69 73 74 2e 63 6f dev-blacklist.co > Object ffff88006a225620: 6e 66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nf.............. > Object ffff88006a225630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > CPU: 2 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #171 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 > 0000000000000000 ffff88006cd97c58 ffffffff8146bd4c ffff8800000946c0 > ffff88006a2255e0 ffff88006cd97c88 ffffffff81198d96 ffff8800000946c0 > ffffea0001a88900 ffff88006a2255e0 0000000000000000 ffff88006cd97cb0 > Call Trace: > [< inline >] __dump_stack lib/dump_stack.c:15 > [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 > [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 > [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 > [< inline >] print_address_description mm/kasan/report.c:180 > [< inline >] kasan_report_error mm/kasan/report.c:276 > [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 > [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 > [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 > [<ffffffff811a0041>] kasan_check_read+0x11/0x20 mm/kasan/kasan.c:304 > [< inline >] copy_to_user ./arch/x86/include/asm/uaccess.h:760 > [<ffffffff811ccc08>] filldir+0xc8/0x170 fs/readdir.c:195 > [< inline >] dir_emit include/linux/fs.h:3134 > [<ffffffff8124af38>] call_filldir+0x88/0x140 fs/ext4/dir.c:510 > [< inline >] ext4_dx_readdir fs/ext4/dir.c:586 > [<ffffffff8124b934>] ext4_readdir+0x714/0x950 fs/ext4/dir.c:121 > [<ffffffff811ccd2d>] iterate_dir+0x7d/0x190 fs/readdir.c:50 > [< inline >] SYSC_getdents fs/readdir.c:230 > [<ffffffff811ccf71>] SyS_getdents+0x91/0x120 fs/readdir.c:212 > [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 > Memory state around the buggy address: > ffff88006a225500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff88006a225580: fc fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 >>ffff88006a225600: 00 00 00 00 05 fc fc fc fc fc fc fc fc fc fc fc > ^ > ffff88006a225680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff88006a225700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc 00 00 I think I've seen relevant reports on the Chrome OS 3.14/3.18 kernel with Clang and GCC 6.0.0. I never managed to reproduce those reliably, they would always go away every time I tried to catch them. You can try enabling some of the ext4 debug checks, but I still think it won't help much as long as you're using an unsupported compiler. -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-07 17:51 ` Alexander Potapenko @ 2017-03-07 20:24 ` Nikolay Borisov 0 siblings, 0 replies; 16+ messages in thread From: Nikolay Borisov @ 2017-03-07 20:24 UTC (permalink / raw) To: Alexander Potapenko Cc: Dmitry Vyukov, Andrey Ryabinin, LKML, kasan-dev, Kees Cook [-- Attachment #1: Type: text/plain, Size: 10526 bytes --] On 7.03.2017 19:51, Alexander Potapenko wrote: > On Tue, Mar 7, 2017 at 6:33 PM, Nikolay Borisov > <n.borisov.lkml@gmail.com> wrote: >> >> >> On 7.03.2017 18:05, Alexander Potapenko wrote: >>> On Tue, Mar 7, 2017 at 4:54 PM, Dmitry Vyukov <dvyukov@google.com> wrote: >>>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov >>>> <n.borisov.lkml@gmail.com> wrote: >>>>> Hello, >>>>> >>>>> I've been chasing a particular UAF as reported by kasan >>>>> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one >>>>> thing which I took notice of rather lately is that I was building my >>>>> kernel with gcc 4.7.4 which is not supported by kasan as indicated by >>>>> the following string: >>>>> >>>>> scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: >>>>> -fsanitize=kernel-address is not supported by compiler >>>>> >>>>> >>>>> Nevertheless, the kernel compiles and when I boot it I see the kasan >>>>> splats as per the referenced thread. If, however, I build the kernel >>>>> with a newer compiler version 5.4.0 kasan no longer complains. >>>>> >>>>> >>>>> At this point I'm wondering whether the splats can be due to old >>>>> compiler being used e.g. false positives or are they genuine splats and >>>>> gcc 5 somehow obfuscates them ? Clearly despite the warning about not >>>>> being able to use CONFIG_KASAN it is still working since I'm seeing the >>>>> splats. Is this valid behavior ? >>>> >>>> >>>> Hi, >>>> >>>> Re the message that kasan is not supported while it's still enabled in the end. >>>> I think it's an issue related to gcc plugins. Originally kasan was >>>> supported with 5.0+ thus the message. However, later we extended this >>>> support to 4.5+ with gcc plugins. However, that confusing message from >>>> build system was not fixed. So yes, it's confusing and it's something >>>> to fix, but mostly you can just ignore it. >>>> >>>> Re false positives with 4.7. By default I would assume that it is true >>>> positive. Should be easy to check with manual printfs. >>>> >>>> Re why 5.4 does not detect it. Difficult to say. >>>> If you confirm that it's a real bug and provide repro instructions, >>>> then I can recheck it with latest gcc. If it's a real bug and the >>>> latest gcc does not detect it, then we need to look more closely at >>>> it. I afraid 5.4 won't be fixed. >>>> It's also possible that it's a false positive in the old compiler (I >>>> think there were some bugs). If so, I would recommend switching to a >>>> newer compiler. >>> >>> I wonder if there's actual KASAN instrumentation in the kernel in >>> question built with GCC 4.7. >>> If there's none, there's little point in investigating this further, >>> as the tool is anyway barely usable. >>> Note that the report originates from something like copy_to_user() (or >>> hard to tell the exact place - Nikolay, could you please symbolize the >>> report?), i.e. it could be triggered even without KASAN >>> instrumentation. >> >> Of course there is kasan instrumentation, otherwise I won't see kasan reports, no ? > Not necessarily. > There's KASAN instrumentation inserted by the compiler, and KASAN > instrumentation added manually to the places the compiler can't > instrument. >> I bisected this to commit 1771c6e1a567ea0ba2cc which adds user memory access API > Commit 1771c6e1a567ea0ba2cc added exactly these calls to > check_memory_region() you are seeing. > If there is any other instrumentation inserted by the compiler, it's > possible that it may catch accesses to the same object (if something > else except copy_to_user() is being done). > Otherwise the only thing you can do to investigate this bug with GCC > 4.7 is to bisect further by rolling to earlier revisions and applying > 1771c6e1a567ea0ba2cc on top of them. > I won't be surprised though if at some point the bisection may stop > for a different reason. >> instrumentation. Here is a symbolized report: >> >> ================================================================== >> BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr ffff88006a22560e >> Read of size 20 by task systemd/1 >> ============================================================================= >> BUG kmalloc-96 (Not tainted): kasan: bad access detected >> ----------------------------------------------------------------------------- >> >> Disabling lock debugging due to kernel taint >> INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1 >> [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 >> [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 >> [< inline >] slab_alloc_node mm/slub.c:2538 >> [< inline >] slab_alloc mm/slub.c:2580 >> [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 >> [< inline >] kmalloc include/linux/slab.h:483 >> [< inline >] kzalloc include/linux/slab.h:622 >> [< none >] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447 >> [< none >] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001 >> [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 >> [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 >> [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 >> [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 >> [< inline >] SYSC_getdents fs/readdir.c:230 >> [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 >> [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 >> >> INFO: Freed in ext4_ext_map_blocks+0x7f9/0x23e0 age=1 cpu=2 pid=1 >> [< none >] __slab_free+0x31b/0x440 mm/slub.c:2657 >> [< inline >] slab_free mm/slub.c:2810 >> [< none >] kfree+0x27f/0x2d0 mm/slub.c:3662 >> [< none >] ext4_ext_map_blocks+0x7f9/0x23e0 fs/ext4/extents.c:4619 >> [< none >] ext4_map_blocks+0x3b4/0x5b0 fs/ext4/inode.c:529 >> [< none >] ext4_getblk+0x54/0x1a0 fs/ext4/inode.c:929 >> [< none >] ext4_bread+0x13/0x90 fs/ext4/inode.c:979 >> [< none >] __ext4_read_dirblock+0x3f/0x380 fs/ext4/namei.c:99 >> [< none >] htree_dirblock_to_tree+0x48/0x190 fs/ext4/namei.c:959 >> [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 >> [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 >> [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 >> [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 >> [< inline >] SYSC_getdents fs/readdir.c:230 >> [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 >> [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 >> INFO: Slab 0xffffea0001a88900 objects=20 used=17 fp=0xffff88006a224e10 flags=0x4080 >> INFO: Object 0xffff88006a2255e0 @offset=5600 fp=0x45b282a2484c60d4 >> >> Bytes b4 ffff88006a2255d0: 02 00 00 00 01 00 00 00 c9 ac fb ff 00 00 00 00 ................ >> Object ffff88006a2255e0: d4 60 4c 48 a2 82 b2 45 18 8a 82 6a 00 88 ff ff .`LH...E...j.... >> Object ffff88006a2255f0: 38 51 22 6a 00 88 ff ff 88 8b 82 6a 00 88 ff ff 8Q"j.......j.... >> Object ffff88006a225600: 00 00 00 00 00 00 00 00 28 03 08 00 14 01 66 62 ........(.....fb >> Object ffff88006a225610: 64 65 76 2d 62 6c 61 63 6b 6c 69 73 74 2e 63 6f dev-blacklist.co >> Object ffff88006a225620: 6e 66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nf.............. >> Object ffff88006a225630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ >> CPU: 2 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #171 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 >> 0000000000000000 ffff88006cd97c58 ffffffff8146bd4c ffff8800000946c0 >> ffff88006a2255e0 ffff88006cd97c88 ffffffff81198d96 ffff8800000946c0 >> ffffea0001a88900 ffff88006a2255e0 0000000000000000 ffff88006cd97cb0 >> Call Trace: >> [< inline >] __dump_stack lib/dump_stack.c:15 >> [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 >> [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 >> [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 >> [< inline >] print_address_description mm/kasan/report.c:180 >> [< inline >] kasan_report_error mm/kasan/report.c:276 >> [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 >> [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 >> [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 >> [<ffffffff811a0041>] kasan_check_read+0x11/0x20 mm/kasan/kasan.c:304 >> [< inline >] copy_to_user ./arch/x86/include/asm/uaccess.h:760 >> [<ffffffff811ccc08>] filldir+0xc8/0x170 fs/readdir.c:195 >> [< inline >] dir_emit include/linux/fs.h:3134 >> [<ffffffff8124af38>] call_filldir+0x88/0x140 fs/ext4/dir.c:510 >> [< inline >] ext4_dx_readdir fs/ext4/dir.c:586 >> [<ffffffff8124b934>] ext4_readdir+0x714/0x950 fs/ext4/dir.c:121 >> [<ffffffff811ccd2d>] iterate_dir+0x7d/0x190 fs/readdir.c:50 >> [< inline >] SYSC_getdents fs/readdir.c:230 >> [<ffffffff811ccf71>] SyS_getdents+0x91/0x120 fs/readdir.c:212 >> [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 >> Memory state around the buggy address: >> ffff88006a225500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> ffff88006a225580: fc fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 >>> ffff88006a225600: 00 00 00 00 05 fc fc fc fc fc fc fc fc fc fc fc >> ^ >> ffff88006a225680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >> ffff88006a225700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc 00 00 > > I think I've seen relevant reports on the Chrome OS 3.14/3.18 kernel > with Clang and GCC 6.0.0. > I never managed to reproduce those reliably, they would always go away > every time I tried to catch them. > You can try enabling some of the ext4 debug checks, but I still think > it won't help much as long as you're using an unsupported compiler. > > I'm also attaching other kasan reports that follow the first one from the same boot. It's very strange since there are buffer allocated in ext4 readdir and freed even in the virtio buffer management code. That's also rather odd. I also backported 64f8ebaf115bcddc4 and 1771c6e1a567ea0 to 4.6 and still see similar splats. Tried applying those patches to 4.5 however, it seems there are other pieces of code missing to make kasan work for that version. [-- Attachment #2: kasan_symbolized.txt --] [-- Type: text/plain, Size: 38735 bytes --] ================================================================== BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr ffff88006a22560e Read of size 20 by task systemd/1 ============================================================================= BUG kmalloc-96 (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=3 cpu=1 pid=1 [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 [< inline >] slab_alloc_node mm/slub.c:2538 [< inline >] slab_alloc mm/slub.c:2580 [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 [< inline >] kmalloc include/linux/slab.h:483 [< inline >] kzalloc include/linux/slab.h:622 [< none >] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447 [< none >] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Freed in ext4_ext_map_blocks+0x7f9/0x23e0 age=6 cpu=1 pid=1 [< none >] __slab_free+0x31b/0x440 mm/slub.c:2657 [< inline >] slab_free mm/slub.c:2810 [< none >] kfree+0x27f/0x2d0 mm/slub.c:3662 [< none >] ext4_ext_map_blocks+0x7f9/0x23e0 fs/ext4/extents.c:4619 [< none >] ext4_map_blocks+0x3b4/0x5b0 fs/ext4/inode.c:529 [< none >] ext4_getblk+0x54/0x1a0 fs/ext4/inode.c:929 [< none >] ext4_bread+0x13/0x90 fs/ext4/inode.c:979 [< none >] __ext4_read_dirblock+0x3f/0x380 fs/ext4/namei.c:99 [< none >] htree_dirblock_to_tree+0x48/0x190 fs/ext4/namei.c:959 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Slab 0xffffea0001a88900 objects=20 used=17 fp=0xffff88006a224c80 flags=0x4080 INFO: Object 0xffff88006a2255e0 @offset=5600 fp=0x45b282a2484c60d4 Bytes b4 ffff88006a2255d0: 01 00 00 00 01 00 00 00 6e b0 fb ff 00 00 00 00 ........n....... Object ffff88006a2255e0: d4 60 4c 48 a2 82 b2 45 88 8b 82 6a 00 88 ff ff .`LH...E...j.... Object ffff88006a2255f0: 38 51 22 6a 00 88 ff ff 78 98 82 6a 00 88 ff ff 8Q"j....x..j.... Object ffff88006a225600: 00 00 00 00 00 00 00 00 28 03 08 00 14 01 66 62 ........(.....fb Object ffff88006a225610: 64 65 76 2d 62 6c 61 63 6b 6c 69 73 74 2e 63 6f dev-blacklist.co Object ffff88006a225620: 6e 66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nf.............. Object ffff88006a225630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 1 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #188 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 ffff88006cd97c58 ffffffff8146bd4c ffff8800000946c0 ffff88006a2255e0 ffff88006cd97c88 ffffffff81198d96 ffff8800000946c0 ffffea0001a88900 ffff88006a2255e0 0000000000000000 ffff88006cd97cb0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 [< inline >] print_address_description mm/kasan/report.c:180 [< inline >] kasan_report_error mm/kasan/report.c:276 [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 [<ffffffff811a0041>] kasan_check_read+0x11/0x20 mm/kasan/kasan.c:304 [< inline >] copy_to_user ./arch/x86/include/asm/uaccess.h:760 [<ffffffff811ccc08>] filldir+0xc8/0x170 fs/readdir.c:195 [< inline >] dir_emit include/linux/fs.h:3134 [<ffffffff8124af38>] call_filldir+0x88/0x140 fs/ext4/dir.c:510 [< inline >] ext4_dx_readdir fs/ext4/dir.c:586 [<ffffffff8124b934>] ext4_readdir+0x714/0x950 fs/ext4/dir.c:121 [<ffffffff811ccd2d>] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [<ffffffff811ccf71>] SyS_getdents+0x91/0x120 fs/readdir.c:212 [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 Memory state around the buggy address: ffff88006a225500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a225580: fc fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 >ffff88006a225600: 00 00 00 00 05 fc fc fc fc fc fc fc fc fc fc fc ^ ffff88006a225680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a225700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc 00 00 ================================================================== ================================================================== BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr ffff88006a224e3e Read of size 27 by task systemd/1 ============================================================================= BUG kmalloc-96 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=39 cpu=1 pid=1 [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 [< inline >] slab_alloc_node mm/slub.c:2538 [< inline >] slab_alloc mm/slub.c:2580 [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 [< inline >] kmalloc include/linux/slab.h:483 [< inline >] kzalloc include/linux/slab.h:622 [< none >] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447 [< none >] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Slab 0xffffea0001a88900 objects=20 used=17 fp=0xffff88006a224c80 flags=0x4080 INFO: Object 0xffff88006a224e10 @offset=3600 fp=0x3a131cf85779a612 Bytes b4 ffff88006a224e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a224e10: 12 a6 79 57 f8 1c 13 3a 38 51 22 6a 00 88 ff ff ..yW...:8Q"j.... Object ffff88006a224e20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a224e30: 00 00 00 00 00 00 00 00 8e 02 08 00 1b 01 62 6c ..............bl Object ffff88006a224e40: 61 63 6b 6c 69 73 74 2d 72 61 72 65 2d 6e 65 74 acklist-rare-net Object ffff88006a224e50: 77 6f 72 6b 2e 63 6f 6e 66 00 00 00 00 00 00 00 work.conf....... Object ffff88006a224e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 1 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #188 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 ffff88006cd97c58 ffffffff8146bd4c ffff8800000946c0 ffff88006a224e10 ffff88006cd97c88 ffffffff81198d96 ffff8800000946c0 ffffea0001a88900 ffff88006a224e10 0000000000000000 ffff88006cd97cb0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 [< inline >] print_address_description mm/kasan/report.c:180 [< inline >] kasan_report_error mm/kasan/report.c:276 [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 [<ffffffff811a0041>] kasan_check_read+0x11/0x20 mm/kasan/kasan.c:304 [< inline >] copy_to_user ./arch/x86/include/asm/uaccess.h:760 [<ffffffff811ccc08>] filldir+0xc8/0x170 fs/readdir.c:195 [< inline >] dir_emit include/linux/fs.h:3134 [<ffffffff8124af38>] call_filldir+0x88/0x140 fs/ext4/dir.c:510 [< inline >] ext4_dx_readdir fs/ext4/dir.c:586 [<ffffffff8124b934>] ext4_readdir+0x714/0x950 fs/ext4/dir.c:121 [<ffffffff811ccd2d>] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [<ffffffff811ccf71>] SyS_getdents+0x91/0x120 fs/readdir.c:212 [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 Memory state around the buggy address: ffff88006a224d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a224d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88006a224e00: fc fc 00 00 00 00 00 00 00 00 00 04 fc fc fc fc ^ ffff88006a224e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a224f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== ================================================================== BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr ffff88006a22547e Read of size 22 by task systemd/1 ============================================================================= BUG kmalloc-96 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=66 cpu=1 pid=1 [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 [< inline >] slab_alloc_node mm/slub.c:2538 [< inline >] slab_alloc mm/slub.c:2580 [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 [< inline >] kmalloc include/linux/slab.h:483 [< inline >] kzalloc include/linux/slab.h:622 [< none >] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447 [< none >] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Freed in detach_buf+0x95/0xb0 age=120 cpu=1 pid=1 [< none >] __slab_free+0x31b/0x440 mm/slub.c:2657 [< inline >] slab_free mm/slub.c:2810 [< none >] kfree+0x27f/0x2d0 mm/slub.c:3662 [< none >] detach_buf+0x95/0xb0 drivers/virtio/virtio_ring.c:623 [< none >] virtqueue_get_buf+0x72/0x100 drivers/virtio/virtio_ring.c:687 [< none >] virtblk_done+0x79/0xe0 drivers/block/virtio_blk.c:146 [< none >] vring_interrupt+0x31/0x50 drivers/virtio/virtio_ring.c:892 [< none >] handle_irq_event_percpu+0x77/0x370 kernel/irq/handle.c:145 [< none >] handle_irq_event+0x44/0x70 kernel/irq/handle.c:192 [< none >] handle_edge_irq+0xa7/0x130 kernel/irq/chip.c:623 [< inline >] generic_handle_irq_desc include/linux/irqdesc.h:147 [< none >] handle_irq+0x1d/0x30 arch/x86/kernel/irq_64.c:78 do_IRQ+0x72/0x140 [< none >] ret_from_intr+0x0/0x20 arch/x86/entry/entry_64.S:482 [< inline >] slab_alloc_node mm/slub.c:2538 [< inline >] slab_alloc mm/slub.c:2580 [< none >] kmem_cache_alloc+0x229/0x2d0 mm/slub.c:2585 [< none >] mempool_alloc_slab+0x15/0x20 mm/mempool.c:461 [< none >] mempool_alloc+0x7a/0x190 mm/mempool.c:340 [< none >] bio_alloc_bioset+0x107/0x1e0 block/bio.c:469 INFO: Slab 0xffffea0001a88900 objects=20 used=17 fp=0xffff88006a224c80 flags=0x4080 INFO: Object 0xffff88006a225450 @offset=5200 fp=0x6d74c0b2854baae8 Bytes b4 ffff88006a225440: 01 00 00 00 01 00 00 00 6e b0 fb ff 00 00 00 00 ........n....... Object ffff88006a225450: e8 aa 4b 85 b2 c0 74 6d 38 51 22 6a 00 88 ff ff ..K...tm8Q"j.... Object ffff88006a225460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a225470: 00 00 00 00 00 00 00 00 92 02 08 00 16 01 62 6c ..............bl Object ffff88006a225480: 61 63 6b 6c 69 73 74 2d 61 74 68 5f 70 63 69 2e acklist-ath_pci. Object ffff88006a225490: 63 6f 6e 66 00 00 00 00 00 00 00 00 00 00 00 00 conf............ Object ffff88006a2254a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 1 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #188 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 ffff88006cd97c58 ffffffff8146bd4c ffff8800000946c0 ffff88006a225450 ffff88006cd97c88 ffffffff81198d96 ffff8800000946c0 ffffea0001a88900 ffff88006a225450 0000000000000000 ffff88006cd97cb0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 [< inline >] print_address_description mm/kasan/report.c:180 [< inline >] kasan_report_error mm/kasan/report.c:276 [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 [<ffffffff811a0041>] kasan_check_read+0x11/0x20 mm/kasan/kasan.c:304 [< inline >] copy_to_user ./arch/x86/include/asm/uaccess.h:760 [<ffffffff811ccc08>] filldir+0xc8/0x170 fs/readdir.c:195 [< inline >] dir_emit include/linux/fs.h:3134 [<ffffffff8124af38>] call_filldir+0x88/0x140 fs/ext4/dir.c:510 [< inline >] ext4_dx_readdir fs/ext4/dir.c:586 [<ffffffff8124b934>] ext4_readdir+0x714/0x950 fs/ext4/dir.c:121 [<ffffffff811ccd2d>] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [<ffffffff811ccf71>] SyS_getdents+0x91/0x120 fs/readdir.c:212 [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 Memory state around the buggy address: ffff88006a225380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a225400: fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00 00 >ffff88006a225480: 00 00 07 fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88006a225500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a225580: fc fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 ================================================================== ================================================================== BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr ffff88006a828e8e Read of size 14 by task systemd/1 ============================================================================= BUG kmalloc-64 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=102 cpu=1 pid=1 [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 [< inline >] slab_alloc_node mm/slub.c:2538 [< inline >] slab_alloc mm/slub.c:2580 [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 [< inline >] kmalloc include/linux/slab.h:483 [< inline >] kzalloc include/linux/slab.h:622 [< none >] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447 [< none >] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Freed in detach_buf+0x95/0xb0 age=130 cpu=0 pid=0 [< none >] __slab_free+0x31b/0x440 mm/slub.c:2657 [< inline >] slab_free mm/slub.c:2810 [< none >] kfree+0x27f/0x2d0 mm/slub.c:3662 [< none >] detach_buf+0x95/0xb0 drivers/virtio/virtio_ring.c:623 [< none >] virtqueue_get_buf+0x72/0x100 drivers/virtio/virtio_ring.c:687 [< none >] virtblk_done+0x79/0xe0 drivers/block/virtio_blk.c:146 [< none >] vring_interrupt+0x31/0x50 drivers/virtio/virtio_ring.c:892 [< none >] handle_irq_event_percpu+0x77/0x370 kernel/irq/handle.c:145 [< none >] handle_irq_event+0x44/0x70 kernel/irq/handle.c:192 [< none >] handle_edge_irq+0xa7/0x130 kernel/irq/chip.c:623 [< inline >] generic_handle_irq_desc include/linux/irqdesc.h:147 [< none >] handle_irq+0x1d/0x30 arch/x86/kernel/irq_64.c:78 do_IRQ+0x72/0x140 [< none >] ret_from_intr+0x0/0x20 arch/x86/entry/entry_64.S:482 [< inline >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:107 [< none >] default_idle+0x23/0x180 arch/x86/kernel/process.c:306 [< none >] arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:297 [< none >] default_idle_call+0x2f/0x50 kernel/sched/idle.c:93 [< inline >] cpuidle_idle_call kernel/sched/idle.c:151 [< inline >] cpu_idle_loop kernel/sched/idle.c:242 [< none >] cpu_startup_entry+0x2d6/0x410 kernel/sched/idle.c:291 INFO: Slab 0xffffea0001aa0a00 objects=22 used=16 fp=0xffff88006a8285c0 flags=0x4080 INFO: Object 0xffff88006a828e60 @offset=3680 fp=0x943db016b8e469b2 Bytes b4 ffff88006a828e50: 00 00 00 00 00 00 00 00 8f b0 fb ff 00 00 00 00 ................ Object ffff88006a828e60: b2 69 e4 b8 16 b0 3d 94 28 94 82 6a 00 88 ff ff .i....=.(..j.... Object ffff88006a828e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a828e80: 00 00 00 00 00 00 00 00 8f 02 08 00 0e 01 62 6c ..............bl Object ffff88006a828e90: 61 63 6b 6c 69 73 74 2e 63 6f 6e 66 00 00 00 00 acklist.conf.... CPU: 1 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #188 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 ffff88006cd97c58 ffffffff8146bd4c ffff880000097840 ffff88006a828e60 ffff88006cd97c88 ffffffff81198d96 ffff880000097840 ffffea0001aa0a00 ffff88006a828e60 0000000000000000 ffff88006cd97cb0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 [< inline >] print_address_description mm/kasan/report.c:180 [< inline >] kasan_report_error mm/kasan/report.c:276 [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 [<ffffffff811a0041>] kasan_check_read+0x11/0x20 mm/kasan/kasan.c:304 [< inline >] copy_to_user ./arch/x86/include/asm/uaccess.h:760 [<ffffffff811ccc08>] filldir+0xc8/0x170 fs/readdir.c:195 [< inline >] dir_emit include/linux/fs.h:3134 [<ffffffff8124af38>] call_filldir+0x88/0x140 fs/ext4/dir.c:510 [< inline >] ext4_dx_readdir fs/ext4/dir.c:586 [<ffffffff8124b934>] ext4_readdir+0x714/0x950 fs/ext4/dir.c:121 [<ffffffff811ccd2d>] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [<ffffffff811ccf71>] SyS_getdents+0x91/0x120 fs/readdir.c:212 [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 Memory state around the buggy address: ffff88006a828d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a828e00: fc fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 >ffff88006a828e80: 00 00 00 07 fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88006a828f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a828f80: fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00 fc ================================================================== ================================================================== BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr ffff88006a82944e Read of size 12 by task systemd/1 ============================================================================= BUG kmalloc-64 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=135 cpu=1 pid=1 [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 [< inline >] slab_alloc_node mm/slub.c:2538 [< inline >] slab_alloc mm/slub.c:2580 [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 [< inline >] kmalloc include/linux/slab.h:483 [< inline >] kzalloc include/linux/slab.h:622 [< none >] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447 [< none >] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Freed in detach_buf+0x95/0xb0 age=153 cpu=2 pid=0 [< none >] __slab_free+0x31b/0x440 mm/slub.c:2657 [< inline >] slab_free mm/slub.c:2810 [< none >] kfree+0x27f/0x2d0 mm/slub.c:3662 [< none >] detach_buf+0x95/0xb0 drivers/virtio/virtio_ring.c:623 [< none >] virtqueue_get_buf+0x72/0x100 drivers/virtio/virtio_ring.c:687 [< none >] virtblk_done+0x79/0xe0 drivers/block/virtio_blk.c:146 [< none >] vring_interrupt+0x31/0x50 drivers/virtio/virtio_ring.c:892 [< none >] handle_irq_event_percpu+0x77/0x370 kernel/irq/handle.c:145 [< none >] handle_irq_event+0x44/0x70 kernel/irq/handle.c:192 [< none >] handle_edge_irq+0xa7/0x130 kernel/irq/chip.c:623 [< inline >] generic_handle_irq_desc include/linux/irqdesc.h:147 [< none >] handle_irq+0x1d/0x30 arch/x86/kernel/irq_64.c:78 do_IRQ+0x72/0x140 [< none >] ret_from_intr+0x0/0x20 arch/x86/entry/entry_64.S:482 [< inline >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:107 [< none >] default_idle+0x23/0x180 arch/x86/kernel/process.c:306 [< none >] arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:297 [< none >] default_idle_call+0x2f/0x50 kernel/sched/idle.c:93 [< inline >] cpuidle_idle_call kernel/sched/idle.c:151 [< inline >] cpu_idle_loop kernel/sched/idle.c:242 [< none >] cpu_startup_entry+0x2d6/0x410 kernel/sched/idle.c:291 INFO: Slab 0xffffea0001aa0a00 objects=22 used=16 fp=0xffff88006a8285c0 flags=0x4080 INFO: Object 0xffff88006a829420 @offset=5152 fp=0xfb71dea2cae00e56 Bytes b4 ffff88006a829410: 02 00 00 00 00 00 00 00 8d b0 fb ff 00 00 00 00 ................ Object ffff88006a829420: 56 0e e0 ca a2 de 71 fb f9 8c 82 6a 00 88 ff ff V.....q....j.... Object ffff88006a829430: 00 00 00 00 00 00 00 00 68 8e 82 6a 00 88 ff ff ........h..j.... Object ffff88006a829440: 00 00 00 00 00 00 00 00 91 02 08 00 0c 01 69 77 ..............iw Object ffff88006a829450: 6c 77 69 66 69 2e 63 6f 6e 66 00 00 00 00 00 00 lwifi.conf...... CPU: 1 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #188 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 ffff88006cd97c58 ffffffff8146bd4c ffff880000097840 ffff88006a829420 ffff88006cd97c88 ffffffff81198d96 ffff880000097840 ffffea0001aa0a00 ffff88006a829420 0000000000000000 ffff88006cd97cb0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 [< inline >] print_address_description mm/kasan/report.c:180 [< inline >] kasan_report_error mm/kasan/report.c:276 [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 [<ffffffff811a0041>] kasan_check_read+0x11/0x20 mm/kasan/kasan.c:304 [< inline >] copy_to_user ./arch/x86/include/asm/uaccess.h:760 [<ffffffff811ccc08>] filldir+0xc8/0x170 fs/readdir.c:195 [< inline >] dir_emit include/linux/fs.h:3134 [<ffffffff8124af38>] call_filldir+0x88/0x140 fs/ext4/dir.c:510 [< inline >] ext4_dx_readdir fs/ext4/dir.c:586 [<ffffffff8124b934>] ext4_readdir+0x714/0x950 fs/ext4/dir.c:121 [<ffffffff811ccd2d>] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [<ffffffff811ccf71>] SyS_getdents+0x91/0x120 fs/readdir.c:212 [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 Memory state around the buggy address: ffff88006a829300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a829380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88006a829400: fc fc fc fc 00 00 00 00 00 00 00 05 fc fc fc fc ^ ffff88006a829480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a829500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== ================================================================== BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr ffff88006a82847e Read of size 12 by task systemd/1 ============================================================================= BUG kmalloc-64 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=3 cpu=1 pid=1 [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 [< inline >] slab_alloc_node mm/slub.c:2538 [< inline >] slab_alloc mm/slub.c:2580 [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 [< inline >] kmalloc include/linux/slab.h:483 [< inline >] kzalloc include/linux/slab.h:622 [< none >] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447 [< none >] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Freed in detach_buf+0x95/0xb0 age=188 cpu=0 pid=0 [< none >] __slab_free+0x31b/0x440 mm/slub.c:2657 [< inline >] slab_free mm/slub.c:2810 [< none >] kfree+0x27f/0x2d0 mm/slub.c:3662 [< none >] detach_buf+0x95/0xb0 drivers/virtio/virtio_ring.c:623 [< none >] virtqueue_get_buf+0x72/0x100 drivers/virtio/virtio_ring.c:687 [< none >] virtblk_done+0x79/0xe0 drivers/block/virtio_blk.c:146 [< none >] vring_interrupt+0x31/0x50 drivers/virtio/virtio_ring.c:892 [< none >] handle_irq_event_percpu+0x77/0x370 kernel/irq/handle.c:145 [< none >] handle_irq_event+0x44/0x70 kernel/irq/handle.c:192 [< none >] handle_edge_irq+0xa7/0x130 kernel/irq/chip.c:623 [< inline >] generic_handle_irq_desc include/linux/irqdesc.h:147 [< none >] handle_irq+0x1d/0x30 arch/x86/kernel/irq_64.c:78 do_IRQ+0x72/0x140 [< none >] ret_from_intr+0x0/0x20 arch/x86/entry/entry_64.S:482 [< inline >] arch_safe_halt ./arch/x86/include/asm/paravirt.h:107 [< none >] default_idle+0x23/0x180 arch/x86/kernel/process.c:306 [< none >] arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:297 [< none >] default_idle_call+0x2f/0x50 kernel/sched/idle.c:93 [< inline >] cpuidle_idle_call kernel/sched/idle.c:151 [< inline >] cpu_idle_loop kernel/sched/idle.c:242 [< none >] cpu_startup_entry+0x2d6/0x410 kernel/sched/idle.c:291 INFO: Slab 0xffffea0001aa0a00 objects=22 used=14 fp=0xffff88006a829420 flags=0x4080 INFO: Object 0xffff88006a828450 @offset=1104 fp=0xe6c5cd51031211fc Bytes b4 ffff88006a828440: 02 00 00 00 2b 00 00 00 ae ad fb ff 00 00 00 00 ....+........... Object ffff88006a828450: fc 11 12 03 51 cd c5 e6 88 8b 82 6a 00 88 ff ff ....Q......j.... Object ffff88006a828460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a828470: 00 00 00 00 00 00 00 00 84 03 08 00 0c 01 61 6c ..............al Object ffff88006a828480: 69 61 73 65 73 2e 63 6f 6e 66 00 00 00 00 00 00 iases.conf...... CPU: 1 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #188 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 ffff88006cd97c58 ffffffff8146bd4c ffff880000097840 ffff88006a828450 ffff88006cd97c88 ffffffff81198d96 ffff880000097840 ffffea0001aa0a00 ffff88006a828450 0000000000000000 ffff88006cd97cb0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 [< inline >] print_address_description mm/kasan/report.c:180 [< inline >] kasan_report_error mm/kasan/report.c:276 [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 [<ffffffff811a0041>] kasan_check_read+0x11/0x20 mm/kasan/kasan.c:304 [< inline >] copy_to_user ./arch/x86/include/asm/uaccess.h:760 [<ffffffff811ccc08>] filldir+0xc8/0x170 fs/readdir.c:195 [< inline >] dir_emit include/linux/fs.h:3134 [<ffffffff8124af38>] call_filldir+0x88/0x140 fs/ext4/dir.c:510 [< inline >] ext4_dx_readdir fs/ext4/dir.c:586 [<ffffffff8124b934>] ext4_readdir+0x714/0x950 fs/ext4/dir.c:121 [<ffffffff811ccd2d>] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [<ffffffff811ccf71>] SyS_getdents+0x91/0x120 fs/readdir.c:212 [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 Memory state around the buggy address: ffff88006a828380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a828400: fc fc fc fc fc fc fc fc fc fc 00 00 00 00 00 00 >ffff88006a828480: 00 05 fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88006a828500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a828580: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ================================================================== random: systemd urandom read with 60 bits of entropy available ================================================================== BUG: KASAN: slab-out-of-bounds in copy_from_iter+0x1ee/0x330 at addr ffff88006a246e00 Write of size 178 by task systemd/1 ============================================================================= BUG kmalloc-256 (Tainted: G B ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in devkmsg_write+0x42/0x110 age=2 cpu=1 pid=1 [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 [< inline >] slab_alloc_node mm/slub.c:2538 [< inline >] slab_alloc mm/slub.c:2580 [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 [< inline >] kmalloc include/linux/slab.h:483 [< none >] devkmsg_write+0x42/0x110 kernel/printk/printk.c:631 [< none >] do_iter_readv_writev+0x9b/0x110 fs/read_write.c:695 [< none >] do_readv_writev+0x13a/0x250 fs/read_write.c:843 [< none >] vfs_writev+0x3c/0x50 fs/read_write.c:882 [< none >] do_writev+0x5c/0xc0 fs/read_write.c:915 [< inline >] SYSC_writev fs/read_write.c:988 [< none >] SyS_writev+0x10/0x20 fs/read_write.c:986 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Slab 0xffffea0001a89100 objects=29 used=16 fp=0xffff88006a245180 flags=0x4080 INFO: Object 0xffff88006a246df0 @offset=11760 fp=0x747379733e30333c Bytes b4 ffff88006a246de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246df0: 3c 33 30 3e 73 79 73 74 65 6d 64 5b 31 5d 3a 20 <30>systemd[1]: Object ffff88006a246e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246e10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246e20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246e30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246e40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246e90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246ea0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246eb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246ec0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246ed0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Object ffff88006a246ee0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 1 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #188 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 ffff88006cd97c18 ffffffff8146bd4c ffff8800000973c0 ffff88006a246df0 ffff88006cd97c48 ffffffff81198d96 ffff8800000973c0 ffffea0001a89100 ffff88006a246df0 0000000000000001 ffff88006cd97c70 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 [< inline >] print_address_description mm/kasan/report.c:180 [< inline >] kasan_report_error mm/kasan/report.c:276 [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 [<ffffffff811a0024>] kasan_check_write+0x14/0x20 mm/kasan/kasan.c:310 [< inline >] __copy_from_user ./arch/x86/include/asm/uaccess_64.h:113 [<ffffffff8147fdbe>] copy_from_iter+0x1ee/0x330 lib/iov_iter.c:408 [<ffffffff810aa63c>] devkmsg_write+0x5c/0x110 kernel/printk/printk.c:636 [<ffffffff811b83cb>] do_iter_readv_writev+0x9b/0x110 fs/read_write.c:695 [<ffffffff811b9bca>] do_readv_writev+0x13a/0x250 fs/read_write.c:843 [<ffffffff811b9d1c>] vfs_writev+0x3c/0x50 fs/read_write.c:882 [<ffffffff811b9d8c>] do_writev+0x5c/0xc0 fs/read_write.c:915 [< inline >] SYSC_writev fs/read_write.c:988 [<ffffffff811ba720>] SyS_writev+0x10/0x20 fs/read_write.c:986 [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 Memory state around the buggy address: ffff88006a246d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc 00 00 ffff88006a246e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88006a246e80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff88006a246f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a246f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-07 15:54 ` Dmitry Vyukov 2017-03-07 16:05 ` Alexander Potapenko @ 2017-03-07 16:26 ` Andrey Ryabinin 2017-03-07 16:40 ` Dmitry Vyukov 2017-03-08 8:10 ` Nikolay Borisov 2 siblings, 1 reply; 16+ messages in thread From: Andrey Ryabinin @ 2017-03-07 16:26 UTC (permalink / raw) To: Dmitry Vyukov, Nikolay Borisov Cc: Alexander Potapenko, LKML, kasan-dev, Kees Cook On 03/07/2017 06:54 PM, Dmitry Vyukov wrote: > > Hi, > > Re the message that kasan is not supported while it's still enabled in the end. > I think it's an issue related to gcc plugins. Originally kasan was > supported with 5.0+ thus the message. However, later we extended this > support to 4.5+ with gcc plugins. You made this up, we don't have such plugin. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-07 16:26 ` Andrey Ryabinin @ 2017-03-07 16:40 ` Dmitry Vyukov 0 siblings, 0 replies; 16+ messages in thread From: Dmitry Vyukov @ 2017-03-07 16:40 UTC (permalink / raw) To: Andrey Ryabinin Cc: Nikolay Borisov, Alexander Potapenko, LKML, kasan-dev, Kees Cook On Tue, Mar 7, 2017 at 5:26 PM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote: > > > On 03/07/2017 06:54 PM, Dmitry Vyukov wrote: > >> >> Hi, >> >> Re the message that kasan is not supported while it's still enabled in the end. >> I think it's an issue related to gcc plugins. Originally kasan was >> supported with 5.0+ thus the message. However, later we extended this >> support to 4.5+ with gcc plugins. > > You made this up, we don't have such plugin. Right. It was KCOV. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-07 15:54 ` Dmitry Vyukov 2017-03-07 16:05 ` Alexander Potapenko 2017-03-07 16:26 ` Andrey Ryabinin @ 2017-03-08 8:10 ` Nikolay Borisov 2017-03-08 12:34 ` Dmitry Vyukov 2017-03-09 9:46 ` Andrey Ryabinin 2 siblings, 2 replies; 16+ messages in thread From: Nikolay Borisov @ 2017-03-08 8:10 UTC (permalink / raw) To: Dmitry Vyukov Cc: Andrey Ryabinin, Alexander Potapenko, LKML, kasan-dev, Kees Cook [-- Attachment #1: Type: text/plain, Size: 3569 bytes --] On 7.03.2017 17:54, Dmitry Vyukov wrote: > On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov > <n.borisov.lkml@gmail.com> wrote: >> Hello, >> >> I've been chasing a particular UAF as reported by kasan >> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one >> thing which I took notice of rather lately is that I was building my >> kernel with gcc 4.7.4 which is not supported by kasan as indicated by >> the following string: >> >> scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: >> -fsanitize=kernel-address is not supported by compiler >> >> >> Nevertheless, the kernel compiles and when I boot it I see the kasan >> splats as per the referenced thread. If, however, I build the kernel >> with a newer compiler version 5.4.0 kasan no longer complains. >> >> >> At this point I'm wondering whether the splats can be due to old >> compiler being used e.g. false positives or are they genuine splats and >> gcc 5 somehow obfuscates them ? Clearly despite the warning about not >> being able to use CONFIG_KASAN it is still working since I'm seeing the >> splats. Is this valid behavior ? > > > Hi, > > Re the message that kasan is not supported while it's still enabled in the end. > I think it's an issue related to gcc plugins. Originally kasan was > supported with 5.0+ thus the message. However, later we extended this > support to 4.5+ with gcc plugins. However, that confusing message from > build system was not fixed. So yes, it's confusing and it's something > to fix, but mostly you can just ignore it. > > Re false positives with 4.7. By default I would assume that it is true > positive. Should be easy to check with manual printfs. So apparently this is indeed a false positive, resulting from using the old compiler. I used the attached patch to verify it. And what it prints is : [ 17.184288] Assigned fbdev-blacklist.conff(ffff880001ea8020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 [ 17.185808] Calling filldir with ffff88006ae8fdb0 So the first line essentially happens when the object ffff88006ae8fdb0 is being allocated and the second when it's used in filldir. The warning in ext4_ext_map_blocks doesn't trigger. However, if I remove the check for the value of ext4_global_pointer then I see multiple lines such as: [ 17.386283] ext4_ext_map_blocks:freeing pointer used in ext4_htree_store_dirent: ffff88006ae8fdb0 inode: ffff88006bff60d0 [ 17.387601] Assigned fbdev-blacklist.conff(ffff880001eb3020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 [ 17.388740] Calling filldir with ffff88006ae8fdb0 so that same object was used right before it is allocated again in ext4_htree_store_dirent. And when you think about it it is logical since before filling in the dentry names in ext4_htree_store_dirent ext4 has to fetch the contents of the directory from disk. This leads me to believe that kasan is getting confused thinking that the object is being freed AFTER being allocated in ext4_htree_store_dirent but testing shows it's being freed BEFORE. So I deem this a false positive, triggered by the compiler. > > Re why 5.4 does not detect it. Difficult to say. > If you confirm that it's a real bug and provide repro instructions, > then I can recheck it with latest gcc. If it's a real bug and the > latest gcc does not detect it, then we need to look more closely at > it. I afraid 5.4 won't be fixed. > It's also possible that it's a false positive in the old compiler (I > think there were some bugs). If so, I would recommend switching to a > newer compiler. > [-- Attachment #2: ext4-debug.patch --] [-- Type: text/x-patch, Size: 2084 bytes --] diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c index 68323e3da3fa..31f5153b3df4 100644 --- a/fs/ext4/dir.c +++ b/fs/ext4/dir.c @@ -429,6 +429,7 @@ void ext4_htree_free_dir_info(struct dir_private_info *p) * encrypted filename, while the htree will hold decrypted filename. * The decrypted filename is passed in via ent_name. parameter. */ +void *global_ext4_pointer = NULL; int ext4_htree_store_dirent(struct file *dir_file, __u32 hash, __u32 minor_hash, struct ext4_dir_entry_2 *dirent, @@ -454,7 +455,10 @@ int ext4_htree_store_dirent(struct file *dir_file, __u32 hash, new_fn->file_type = dirent->file_type; memcpy(new_fn->name, ent_name->name, ent_name->len); new_fn->name[ent_name->len] = 0; - + if (!strcmp(new_fn->name, "fbdev-blacklist.conf")) { + pr_info("Assigned %s(%p)%u whole object: %p inode:%p\n", ent_name->name, ent_name->name, ent_name->len, new_fn, file_inode(dir_file)); + global_ext4_pointer = new_fn; + } while (*p) { parent = *p; fname = rb_entry(parent, struct fname, rb_hash); @@ -507,6 +511,8 @@ static int call_filldir(struct file *file, struct dir_context *ctx, } ctx->pos = hash2pos(file, fname->hash, fname->minor_hash); while (fname) { + if (fname == global_ext4_pointer) + pr_info("Calling filldir with %p\n", fname); if (!dir_emit(ctx, fname->name, fname->name_len, fname->inode, diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c index 2a2eef9c14e4..590a8cbb66b4 100644 --- a/fs/ext4/extents.c +++ b/fs/ext4/extents.c @@ -4276,6 +4276,8 @@ static int get_implied_cluster_alloc(struct super_block *sb, * * return < 0, error case. */ +extern void* global_ext4_pointer; + int ext4_ext_map_blocks(handle_t *handle, struct inode *inode, struct ext4_map_blocks *map, int flags) { @@ -4616,6 +4618,9 @@ out: map->m_len = allocated; out2: ext4_ext_drop_refs(path); + if (path == global_ext4_pointer) { + pr_info("%s:freeing pointer used in ext4_htree_store_dirent: %p inode: %p\n", __func__, path, inode); + } kfree(path); trace_ext4_ext_map_blocks_exit(inode, flags, map, ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-08 8:10 ` Nikolay Borisov @ 2017-03-08 12:34 ` Dmitry Vyukov 2017-03-09 9:46 ` Andrey Ryabinin 1 sibling, 0 replies; 16+ messages in thread From: Dmitry Vyukov @ 2017-03-08 12:34 UTC (permalink / raw) To: Nikolay Borisov Cc: Andrey Ryabinin, Alexander Potapenko, LKML, kasan-dev, Kees Cook On Wed, Mar 8, 2017 at 9:10 AM, Nikolay Borisov <n.borisov.lkml@gmail.com> wrote: > > > On 7.03.2017 17:54, Dmitry Vyukov wrote: >> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov >> <n.borisov.lkml@gmail.com> wrote: >>> Hello, >>> >>> I've been chasing a particular UAF as reported by kasan >>> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one >>> thing which I took notice of rather lately is that I was building my >>> kernel with gcc 4.7.4 which is not supported by kasan as indicated by >>> the following string: >>> >>> scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: >>> -fsanitize=kernel-address is not supported by compiler >>> >>> >>> Nevertheless, the kernel compiles and when I boot it I see the kasan >>> splats as per the referenced thread. If, however, I build the kernel >>> with a newer compiler version 5.4.0 kasan no longer complains. >>> >>> >>> At this point I'm wondering whether the splats can be due to old >>> compiler being used e.g. false positives or are they genuine splats and >>> gcc 5 somehow obfuscates them ? Clearly despite the warning about not >>> being able to use CONFIG_KASAN it is still working since I'm seeing the >>> splats. Is this valid behavior ? >> >> >> Hi, >> >> Re the message that kasan is not supported while it's still enabled in the end. >> I think it's an issue related to gcc plugins. Originally kasan was >> supported with 5.0+ thus the message. However, later we extended this >> support to 4.5+ with gcc plugins. However, that confusing message from >> build system was not fixed. So yes, it's confusing and it's something >> to fix, but mostly you can just ignore it. >> >> Re false positives with 4.7. By default I would assume that it is true >> positive. Should be easy to check with manual printfs. > > So apparently this is indeed a false positive, resulting from using the old > compiler. I used the attached patch to verify it. > > And what it prints is : > [ 17.184288] Assigned fbdev-blacklist.conff(ffff880001ea8020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 > [ 17.185808] Calling filldir with ffff88006ae8fdb0 > > So the first line essentially happens when the object ffff88006ae8fdb0 is > being allocated and the second when it's used in filldir. The warning in > ext4_ext_map_blocks doesn't trigger. However, if I remove the check for > the value of ext4_global_pointer then I see multiple lines such as: > [ 17.386283] ext4_ext_map_blocks:freeing pointer used in ext4_htree_store_dirent: ffff88006ae8fdb0 inode: ffff88006bff60d0 > [ 17.387601] Assigned fbdev-blacklist.conff(ffff880001eb3020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 > [ 17.388740] Calling filldir with ffff88006ae8fdb0 > > so that same object was used right before it is allocated again in > ext4_htree_store_dirent. And when you think about it it is logical since > before filling in the dentry names in ext4_htree_store_dirent ext4 has to fetch the > contents of the directory from disk. > > This leads me to believe that kasan is getting confused thinking that > the object is being freed AFTER being allocated in > ext4_htree_store_dirent but testing shows it's being freed BEFORE. So > I deem this a false positive, triggered by the compiler. I am not following how compiler version can affect any of this. But if you say this is a false positive, let it be so. gcc 4.7 is old. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-08 8:10 ` Nikolay Borisov 2017-03-08 12:34 ` Dmitry Vyukov @ 2017-03-09 9:46 ` Andrey Ryabinin 2017-03-09 9:47 ` Dmitry Vyukov 2017-03-09 9:58 ` Nikolay Borisov 1 sibling, 2 replies; 16+ messages in thread From: Andrey Ryabinin @ 2017-03-09 9:46 UTC (permalink / raw) To: Nikolay Borisov, Dmitry Vyukov Cc: Alexander Potapenko, LKML, kasan-dev, Kees Cook On 03/08/2017 11:10 AM, Nikolay Borisov wrote: > > So apparently this is indeed a false positive, resulting from using the old > compiler. I used the attached patch to verify it. > > And what it prints is : > [ 17.184288] Assigned fbdev-blacklist.conff(ffff880001ea8020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 > [ 17.185808] Calling filldir with ffff88006ae8fdb0 > > So the first line essentially happens when the object ffff88006ae8fdb0 is > being allocated and the second when it's used in filldir. The warning in > ext4_ext_map_blocks doesn't trigger. However, if I remove the check for > the value of ext4_global_pointer then I see multiple lines such as: > [ 17.386283] ext4_ext_map_blocks:freeing pointer used in ext4_htree_store_dirent: ffff88006ae8fdb0 inode: ffff88006bff60d0 > [ 17.387601] Assigned fbdev-blacklist.conff(ffff880001eb3020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 > [ 17.388740] Calling filldir with ffff88006ae8fdb0 > > so that same object was used right before it is allocated again in > ext4_htree_store_dirent. And when you think about it it is logical since > before filling in the dentry names in ext4_htree_store_dirent ext4 has to fetch the > contents of the directory from disk. > > This leads me to believe that kasan is getting confused thinking that > the object is being freed As I said before, this is *not* use-after-free. It's out-of-bounds access. No, kasan is not confused, it doesn't think that object is freed. Object is allocated and kasan see it as allocated object. The problem is that filldir reads past the end of that allocated object. I don't see any sign that it's a false-positive. > AFTER being allocated in > ext4_htree_store_dirent but testing shows it's being freed BEFORE. So > I deem this a false positive, triggered by the compiler. > > > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-09 9:46 ` Andrey Ryabinin @ 2017-03-09 9:47 ` Dmitry Vyukov 2017-03-09 9:58 ` Nikolay Borisov 1 sibling, 0 replies; 16+ messages in thread From: Dmitry Vyukov @ 2017-03-09 9:47 UTC (permalink / raw) To: Andrey Ryabinin; +Cc: Nikolay Borisov, Alexander Potapenko, LKML, kasan-dev On Thu, Mar 9, 2017 at 10:46 AM, Andrey Ryabinin <aryabinin@virtuozzo.com> wrote: > On 03/08/2017 11:10 AM, Nikolay Borisov wrote: > >> >> So apparently this is indeed a false positive, resulting from using the old >> compiler. I used the attached patch to verify it. >> >> And what it prints is : >> [ 17.184288] Assigned fbdev-blacklist.conff(ffff880001ea8020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 >> [ 17.185808] Calling filldir with ffff88006ae8fdb0 >> >> So the first line essentially happens when the object ffff88006ae8fdb0 is >> being allocated and the second when it's used in filldir. The warning in >> ext4_ext_map_blocks doesn't trigger. However, if I remove the check for >> the value of ext4_global_pointer then I see multiple lines such as: >> [ 17.386283] ext4_ext_map_blocks:freeing pointer used in ext4_htree_store_dirent: ffff88006ae8fdb0 inode: ffff88006bff60d0 >> [ 17.387601] Assigned fbdev-blacklist.conff(ffff880001eb3020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 >> [ 17.388740] Calling filldir with ffff88006ae8fdb0 >> >> so that same object was used right before it is allocated again in >> ext4_htree_store_dirent. And when you think about it it is logical since >> before filling in the dentry names in ext4_htree_store_dirent ext4 has to fetch the >> contents of the directory from disk. >> >> This leads me to believe that kasan is getting confused thinking that >> the object is being freed > > As I said before, this is *not* use-after-free. It's out-of-bounds access. > No, kasan is not confused, it doesn't think that object is freed. > Object is allocated and kasan see it as allocated object. > The problem is that filldir reads past the end of that allocated object. > > I don't see any sign that it's a false-positive. Then the question is: why is not it detected with newer compiler? It's equally strange: all of kmalloc/free/copy_to_user have manual instrumentation. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-09 9:46 ` Andrey Ryabinin 2017-03-09 9:47 ` Dmitry Vyukov @ 2017-03-09 9:58 ` Nikolay Borisov 2017-03-09 10:16 ` Dmitry Vyukov 1 sibling, 1 reply; 16+ messages in thread From: Nikolay Borisov @ 2017-03-09 9:58 UTC (permalink / raw) To: Andrey Ryabinin, Dmitry Vyukov Cc: Alexander Potapenko, LKML, kasan-dev, Kees Cook On 9.03.2017 11:46, Andrey Ryabinin wrote: > On 03/08/2017 11:10 AM, Nikolay Borisov wrote: > >> >> So apparently this is indeed a false positive, resulting from using the old >> compiler. I used the attached patch to verify it. >> >> And what it prints is : >> [ 17.184288] Assigned fbdev-blacklist.conff(ffff880001ea8020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 >> [ 17.185808] Calling filldir with ffff88006ae8fdb0 >> >> So the first line essentially happens when the object ffff88006ae8fdb0 is >> being allocated and the second when it's used in filldir. The warning in >> ext4_ext_map_blocks doesn't trigger. However, if I remove the check for >> the value of ext4_global_pointer then I see multiple lines such as: >> [ 17.386283] ext4_ext_map_blocks:freeing pointer used in ext4_htree_store_dirent: ffff88006ae8fdb0 inode: ffff88006bff60d0 >> [ 17.387601] Assigned fbdev-blacklist.conff(ffff880001eb3020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 >> [ 17.388740] Calling filldir with ffff88006ae8fdb0 >> >> so that same object was used right before it is allocated again in >> ext4_htree_store_dirent. And when you think about it it is logical since >> before filling in the dentry names in ext4_htree_store_dirent ext4 has to fetch the >> contents of the directory from disk. >> >> This leads me to believe that kasan is getting confused thinking that >> the object is being freed > > As I said before, this is *not* use-after-free. It's out-of-bounds access. > No, kasan is not confused, it doesn't think that object is freed. > Object is allocated and kasan see it as allocated object. > The problem is that filldir reads past the end of that allocated object. > > I don't see any sign that it's a false-positive. Okay in that case I will continue digging. So the name is indeed housed at the end of the struct fname. In ext4_htree_store_dirent this structure seems allocated correctly sizeof(struct fname) + ent_name->len + 1; Also the read should indeed be 20 bytes since the filename in question fbdev-blacklist.conf is indeed 20 bytes. This implies that the 'namlen' passed to copy_to_user is also correct. I guess I will have to look at the generated assembly between the 2 gcc versions and see if anything pops out. > > >> AFTER being allocated in >> ext4_htree_store_dirent but testing shows it's being freed BEFORE. So >> I deem this a false positive, triggered by the compiler. >> >> >> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-09 9:58 ` Nikolay Borisov @ 2017-03-09 10:16 ` Dmitry Vyukov 2017-03-09 11:23 ` Andrey Ryabinin 0 siblings, 1 reply; 16+ messages in thread From: Dmitry Vyukov @ 2017-03-09 10:16 UTC (permalink / raw) To: Nikolay Borisov Cc: Andrey Ryabinin, Alexander Potapenko, LKML, kasan-dev, Kees Cook On Thu, Mar 9, 2017 at 10:58 AM, Nikolay Borisov <n.borisov.lkml@gmail.com> wrote: > > > On 9.03.2017 11:46, Andrey Ryabinin wrote: >> On 03/08/2017 11:10 AM, Nikolay Borisov wrote: >> >>> >>> So apparently this is indeed a false positive, resulting from using the old >>> compiler. I used the attached patch to verify it. >>> >>> And what it prints is : >>> [ 17.184288] Assigned fbdev-blacklist.conff(ffff880001ea8020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 >>> [ 17.185808] Calling filldir with ffff88006ae8fdb0 >>> >>> So the first line essentially happens when the object ffff88006ae8fdb0 is >>> being allocated and the second when it's used in filldir. The warning in >>> ext4_ext_map_blocks doesn't trigger. However, if I remove the check for >>> the value of ext4_global_pointer then I see multiple lines such as: >>> [ 17.386283] ext4_ext_map_blocks:freeing pointer used in ext4_htree_store_dirent: ffff88006ae8fdb0 inode: ffff88006bff60d0 >>> [ 17.387601] Assigned fbdev-blacklist.conff(ffff880001eb3020)20 whole object: ffff88006ae8fdb0 inode:ffff88006bff60d0 >>> [ 17.388740] Calling filldir with ffff88006ae8fdb0 >>> >>> so that same object was used right before it is allocated again in >>> ext4_htree_store_dirent. And when you think about it it is logical since >>> before filling in the dentry names in ext4_htree_store_dirent ext4 has to fetch the >>> contents of the directory from disk. >>> >>> This leads me to believe that kasan is getting confused thinking that >>> the object is being freed >> >> As I said before, this is *not* use-after-free. It's out-of-bounds access. >> No, kasan is not confused, it doesn't think that object is freed. >> Object is allocated and kasan see it as allocated object. >> The problem is that filldir reads past the end of that allocated object. >> >> I don't see any sign that it's a false-positive. > > Okay in that case I will continue digging. So the name is indeed housed > at the end of the struct fname. In ext4_htree_store_dirent this > structure seems allocated correctly sizeof(struct fname) + ent_name->len > + 1; > > Also the read should indeed be 20 bytes since the filename in question > fbdev-blacklist.conf is indeed 20 bytes. This implies that the 'namlen' > passed to copy_to_user is also correct. I guess I will have to look at > the generated assembly between the 2 gcc versions and see if anything > pops out. > >> >> >>> AFTER being allocated in >>> ext4_htree_store_dirent but testing shows it's being freed BEFORE. So >>> I deem this a false positive, triggered by the compiler. Looking at this report I don't see how this is OOB. Object starts at 0xffff88006a2255e0, object size is 69 bytes (from shadow). ffff88006a22560e + 20 bytes is not OOB. BUG: KASAN: slab-out-of-bounds in filldir+0xc8/0x170 at addr ffff88006a22560e Read of size 20 by task systemd/1 ============================================================================= BUG kmalloc-96 (Not tainted): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in ext4_htree_store_dirent+0x3e/0x120 age=0 cpu=2 pid=1 [< none >] ___slab_alloc+0x636/0x6a0 mm/slub.c:2446 [< none >] __slab_alloc+0x4f/0x86 mm/slub.c:2475 [< inline >] slab_alloc_node mm/slub.c:2538 [< inline >] slab_alloc mm/slub.c:2580 [< none >] __kmalloc+0x27a/0x340 mm/slub.c:3561 [< inline >] kmalloc include/linux/slab.h:483 [< inline >] kzalloc include/linux/slab.h:622 [< none >] ext4_htree_store_dirent+0x3e/0x120 fs/ext4/dir.c:447 [< none >] htree_dirblock_to_tree+0x16a/0x190 fs/ext4/namei.c:1001 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Freed in ext4_ext_map_blocks+0x7f9/0x23e0 age=1 cpu=2 pid=1 [< none >] __slab_free+0x31b/0x440 mm/slub.c:2657 [< inline >] slab_free mm/slub.c:2810 [< none >] kfree+0x27f/0x2d0 mm/slub.c:3662 [< none >] ext4_ext_map_blocks+0x7f9/0x23e0 fs/ext4/extents.c:4619 [< none >] ext4_map_blocks+0x3b4/0x5b0 fs/ext4/inode.c:529 [< none >] ext4_getblk+0x54/0x1a0 fs/ext4/inode.c:929 [< none >] ext4_bread+0x13/0x90 fs/ext4/inode.c:979 [< none >] __ext4_read_dirblock+0x3f/0x380 fs/ext4/namei.c:99 [< none >] htree_dirblock_to_tree+0x48/0x190 fs/ext4/namei.c:959 [< none >] ext4_htree_fill_tree+0xaa/0x310 fs/ext4/namei.c:1075 [< inline >] ext4_dx_readdir fs/ext4/dir.c:571 [< none >] ext4_readdir+0x698/0x950 fs/ext4/dir.c:121 [< none >] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [< none >] SyS_getdents+0x91/0x120 fs/readdir.c:212 [< none >] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 INFO: Slab 0xffffea0001a88900 objects=20 used=17 fp=0xffff88006a224e10 flags=0x4080 INFO: Object 0xffff88006a2255e0 @offset=5600 fp=0x45b282a2484c60d4 Bytes b4 ffff88006a2255d0: 02 00 00 00 01 00 00 00 c9 ac fb ff 00 00 00 00 ................ Object ffff88006a2255e0: d4 60 4c 48 a2 82 b2 45 18 8a 82 6a 00 88 ff ff .`LH...E...j.... Object ffff88006a2255f0: 38 51 22 6a 00 88 ff ff 88 8b 82 6a 00 88 ff ff 8Q"j.......j.... Object ffff88006a225600: 00 00 00 00 00 00 00 00 28 03 08 00 14 01 66 62 ........(.....fb Object ffff88006a225610: 64 65 76 2d 62 6c 61 63 6b 6c 69 73 74 2e 63 6f dev-blacklist.co Object ffff88006a225620: 6e 66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 nf.............. Object ffff88006a225630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ CPU: 2 PID: 1 Comm: systemd Tainted: G B 4.7.0-nbor #171 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 0000000000000000 ffff88006cd97c58 ffffffff8146bd4c ffff8800000946c0 ffff88006a2255e0 ffff88006cd97c88 ffffffff81198d96 ffff8800000946c0 ffffea0001a88900 ffff88006a2255e0 0000000000000000 ffff88006cd97cb0 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff8146bd4c>] dump_stack+0x85/0xc9 lib/dump_stack.c:51 [<ffffffff81198d96>] print_trailer+0x116/0x190 mm/slub.c:667 [<ffffffff811992c1>] object_err+0x41/0x50 mm/slub.c:674 [< inline >] print_address_description mm/kasan/report.c:180 [< inline >] kasan_report_error mm/kasan/report.c:276 [<ffffffff811a0a42>] kasan_report+0x282/0x530 mm/kasan/report.c:298 [< inline >] check_memory_region_inline mm/kasan/kasan.c:292 [<ffffffff8119ffa7>] check_memory_region+0x137/0x160 mm/kasan/kasan.c:299 [<ffffffff811a0041>] kasan_check_read+0x11/0x20 mm/kasan/kasan.c:304 [< inline >] copy_to_user ./arch/x86/include/asm/uaccess.h:760 [<ffffffff811ccc08>] filldir+0xc8/0x170 fs/readdir.c:195 [< inline >] dir_emit include/linux/fs.h:3134 [<ffffffff8124af38>] call_filldir+0x88/0x140 fs/ext4/dir.c:510 [< inline >] ext4_dx_readdir fs/ext4/dir.c:586 [<ffffffff8124b934>] ext4_readdir+0x714/0x950 fs/ext4/dir.c:121 [<ffffffff811ccd2d>] iterate_dir+0x7d/0x190 fs/readdir.c:50 [< inline >] SYSC_getdents fs/readdir.c:230 [<ffffffff811ccf71>] SyS_getdents+0x91/0x120 fs/readdir.c:212 [<ffffffff816d7d80>] entry_SYSCALL_64_fastpath+0x23/0xc1 arch/x86/entry/entry_64.S:207 Memory state around the buggy address: ffff88006a225500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a225580: fc fc fc fc fc fc fc fc fc fc fc fc 00 00 00 00 >ffff88006a225600: 00 00 00 00 05 fc fc fc fc fc fc fc fc fc fc fc ^ ffff88006a225680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88006a225700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc 00 00 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-09 10:16 ` Dmitry Vyukov @ 2017-03-09 11:23 ` Andrey Ryabinin 0 siblings, 0 replies; 16+ messages in thread From: Andrey Ryabinin @ 2017-03-09 11:23 UTC (permalink / raw) To: Dmitry Vyukov, Nikolay Borisov Cc: Alexander Potapenko, LKML, kasan-dev, Kees Cook On 03/09/2017 01:16 PM, Dmitry Vyukov wrote: > > Looking at this report I don't see how this is OOB. > Object starts at 0xffff88006a2255e0, object size is 69 bytes (from shadow). > ffff88006a22560e + 20 bytes is not OOB. > Indeed, perhaps gcc 4.7.4 miscompiles something check_memory_region ? That's the only reasonable explanation I have. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: kasan behavior when built with unsupported compiler 2017-03-07 15:35 kasan behavior when built with unsupported compiler Nikolay Borisov 2017-03-07 15:54 ` Dmitry Vyukov @ 2017-03-07 16:23 ` Andrey Ryabinin 1 sibling, 0 replies; 16+ messages in thread From: Andrey Ryabinin @ 2017-03-07 16:23 UTC (permalink / raw) To: Nikolay Borisov; +Cc: glider, Dmitry Vyukov, LKML On 03/07/2017 06:35 PM, Nikolay Borisov wrote: > Hello, > > I've been chasing a particular UAF as reported by kasan > (https://www.spinics.net/lists/kernel/msg2458136.html). AFAICS it's not use after free, it's out-of-bounds access. > However, one > thing which I took notice of rather lately is that I was building my > kernel with gcc 4.7.4 which is not supported by kasan as indicated by > the following string: > > scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN: > -fsanitize=kernel-address is not supported by compiler > > > Nevertheless, the kernel compiles and when I boot it I see the kasan > splats as per the referenced thread. With gcc like 4.7.4 compiler will not instrument memory accesses in code, which means that kasan will not detect bugs. However, in your case, access is done via copy_to_user(). Compiler doesn't see accesses in copy_to_user() because it's written in assembly, thus we added manual check in commit 1771c6e1a567ea0ba2cccc0a4ffe68a1419fd8ef. Of course this manual check will work with any compiler version. > If, however, I build the kernel > with a newer compiler version 5.4.0 kasan no longer complains. > That's odd. Perhaps we have some tricky bug triggered by gcc 4.7.4 code generation or it might be some bug in gcc. But it's just a blind guess, it's hard to say anything for sure without further analysis. > > At this point I'm wondering whether the splats can be due to old > compiler being used e.g. false positives or are they genuine splats and > gcc 5 somehow obfuscates them ? Clearly despite the warning about not > being able to use CONFIG_KASAN it is still working since I'm seeing the > splats. Is this valid behavior ? > So with GCCs that doesn't support kasan we shouldn't have any false-positives, but it's expected to have a lot of false-negatives (missed bugs). > > Regards, > Nikolay > ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-03-09 11:38 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-07 15:35 kasan behavior when built with unsupported compiler Nikolay Borisov 2017-03-07 15:54 ` Dmitry Vyukov 2017-03-07 16:05 ` Alexander Potapenko 2017-03-07 17:33 ` Nikolay Borisov 2017-03-07 17:51 ` Alexander Potapenko 2017-03-07 20:24 ` Nikolay Borisov 2017-03-07 16:26 ` Andrey Ryabinin 2017-03-07 16:40 ` Dmitry Vyukov 2017-03-08 8:10 ` Nikolay Borisov 2017-03-08 12:34 ` Dmitry Vyukov 2017-03-09 9:46 ` Andrey Ryabinin 2017-03-09 9:47 ` Dmitry Vyukov 2017-03-09 9:58 ` Nikolay Borisov 2017-03-09 10:16 ` Dmitry Vyukov 2017-03-09 11:23 ` Andrey Ryabinin 2017-03-07 16:23 ` Andrey Ryabinin
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.