On Mon, Jul 27, 2020 at 4:43 PM Dan Carpenter <dan.carpen...@oracle.com> 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.carpen...@oracle.com>
> > 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...@gmail.com>
> > > > 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+79d751604cb6f29fb...@syzkaller.appspotmail.com
> > > > > Link: https://syzkaller.appspot.com/bug?extid=79d751604cb6f29fbf59
> > > > > Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> > > > > Signed-off-by: Peilin Ye <yepeilin...@gmail.com>
> > > >
> > > > 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
