Re: BUG: unable to handle kernel NULL pointer dereference in mem_serial_out

From: Tetsuo Handa
Date: Sat Dec 14 2019 - 05:29:08 EST

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

+static char dummybuf[PAGE_SIZE];

ptr = xlate_dev_mem_ptr(p);
if (!ptr) {
if (written)
return -EFAULT;
copied = copy_from_user(ptr, buf, sz);
+ copied = copy_from_user(dummybuf, buf, min(sizeof(dummybuf), sz));
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. :-(