On Mon, Jul 27, 2020 at 4:43 PM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > On Mon, Jul 27, 2020 at 04:05:38PM +0200, Arnd Bergmann wrote: > > On Mon, Jul 27, 2020 at 3:16 PM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > > > > > On Mon, Jul 27, 2020 at 09:25:16AM +0200, Arnd Bergmann wrote: > > > > On Mon, Jul 27, 2020 at 12:28 AM Peilin Ye <yepeilin.cs@xxxxxxxxx> wrote: > > > > > > > > > > video_put_user() is copying uninitialized stack memory to userspace due > > > > > to the compiler not initializing holes in the structures declared on the > > > > > stack. Fix it by initializing `ev32` and `vb32` using memset(). > > > > > > > > > > Reported-and-tested-by: syzbot+79d751604cb6f29fbf59@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > Link: https://syzkaller.appspot.com/bug?extid=79d751604cb6f29fbf59 > > > > > Reviewed-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> > > > > > Signed-off-by: Peilin Ye <yepeilin.cs@xxxxxxxxx> > > > > > > > > Thanks a lot for addressing this! I now see that I actually created a similar > > > > bugfix for it back in January, but for some reason that got stuck in my > > > > backlog and I never wrote a proper description for it or sent it out to the > > > > list, sorry about that. I would hope we could find a way to have either > > > > the compiler or sparse warn if we copy uninitialized data to user space, > > > > but we now don't even check for that within the kernel any more. > > > > > > Here are my latest warnings on linux-next from Friday. > > > > Ah, I forgot you had that kind of list already, thanks for checking! > > > > > block/scsi_ioctl.c:707 scsi_put_cdrom_generic_arg() warn: check that 'cgc32' doesn't leak information (struct has a hole after 'data_direction') > > > > I see no padding in this one, should be fine AFAICT. Any idea why you > > get a warning > > for this instance? > > > > The warning message only prints the first struct hole or uninitialized > struct memeber. ->data_direction in this case. > > block/scsi_ioctl.c > 646 #ifdef CONFIG_COMPAT > 647 struct compat_cdrom_generic_command { > 648 unsigned char cmd[CDROM_PACKET_SIZE]; > 649 compat_caddr_t buffer; > 650 compat_uint_t buflen; > 651 compat_int_t stat; > 652 compat_caddr_t sense; > 653 unsigned char data_direction; > > There is going to be 3 bytes of padding between this char and the next > int. > > 654 compat_int_t quiet; > 655 compat_int_t timeout; > 656 compat_caddr_t reserved[1]; > 657 }; > 658 #endif > > The bug seems real, but it depends on the compiler of course. Right, I misread the single 'char' in there. > > > drivers/input/misc/uinput.c:743 uinput_ff_upload_to_user() warn: check that 'ff_up_compat' doesn't leak information (struct has a hole after 'replay') > > > > This one hs padding in it and looks broken. > > No. This a bug in smatch. It's memcpy() over the hole, but the check > isn't capturing that. The code is slightly weird... I could try > silence the warning but it would only silence this one false positive so > I haven't investigated it. Ah right, and the structure it copies in turn comes from user space originally. > > > drivers/scsi/megaraid/megaraid_mm.c:824 kioc_to_mimd() warn: check that 'cinfo.base' doesn't leak information > > > > Seems fine due to __packed annotation. > > > > It's not related __packed. Smatch is saying that cinfo.base isn't > necessarily initialized. > > drivers/scsi/megaraid/megaraid_mm.c > 816 > 817 case MEGAIOC_QADAPINFO: > 818 > 819 hinfo = (mraid_hba_info_t *)(unsigned long) > 820 kioc->buf_vaddr; > 821 > 822 hinfo_to_cinfo(hinfo, &cinfo); > > hinfo_to_cinfo() is a no-op if hinfo is NULL. Smatch can't tell if > "hinfo" is non-NULL. Ok, that sounds fair, I couldn't easily tell either ;-) Arnd
