linux-kernel - Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8

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-prev] [day] [month] [year] [list]

Date:   Wed, 14 Jun 2017 09:49:52 -0600
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Bjorn Helgaas <helgaas@...nel.org>,
        kernel test robot <fengguang.wu@...el.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKP <lkp@...org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>, wfg@...ux.intel.com,
        Alan Cox <alan@...ux.intel.com>, Arnd Bergmann <arnd@...db.de>,
        David Airlie <airlied@...ux.ie>,
        David Herrmann <dh.herrmann@...il.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [Merge tag 'pci-v4.12-changes' of git] 857f864014: BUG: unable to
 handle kernel NULL pointer dereference at 00000000000000a8

Hi Linus,

On 14/06/17 03:59 AM, Linus Walleij wrote:
> I started to take a stab at it at one point and incorporated some feedback
> from Torvalds etc, it's here:
> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/commit/?h=chrdev-warn&id=65e5b1e9eb3f777ab7535b74b490e882eeec79d7

Yes, thanks, I did find your work after a google search. However, seeing
it seems to recover only a handful of numbers with some significant
complexity required it seemed like a stopgap solution anyway. I posted a
proposal in this thread that simply extends the dynamic range into a
region above 256 which seems to work well. This means regular
configurations won't be affected an any configuration requiring more
than 20 dynamic majors will simply end up with high numbers.

So unless anyone can think of a reason why this won't work, it's my
preferred direction.

> Making them all dynamic seemed dangerous because I was afraid
> of userspace ABI breakage because of old userlands with
> static mknod:s.

I agree.

Logan