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: <ZqfYfIp3n7Qfo1-Q@google.com>
Date: Mon, 29 Jul 2024 10:59:24 -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 10:43:58AM -0700, Linus Torvalds wrote:
> On Mon, 29 Jul 2024 at 08:57, Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
> >
> > iThe other types of warnings, such as the warning in the memory
> > allocation case, are warnings of convenience.
> 
> No.
> 
> They are WARNINGS OF BUGS.
> 
> They are basically warning that the code seems to allow arbitrary
> allocation sizes.

No, this is decidedly not a bug. As with any other resource, if it is
available it can be allocated and if it is not available the code should
handle the failures.

Can I write a gigabyte of data to disk? Terabyte? Is petabyte too much?
What if I don't have enough physical disk. Do we "fix" write() not to
take size_t length?

> 
> So apparently you've been sitting on this problem for two years
> because you didn't understand that you had a bug, and thought the
> warning was some "convenience thing".

Yes, it is a convenience thing. Same as some code wanting to allocate 2
or 4 pages and sometimes failing when the system is under load.

> 
> I'll just apply it directly. Don't do this again.

Please do not. Or you will have to patch it again when we will still see
the same allocation failures because someone requested an input device
with "too many" slots (1024 results in 4Mb mt->red table for example).

Just fix malloc/syzkaller not to trigger on benign memory allocation
hickups. They are normal.

Thanks.

-- 
Dmitry