lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 5 Apr 2018 10:00:04 +0100
From:   Steven Whitehouse <>
To:     Dmitry Vyukov <>
Cc:     Greg KH <>,,,
        syzbot <>,
        LKML <>,
Subject: Re: WARNING: kobject bug in sysfs_warn_dup


On 05/04/18 09:52, Dmitry Vyukov wrote:
> On Thu, Apr 5, 2018 at 10:36 AM, Steven Whitehouse <> wrote:
>> Hi,
>> On 05/04/18 09:19, Dmitry Vyukov wrote:
>>> On Thu, Apr 5, 2018 at 8:34 AM, Greg KH <>
>>> wrote:
>>>> On Wed, Apr 04, 2018 at 07:02:01PM -0700, syzbot wrote:
>>>>> Hello,
>>>>> syzbot hit the following crash on upstream commit
>>>>> 3e968c9f1401088abc9a19ae6ff571644d37a355 (Wed Apr 4 21:19:24 2018 +0000)
>>>>> Merge tag 'ext4_for_linus' of
>>>>> git://
>>>>> syzbot dashboard link:
>>>>> C reproducer:
>>>>> syzkaller reproducer:
>>>>> Raw console output:
>>>>> Kernel config:
>>>>> compiler: gcc (GCC) 7.1.1 20170620
>>>>> IMPORTANT: if you fix the bug, please add the following tag to the
>>>>> commit:
>>>>> Reported-by:
>>>>> It will help syzbot understand when the bug is fixed. See footer for
>>>>> details.
>>>>> If you forward the report, please keep this part and the footer.
>>>>> R10: 0000000000000000 R11: 0000000000000286 R12: 0000000000000003
>>>>> R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
>>>>> ------------[ cut here ]------------
>>>>> kobject_add_internal failed for nodev( with -EEXIST, don't try to
>>>>> register
>>>>> things with the same name in the same directory.
>>>>> sysfs: cannot create duplicate filename '/fs/gfs2/nodev('
>>>>> WARNING: CPU: 1 PID: 4473 at lib/kobject.c:238
>>>>> kobject_add_internal+0x8d4/0xbc0 lib/kobject.c:235
>>>>> CPU: 0 PID: 4474 Comm: syzkaller533472 Not tainted 4.16.0+ #15
>>>>> Kernel panic - not syncing: panic_on_warn set ...
>>>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>>>> Google 01/01/2011
>>>>> Call Trace:
>>>>>    __dump_stack lib/dump_stack.c:17 [inline]
>>>>>    dump_stack+0x1a7/0x27d lib/dump_stack.c:53
>>>>>    sysfs_warn_dup+0x83/0xa0 fs/sysfs/dir.c:30
>>>>>    sysfs_create_dir_ns+0x178/0x1d0 fs/sysfs/dir.c:58
>>>>>    create_dir lib/kobject.c:69 [inline]
>>>>>    kobject_add_internal+0x335/0xbc0 lib/kobject.c:227
>>>>>    kobject_add_varg lib/kobject.c:364 [inline]
>>>>>    kobject_init_and_add+0xf9/0x150 lib/kobject.c:436
>>>>>    gfs2_sys_fs_add+0x1ff/0x580 fs/gfs2/sys.c:652
>>>>>    fill_super+0x86f/0x1d70 fs/gfs2/ops_fstype.c:1118
>>>>>    gfs2_mount+0x587/0x6e0 fs/gfs2/ops_fstype.c:1321
>>>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>>>> usage of the api.
>>> Then +gfs2 maintainers.
>>>> Now if we should turn this into a non-WARN message, that's a different
>>>> thing, I'll gladly take a patch for that.
>>> If it's API usage bug in higher level code, then I think WARN is a
>>> proper thing. We already had similar ones and they were fixed.
>> I'm trying to figure out what the test is doing, but it is not very clear.
>> At a guess I'd say that perhaps it is trying to mount multiple filesystems
>> with the same label? If that is the case then it is not allowed, and it
>> should be caught be the sysfs code and result in a refusal to mount, which
>> is what I think I see here. Knowing which sysfs directory is involved would
>> allow us to confirm, but I suspect that the test needs altering to give each
>> gfs2 mount a different label at an initial guess,
> Hi Steve,
> But Greg claims that this is incorrect usage of sysfs API:
>> gfs2 bug, not a sysfs bug, we are correctly warning about an incorrect
>> usage of the api.
> I think this means that sysfs callers must not try to create the same
> thing twice.
> Either way user-space code must not be able to triggers WARNINGs in
> kernel. If it does than this is something to fix in kernel.

I guess that this warning was added more recently as I've not seen it 
before. My expectation is that it will return -EEXIST and not print a 
warning there. To avoid that we would have to create a new list of GFS2 
superblocks, and check the list for each mount I think. We could do 
that, but it seems a bit odd to duplicate code that is already there and 

So it sounds like a case of differing assumptions about what is a valid 
use of the sysfs api. Shouldn't be too hard to fix though,


Powered by blists - more mailing lists