linux-kernel - Re: [PATCH RFC 3/8] openat2: explicitly return -E2BIG for (usize > PAGE

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: <63193b87-7057-4ad0-aef2-fdb5d15138c3@app.fastmail.com>
Date: Mon, 02 Sep 2024 09:09:55 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: "Aleksa Sarai" <cyphar@...har.com>, "Ingo Molnar" <mingo@...hat.com>,
 "Peter Zijlstra" <peterz@...radead.org>,
 "Juri Lelli" <juri.lelli@...hat.com>,
 "Vincent Guittot" <vincent.guittot@...aro.org>,
 "Dietmar Eggemann" <dietmar.eggemann@....com>,
 "Steven Rostedt" <rostedt@...dmis.org>,
 "Benjamin Segall" <bsegall@...gle.com>, "Mel Gorman" <mgorman@...e.de>,
 "Valentin Schneider" <vschneid@...hat.com>,
 "Alexander Viro" <viro@...iv.linux.org.uk>,
 "Christian Brauner" <brauner@...nel.org>, "Jan Kara" <jack@...e.cz>,
 shuah <shuah@...nel.org>
Cc: "Kees Cook" <kees@...nel.org>, "Florian Weimer" <fweimer@...hat.com>,
 "Mark Rutland" <mark.rutland@....com>, linux-kernel@...r.kernel.org,
 linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 Linux-Arch <linux-arch@...r.kernel.org>, linux-kselftest@...r.kernel.org,
 stable@...r.kernel.org
Subject: Re: [PATCH RFC 3/8] openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)

On Mon, Sep 2, 2024, at 07:06, Aleksa Sarai wrote:
> While we do currently return -EFAULT in this case, it seems prudent to
> follow the behaviour of other syscalls like clone3. It seems quite
> unlikely that anyone depends on this error code being EFAULT, but we can
> always revert this if it turns out to be an issue.

Right, it's probably a good idea to have a limit there rather than
having a busy loop with a user-provided length when the only bound is
the available virtual memory.

>  	if (unlikely(usize < OPEN_HOW_SIZE_VER0))
>  		return -EINVAL;
> +	if (unlikely(usize > PAGE_SIZE))
> +		return -E2BIG;
> 

Is PAGE_SIZE significant here? If there is a need to enforce a limit,
I would expect this to be the same regardless of kernel configuration,
since the structure layout is also independent of the configuration.

Where is the current -EFAULT for users passing more than a page?
I only see it for reads beyond the VMA, but not e.g. when checking
terabytes of zero pages from an anonymous mapping.

    Arnd