[PATCH v2] linux: Enforce zero fill of siginfo_t

Florian Weimer fweimer@redhat.com
Mon Jan 26 17:22:21 GMT 2026


* Andreas Schwab:

> On Jan 26 2026, Florian Weimer wrote:
>
>>> On Tue, Jan 20, 2026 at 8:14 AM Adhemerval Zanella
>>> <adhemerval.zanella@linaro.org> wrote:
>>>>
>>>> The glibc siginfo struct is larger than the kABI one, and the kernel
>>>> enforces that for an unknown si_code, all the extra bytes should be 0
>>>> (post_copy_siginfo_from_user).
>>>>
>>>> For armhf, gcc-15 is fully zero-filling the struct (it seems to be a
>>>> compiler issue, although I haven't found any already registered on
>>>> gcc bugzilla).
>>>
>>> i assume you mean "isn't" rather than "is" here, right? (since the `=
>>> { .a = b };` style is explicitly defined to zero out all the other
>>> bytes.)
>>>
>>> or do you meant that the compiler bug is that it's doing the zeroing
>>> but dropping the assignments?
>>
>> It's inclear what happens to the surrounding union.  The struct
>> initialization rules only apply to the active union member (if that's a
>> struct), as far as I understand it.
>
> Right, since the current initializer uses the _sifields._kill member
> (which only contains two ints) the rest of the union is not required to
> be initialized.  If you use = {0}, though, the compiler is required to
> clear the whole union, since the first member _pad spans it fully.

But that's subtly unportable, isn't it?  (Using 0 to initialize an array
aggregate, and assuming that the first member of the union is the
largest one.)  So using memset is probably better, given that tests
ideally show exemplary usage of interfaces.

Thanks,
Florian



More information about the Libc-alpha mailing list