Re: [PATCH 1/3] s390/pci: Adjust alignment in insn trace

[Niklas Schnelle <schnelle@linux.ibm.com>]

On Wed, 2026-10-07 at 15:10 +0200, Gerd Bayer wrote:
> On Wed, 2026-10-07 at 11:14 +0000, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Medium] s390/pci: info leak of kernel stack memory in trace buffer due to unnamed bit-fields
> > --
> > 
> > commit 9eddce7825c1b38a4a78855744726217e301528b
> > Author: Gerd Bayer <gbayer@linux.ibm.com>
> > 
--- snip ---
> > 
> > [Severity: Medium]
> > Does this change unintentionally leak kernel stack memory into the s390dbf
> > debug trace ring buffer?
> > 
> > By using unnamed bit-fields for padding, these fields are explicitly
> > excluded from zero-initialization when using a designated initializer.
> > 
> > When zpci_err_insn_req() in arch/s390/pci/pci_insn.c initializes this
> > structure on the stack without an explicit memset(), the unnamed padding
> > bytes retain their uninitialized stack memory:
> > 
> > static inline void zpci_err_insn_req(...)
> > {
> >         struct zpci_err_insn_data data = {
> >                 .insn = insn, .cc = cc, .status = status,
> >                 .req = req, .offset = offset};
> > 
> >         zpci_err_hex_level(lvl, &data, sizeof(data));
> > }
> > 
> > The subsequent call to zpci_err_hex_level() will copy the entire 32-byte
> > structure to the trace buffer, exposing 13 bytes of uninitialized stack
> > data.
> > 
> > Will this also defeat the goal of having clean traces for humans, since
> > the hex dumps will contain random stack data instead of zeroes?
> 
> 
> Alright, according to some research [1][2] unnamed bit-fields are not
> guaranteed to be zero-initialized. I'll provide dummy-names for the
> padding fields in the next iteration.

Agree and to be honest I do like named reserved fields better for
readability too. Other than this issue this all looks good to me and
should definitely make the hex_error easier to read.

Thanks,
Niklas
> >