linux-kernel - Re: [PATCH (resend)] Input: MT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Zqe76gATYUcDVLaG@google.com>
Date: Mon, 29 Jul 2024 08:57:30 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Henrik Rydberg <rydberg@...math.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH (resend)] Input: MT - limit max slots

On Mon, Jul 29, 2024 at 04:28:38PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jul 29, 2024 at 10:15:26PM +0900, Tetsuo Handa wrote:
> > On 2024/07/29 22:05, Greg Kroah-Hartman wrote:
> > > On Mon, Jul 29, 2024 at 09:51:30PM +0900, Tetsuo Handa wrote:
> > >> syzbot is reporting too large allocation at input_mt_init_slots(), for
> > >> num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).
> > >>
> > >> Since nobody knows possible max slots, this patch chose 1024.
> > >>
> > >> Reported-by: syzbot <syzbot+0122fa359a69694395d5@...kaller.appspotmail.com>
> > >> Closes: https://syzkaller.appspot.com/bug?extid=0122fa359a69694395d5
> > >> Suggested-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> > >> Signed-off-by: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> > >> ---
> > >> This patch was tested in linux-next between next-20240611 and next-20240729
> > >> via my tree. Who can take this patch? If nobody can, I will send to Linus.
> > > 
> > > What is wrong with the normal input maintainer and tree?  Why not send
> > > it there?
> > 
> > I don't know why. I couldn't get further response from Dmitry Torokhov.
> > Who can make final decision and what tree is used?
> > 
> > e.g.
> > 2022-11-23  0:28 https://lkml.kernel.org/r/03e8c3f0-bbbf-af37-6f52-67547cbd4cde@I-love.SAKURA.ne.jp
> > 2023-09-03 13:55 https://lkml.kernel.org/r/07350163-de52-a2bf-58bf-88c3d9d8d85b@I-love.SAKURA.ne.jp
> > 2024-05-27 10:35 https://lkml.kernel.org/r/7b7f9cf5-a1de-4e5a-8d30-bb2979309f02@I-love.SAKURA.ne.jp
> > 
> 
> Again, it's up to the Input maintainer.

Sorry, I meant to respond to this and it got lost in my mailbox. To be
honest I really dislike all this extra patching for the sake of
syzkaller. Syzkaller is a tool and ideally we should not modify random
places in the kernel just because it decided to [ab]use one mechanism
that is also used for other purposes.

Now, to the issue at hand. I believe there are 2 classes of warnings: a
true warning that is emitted for clearly unexpected situation that was
caused by a bug or an invariant violation somewhere. Those we definitely
want syzkaller to report so that we could identify the root cause and
fix it.

iThe other types of warnings, such as the warning in the memory
allocation case, are warnings of convenience. We have them so that we do
not need to annotate all memory allocation checks with custom messages.
Instead we just rely on k*alloc() and friends to give us a spew when
they can't allocate memory. These allocation failures are expected and
typically are handled (and if they are not handled we'll get an oops a
moment later). We really do not need syzkaller to trip on those.

Can we change k*alloc() to stop triggering panic on warning when we run
with syzkaller?

Thanks.

-- 
Dmitry