Messages in this thread | | | Subject | Re: BUG: unable to handle kernel NULL pointer dereference in mem_serial_out | From | Tetsuo Handa <> | Date | Sat, 14 Dec 2019 19:28:02 +0900 |
| |
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. :-(
| |