lkml.org 
[lkml]   [2019]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: BUG: unable to handle kernel NULL pointer dereference in mem_serial_out
From
Date
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. :-(

\
 
 \ /
  Last update: 2019-12-14 11:29    [W:0.046 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site