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

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]

Message-ID: <1634f244-543c-28c6-c322-c3d981c3a973@i-love.sakura.ne.jp>
Date:   Sat, 14 Dec 2019 19:28:02 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        syzbot <syzbot+f4f1e871965064ae689e@...kaller.appspotmail.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        asierra@...-inc.com, ext-kimmo.rautkoski@...sala.com,
        Jiri Slaby <jslaby@...e.com>,
        kai heng feng <kai.heng.feng@...onical.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-serial <linux-serial@...r.kernel.org>,
        mika.westerberg@...ux.intel.com, o.barta89@...il.com,
        paulburton@...nel.org, sr@...x.de,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        yegorslists@...glemail.com
Subject: Re: BUG: unable to handle kernel NULL pointer dereference in
 mem_serial_out

On 2019/12/14 18:09, Greg KH wrote:
> On Sat, Dec 14, 2019 at 05:39:02PM +0900, Tetsuo Handa wrote:
>> On 2019/12/14 16:55, Greg KH wrote:
>>>>>> That suggestion got no response for two months.
>>>>>>
>>>>>>   https://lkml.kernel.org/r/3e4e2b6b-7828-54ab-cf28-db1a396d7e20@i-love.sakura.ne.jp
>>>>>>
>>>>>> Unless we add such kernel config option to upstream kernels, it will become
>>>>>> a whack-a-mole game.
>>>>>
>>>>> It will be a whack-a-mole game no matter what.
>>>>>
>>>>> Yes, /dev/mem/ makes no sense to fuzz.  Neither does other things (like
>>>>> serial port memory addresses.)
>>>>
>>>> /dev/mem makes sense to fuzz. Ditto for other things.
>>>
>>> What?  What are you going to find if you randomly start to write to
>>> /dev/mem?  How are we supposed to "fix" that?
>>>
>>
>> When did I say "writing to random addresses" ? If you saw my suggestion, you
>> will find that "fuzzer will be able to test reading from random addresses,
>> writing to safe addresses (in order to find new lock dependency which would
>> otherwise be unnoticed)".
> 
> I don't remember the suggestion specifically, sorry.  But how would you
> figure out what those "safe addresses" really are?  They will change on
> every single platform.

----------
+#ifdef CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING
+static char dummybuf[PAGE_SIZE];
+#endif
----------

----------
                        ptr = xlate_dev_mem_ptr(p);
                        if (!ptr) {
                                if (written)
                                        break;
                                return -EFAULT;
                        }
+#ifndef CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING
                        copied = copy_from_user(ptr, buf, sz);
+#else
+                       copied = copy_from_user(dummybuf, buf, min(sizeof(dummybuf), sz));
+#endif
                        unxlate_dev_mem_ptr(p, ptr);
----------

How dummybuf cannot be "safe address" ?

> 
> And why would this even help anything?  What lock dependency?
> 

copy_from_user() can trigger page fault which involves memory allocation.
And direct reclaim which is performed within memory allocation operation
is full of subtle dependency bugs. :-(