linux-kernel - Re: [PATCH v4 1/2] coredump: Fixes core_pipe_limit sysctl proc

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] [day] [month] [year] [list]

Message-ID: <fa77cbf8-9f69-4dbe-8859-6ca5abbaa9f0@clip-os.org>
Date: Fri, 17 Jan 2025 11:55:05 +0100
From: Nicolas Bouchinet <nicolas.bouchinet@...p-os.org>
To: Kees Cook <kees@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 Nicolas Bouchinet <nicolas.bouchinet@....gouv.fr>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Jiri Slaby <jirislaby@...nel.org>, Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
 Luis Chamberlain <mcgrof@...nel.org>, Joel Granados
 <j.granados@...sung.com>, Andrew Morton <akpm@...ux-foundation.org>,
 Neil Horman <nhorman@...driver.com>, Lin Feng <linf@...gsu.com>,
 Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH v4 1/2] coredump: Fixes core_pipe_limit sysctl
 proc_handler

On 1/16/25 1:32 AM, Kees Cook wrote:
> On Wed, Jan 15, 2025 at 02:22:08PM +0100, nicolas.bouchinet@...p-os.org wrote:
>> Any negative write or >= to INT_MAX in core_pipe_limit sysctl would
>> hypothetically allow a user to create very high load on the system by
>> running processes that produces a coredump in case the core_pattern
>> sysctl is configured to pipe core files to user space helper.
>> Memory or PID exhaustion should happen before but it anyway breaks the
>> core_pipe_limit semantic.
> Isn't this true for "0" too (the default)? I'm not opposed to the change
> since it makes things more clear, but I don't think the >=INT_MAX
> problem is anything more than "functionally identical to 0". :)
Uhm, I think your right, its seems to be functionally identical.
0 codepath slightly differs from > 0 though since it won't trigger
wait_for_dump_helpers().

Thanks for your review,

Nicolas
>
> Reviewed-by: Kees Cook <kees@...nel.org>
>