linux-kernel - Re: BUG: unable to handle kernel NULL pointer dereference in write

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAK8P3a2SnRF9198W4W81WwzEX6yCKFjBLTtTo+97Qcym=99Akg@mail.gmail.com>
Date:   Tue, 20 Nov 2018 14:33:32 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     kt0755@...il.com
Cc:     gregkh <gregkh@...uxfoundation.org>, lifeasageek@...il.com,
        threeearcat@...il.com, syzkaller@...glegroups.com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: BUG: unable to handle kernel NULL pointer dereference in write_port

On Tue, Nov 13, 2018 at 9:24 AM Kyungtae Kim <kt0755@...il.com> wrote:
>
> We report a bug in v4.19-rc8 (4.20-rc1 as well):
>
> kernel config: https://kt0755.github.io/etc/config-4.19-rc2.kmsan
> repro: https://kt0755.github.io/etc/repro.e3752.c
>
> This happens during data transition from user-supplied buffer to port
> (using outb) pointed by ppos. (driver/mem/char.c:640)
> Although there is a strict bound 65536 (driver/mem/char.c:632), user
> buffer copy still causes crashes within the strict bound.
> (In the experiment, the crash arose when loop count is beyond 0x7f )
> To stop it, it probably needs a little tight bound check.
>
> I think this is a little bit related to the crash I reported before
> (https://lkml.org/lkml/2018/5/12/91)
>
> Crash log
> =========================================
> BUG: unable to handle kernel NULL pointer dereference at 00000000000000af

The first thing that comes to mind is that this would be qemu specific.
Note that writing arbitrary data into arbitrary I/O ports is likely to crash
any x86 PC, but it's possible that qemu reports a different set of
exceptions.

Looking in /proc/ioports for a real PC, I find

    0080-008f : dma page reg
    00a0-00a1 : pic2
    00c0-00df : dma2
    00f0-00ff : fpu

so it appears that you have just written into the interrupt
controller here.

       Arnd