Messages in this thread | | | Date | Sat, 14 Dec 2019 08:55:17 +0100 | From | Greg KH <> | Subject | Re: BUG: unable to handle kernel NULL pointer dereference in mem_serial_out |
| |
On Sat, Dec 14, 2019 at 09:48:29AM +0900, Tetsuo Handa wrote: > On 2019/12/14 1:07, Greg KH wrote: > > On Fri, Dec 13, 2019 at 11:31:08PM +0900, Tetsuo Handa wrote: > >> On 2019/12/13 19:00, Dmitry Vyukov wrote: > >>> Easier said than done. "normal user of the serial port" is not really > >>> a thing in Linux, right? You either have CAP_SYS_ADMIN or not, that's > >>> not per-device... > >>> As far as I remember +Tetsuo proposed a config along the lines of > >>> "restrict only things that legitimately cause damage under a fuzzer > >>> workload", e.g. freezing filesystems, disabling console output, etc. > >>> This may be another candidate. But I can't find where that proposal is > >>> now. > >> > >> 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?
> > You just will have a list of things that you "do not fuzz as these are > > dangerous". Nothing new here, any os will have that. > > The list of kernel config options will become too complicated to maintain. > If we can have one kernel config option, we can avoid maintaining > the list of kernel config options (which keeps changing over time).
Use the newly added security_locked_down() call, that gives you a great indication that root can cause problems for those things.
And it's not a config thing, it's a functionality thing within features, as is explicitly shown by this very thread for the serial port memory location.
thanks,
greg k-h
| |