From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EFC9CC43603 for ; Sat, 14 Dec 2019 00:49:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E25CE20724 for ; Sat, 14 Dec 2019 00:49:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726707AbfLNAtS (ORCPT ); Fri, 13 Dec 2019 19:49:18 -0500 Received: from www262.sakura.ne.jp ([202.181.97.72]:63397 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726690AbfLNAtS (ORCPT ); Fri, 13 Dec 2019 19:49:18 -0500 Received: from fsav405.sakura.ne.jp (fsav405.sakura.ne.jp [133.242.250.104]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id xBE0mX3g067624; Sat, 14 Dec 2019 09:48:33 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav405.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav405.sakura.ne.jp); Sat, 14 Dec 2019 09:48:33 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav405.sakura.ne.jp) Received: from [192.168.1.9] (softbank126040062084.bbtec.net [126.40.62.84]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id xBE0mWtv067616 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Sat, 14 Dec 2019 09:48:33 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: BUG: unable to handle kernel NULL pointer dereference in mem_serial_out To: Greg KH Cc: Dmitry Vyukov , Linus Torvalds , syzbot , Andy Shevchenko , asierra@xes-inc.com, ext-kimmo.rautkoski@vaisala.com, Jiri Slaby , kai heng feng , LKML , linux-serial , mika.westerberg@linux.intel.com, o.barta89@gmail.com, paulburton@kernel.org, sr@denx.de, syzkaller-bugs , yegorslists@googlemail.com References: <00000000000053539a0599173973@google.com> <20191212105701.GB1476206@kroah.com> <20191213093357.GB2135612@kroah.com> <74859736-478a-6ad7-f0be-cfe87ec40ff5@i-love.sakura.ne.jp> <20191213160700.GA2632926@kroah.com> From: Tetsuo Handa Message-ID: <4f514a5a-af11-e688-8f8d-72bbadadc889@i-love.sakura.ne.jp> Date: Sat, 14 Dec 2019 09:48:29 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20191213160700.GA2632926@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-serial-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org 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. > > 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).