linux-kernel - Re: [PATCH RFC v3 02/10] sched_getattr: port to copy_struct_to

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: <87y10nz9qo.fsf@oldenburg.str.redhat.com>
Date: Tue, 10 Dec 2024 19:14:07 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Aleksa Sarai <cyphar@...har.com>
Cc: 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>,
 Ben 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>,
 Arnd Bergmann <arnd@...db.de>,  Shuah Khan <shuah@...nel.org>,
 Kees Cook <kees@...nel.org>,  Mark Rutland <mark.rutland@....com>,
 linux-kernel@...r.kernel.org,  linux-api@...r.kernel.org,
 linux-fsdevel@...r.kernel.org,  linux-arch@...r.kernel.org,
 linux-kselftest@...r.kernel.org, libc-alpha@...rceware.org
Subject: Re: [PATCH RFC v3 02/10] sched_getattr: port to copy_struct_to_user

* Aleksa Sarai:

> sched_getattr(2) doesn't care about trailing non-zero bytes in the
> (ksize > usize) case, so just use copy_struct_to_user() without checking
> ignored_trailing.

I think this is what causes glibc's misc/tst-sched_setattr test to fail
on recent kernels.  The previous non-modifying behavior was documented
in the manual page:

       If the caller-provided attr buffer is larger than the kernel's
       sched_attr structure, the additional bytes in the user-space
       structure are not touched.

I can just drop this part of the test if the kernel deems both behaviors
valid.

Thanks,
Florian