linux-kernel - Re: [LKP] [mtd] c4dfa25ab3: kernel_BUG_at

lists.openwall.net		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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wh2sparb1qw4h5QTCR+YF7xsssLgZtNtthRA6QiJjKfbA@mail.gmail.com>
Date:   Wed, 2 Jan 2019 11:53:34 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     kernel test robot <rong.a.chen@...el.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Rafał Miłecki <rafal@...ecki.pl>,
        Richard Weinberger <richard@....at>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Alban Bedel <albeu@...e.fr>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Boris Brezillon <boris.brezillon@...tlin.com>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...org
Subject: Re: [LKP] [mtd] c4dfa25ab3: kernel_BUG_at_fs/sysfs/file.c

Hmm..

Adding a few more mtd people to the cc.

On Tue, Jan 1, 2019 at 4:57 PM kernel test robot <rong.a.chen@...el.com> wrote:
>
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: c4dfa25ab307a277eafa7067cd927fbe4d9be4ba ("mtd: add support for reading MTD devices via the nvmem API")
>
> [   81.780248] kernel BUG at fs/sysfs/file.c:328!
> [   81.781914] Call Trace:
> [   81.781914]  sysfs_create_files+0x60/0x180
> [   81.781914]  mtd_add_partition_attrs+0x14/0x30
> [   81.781914]  add_mtd_partitions+0x11f/0x260
> [   81.781914]  mtd_device_parse_register+0x38d/0x4c0
> [   81.781914]  ns_init_module+0x1033/0x117d
> [   81.781914]  do_one_initcall+0x18f/0x39e
> [   81.781914]  kernel_init_freeable+0x2b4/0x353
> [   81.781914]  kernel_init+0xa/0x120

This actually looks like a very old bug, just exposed by a new error case.

In particular, the mtd code seems to do this in mtd_add_partition():

        int ret = 0;
     ...
        add_mtd_device(&new->mtd);

        mtd_add_partition_attrs(new);

        return ret;

where 'ret' is actually never set to anything but that initial zero.

And in fact, it looks like it never was used.

I _think_ that what's going on is that "add_mtd_device()" historically
never really failed (although it *can* fail), and then
mtd_add_partition_attrs() is called on something that doesn't really
exist.

It looks like the error handling for the add_mtd_device() case nmever
actually existed, and now the nvmem patch makes that fail in the
test-case, and the lack of error handling is exposed.

There is another call-site of add_mtd_device() (in
add_mtd_partitions() - same pattern, notice the "s" at the end of the
function name) that also lacks the error handling.

Both cases go back to 2010.

Greg, Rafael: it does strike me that the "BUG_ON()" in
sysfs_create_file_ns() could easily have been a

        if (WARN_ON(..))
                return -EINVAL;

which would have made the machine boot and probably make things easier
for normal users to report. The kernel test robot doesn't care, but
non-booting kernels are usually not nice to debug or report for normal
human beings..

                 Linus