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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ