[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