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: <ZqfpgmmLgKti0Xrf@google.com>
Date: Mon, 29 Jul 2024 12:12:02 -0700
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	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>
Subject: Re: [PATCH (resend)] Input: MT - limit max slots

On Mon, Jul 29, 2024 at 11:41:59AM -0700, Linus Torvalds wrote:
> On Mon, 29 Jul 2024 at 11:35, Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
> >
> > What exactly did you do? Limit size of data userspace can request to be
> > written? What is the max allowed size then? Can I stick a warning in the
> > code to complain when it is "too big"?
> 
> Look up MAX_RW_COUNT.
> 
> 
> > So does this mean that we should disallow any and all allocations above
> > 4k because they can potentially fail, depending on the system state? Or
> > maybe we should be resilient and fail gracefully instead?
> 
> We are resilient and fail gracefully.
> 
> But there's very a limit to that.
> 
> Dmitry - none of this is at all new. The kernel has a *lot* of
> practical limits. Many of them actually come from very traditional
> sources indeed.
> 
> Things like NR_OPEN, PATH_MAX, lots of arbitrary limits because arrays
> don't get to grow too big. Things that are *so* basic that you don't
> even think about them, because you think they are obvious.
> 
> In fact, you should start from the assumption that *EVERYTHING* is limited.
> 
> So get off your idiotic high horse. The input layer is not so special
> that you should say "I can't have any limits".

OK, if you want to have limits be it. You probably want to lower from
1024 to 128 or something, because with 1024 slots the structure will be
larger than one page and like I said mt->red table will be 4Mb.

This still will not affect any real users, and will not solve syzkaller
issue as it will continue tripping on various memory allocations that we
are actually prepared to handle.

Thanks.

-- 
Dmitry