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]
Message-ID: <c3148aca-5707-1858-d889-af004321b140@deltatee.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ