[PATCH v6] linux: Add openat2 (BZ 31664)
Paul Eggert
eggert@cs.ucla.edu
Tue Nov 18 20:12:46 GMT 2025
On 2025-11-18 11:49, Adhemerval Zanella Netto wrote:
>
>
> On 18/11/25 16:12, Paul Eggert wrote:
>> On 2025-11-10 08:19, Adhemerval Zanella wrote:
>>> +extern int openat2 (int __dfd, const char *__restrict __filename,
>>> + const struct open_how *__restrict __how,
>>> + size_t __usize)
>>> + __nonnull ((2, 3));
>>
>> Shouldn't this be fortified at compile time, by using __builtin_object_size to check that __usize <= sizeof *__how, when fortify checking is enabled?
>
> I am not sure how useful this would be, the kernel will return an error
> if user pass an invalid value
The kernel also returns an error if you pass a null pointer, but that
doesn't mean we should remove the __nonnull ((2, 3)) as it's useful to
warn users when they're screwing up with bad pointers. Similarly for
warning users about bad sizes.
> in theory if the open_how is extended
> user still make a valid call with '__ussize <= sizeof *__how' as long
> the size refers to a valid size
No, the size must be invalid if it is greater than the size of the
object being addressed. Whether the kernel supports larger sizes is
irrelevant.
> The fortify wrapper would need to handle all the open_how possible
> versions, or just support the latest one.
We can't and shouldn't expect the fortify wrapper to catch all possible
ways a syscall might fail. All it needs to do is catch obvious mistakes
about bad pointers and bad sizes, which is what I'm suggesting here.
More information about the Libc-alpha
mailing list