linux-kernel - Re: [ata_port_probe] BUG: unable to handle kernel NULL pointer dereference at 0000000000000350

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

Date:   Tue, 21 Nov 2017 16:30:22 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Tejun Heo <tj@...nel.org>
Cc:     Fengguang Wu <fengguang.wu@...el.com>,
        IDE-ML <linux-ide@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        LKP <lkp@...org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [ata_port_probe] BUG: unable to handle kernel NULL pointer
 dereference at 0000000000000350

On Tue, Nov 21, 2017 at 3:57 PM, Tejun Heo <tj@...nel.org> wrote:
> Hello,
>
> On Tue, Nov 21, 2017 at 01:54:25PM +0100, Arnd Bergmann wrote:
>> > [   56.376960] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
>> > [   56.379169] ata2.00: configured for MWDMA2
>> > [   56.381518] ata2.00: disabled
>> > [   56.385696] sd 1:0:0:0: [sda] Attached SCSI disk
>> > [   56.395326] sd 1:0:0:0: [sda] Synchronizing SCSI cache
>>
>> I guess both can be explained by the same race as the previous one, with
>> async probe racing against removal. The first one might be a use-after-free
>> problem, the second one could be the probing thread running after the
>> device got removed.
>
> This is not a bug in libata.  This is caused by
> CONFIG_DEBUG_TEST_DRIVER_REMOVE incorrectly detaching the driver
> before probing is complete, which can't happen in normal operations
> (we have async flush at the end of boot and around module operations).
>
> Greg, this issue was identified way back.  It's a debug code which
> causes failures which aren't possible.  Can we please either fix or
> remove it?

Maybe we can call async_synchronize_full() before the ->remove()?

    Arnd