[PATCH v2] linux: Enforce zero fill of siginfo_t

[Yury Khrustalev]

On Mon, Jan 26, 2026 at 06:22:21PM +0100, Florian Weimer wrote:
> * 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.

I agree that memset is probably better here. It's unknown where the
struct definition might come from. If a kernel header is used somehow,
pad is not first in there:

  typedef struct siginfo {
    union {
      __SIGINFO;
      int _si_pad[SI_MAX_SIZE/sizeof(int)];
    };
  } __ARCH_SI_ATTRIBUTES siginfo_t;

So, I think the original patch is OK, save for the comment wording.

Adhemerval, will you send v3?

Thanks,
Yury