| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20220415105152.nwj4gd7pizco2kkx@ppc.localdomain>
Date: Fri, 15 Apr 2022 18:51:52 +0800
From: Wang Cheng <wanngchenng@...il.com>
To: Dan Carpenter <dan.carpenter@...cle.com>
Cc: Larry.Finger@...inger.net, florian.c.schilhabel@...glemail.com,
gregkh@...uxfoundation.org, linux-staging@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: rtl8712: fix uninit-value "data" and "mac"
On 22/04/15 12:57PM, Dan Carpenter wrote:
> On Fri, Apr 15, 2022 at 05:47:05PM +0800, Wang Cheng wrote:
> > Hi Dan, thx for your review.
> >
> > On 22/04/14 06:42PM, Dan Carpenter wrote:
> > > On Thu, Apr 14, 2022 at 10:12:23PM +0800, Wang Cheng wrote:
> > > > Due to the case that "requesttype == 0x01 && status <= 0"
> > > > isn't handled in r8712_usbctrl_vendorreq(),
> > > > "data" (drivers/staging/rtl8712/usb_ops.c:32)
> > > > will be returned without initialization.
> > > >
> > > > When "tmpU1b" (drivers/staging/rtl8712/usb_intf.c:395)
> > > > is 0, mac[6] (usb_intf.c:394) won't be initialized,
> > > > which leads to accessing uninit-value on usb_intf.c:541.
> > >
> > > These line numbers are sort of useless because everyone is on a
> > > different git hash.
> >
> > I will correct this.
> >
> > >
> > > >
> > > > Reported-and-tested-by: syzbot+6f5ecd144854c0d8580b@...kaller.appspotmail.com
> > > > Signed-off-by: Wang Cheng <wanngchenng@...il.com>
> > > > ---
> > > > drivers/staging/rtl8712/usb_intf.c | 6 +++---
> > > > drivers/staging/rtl8712/usb_ops_linux.c | 14 ++++++++------
> > > > 2 files changed, 11 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/rtl8712/usb_intf.c b/drivers/staging/rtl8712/usb_intf.c
> > > > index ee4c61f85a07..50dcd3ecb685 100644
> > > > --- a/drivers/staging/rtl8712/usb_intf.c
> > > > +++ b/drivers/staging/rtl8712/usb_intf.c
> > > > @@ -538,13 +538,13 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf,
> > > > } else {
> > > > AutoloadFail = false;
> > > > }
> > > > - if (((mac[0] == 0xff) && (mac[1] == 0xff) &&
> > > > + if ((!AutoloadFail) ||
> > > > + ((mac[0] == 0xff) && (mac[1] == 0xff) &&
> > > > (mac[2] == 0xff) && (mac[3] == 0xff) &&
> > > > (mac[4] == 0xff) && (mac[5] == 0xff)) ||
> > > > ((mac[0] == 0x00) && (mac[1] == 0x00) &&
> > > > (mac[2] == 0x00) && (mac[3] == 0x00) &&
> > > > - (mac[4] == 0x00) && (mac[5] == 0x00)) ||
> > > > - (!AutoloadFail)) {
> > > > + (mac[4] == 0x00) && (mac[5] == 0x00))) {
> > > > mac[0] = 0x00;
> > > > mac[1] = 0xe0;
> > > > mac[2] = 0x4c;
> > >
> > > This is a separate fix from the rest of the patch. Send it by itself.
> >
> > Ah, thought to send a patch series.
> >
>
> Yes, please. Send two patches.
>
> > >
> > >
> > > > diff --git a/drivers/staging/rtl8712/usb_ops_linux.c b/drivers/staging/rtl8712/usb_ops_linux.c
> > > > index f984a5ab2c6f..e321ca4453ca 100644
> > > > --- a/drivers/staging/rtl8712/usb_ops_linux.c
> > > > +++ b/drivers/staging/rtl8712/usb_ops_linux.c
> > > > @@ -495,12 +495,14 @@ int r8712_usbctrl_vendorreq(struct intf_priv *pintfpriv, u8 request, u16 value,
> > > > }
> > > > status = usb_control_msg(udev, pipe, request, reqtype, value, index,
> > > > pIo_buf, len, 500);
> > > > - if (status > 0) { /* Success this control transfer. */
> > > > - if (requesttype == 0x01) {
> > > > - /* For Control read transfer, we have to copy the read
> > > > - * data from pIo_buf to pdata.
> > > > - */
> > > > - memcpy(pdata, pIo_buf, status);
> > > > + /* For Control read transfer, copy the read data from pIo_buf to pdata
> > > > + * when control transfer success; otherwise init *pdata with 0.
> > > > + */
> > > > + if (requesttype == 0x01) {
> > > > + if (status > 0)
> > > > + memcpy(pdata, pIo_buf, status);
> > > > + else
> > > > + *(u32 *)pdata = 0;
> > > > }
> > >
> > > This isn't really correct. In many cases status is "len" is less than 4.
> > > I'm slightly surprised that nothing complains about that as an
> > > uninitialized access. But then another problem is that "status" can be
> > > less than "len".
> >
> > Sorry, I should explain it clearly. If I did right, watching "status"
> > with gdb while running syzkaller reproducer, "status" returns from
> > usb_control_msg() is -71. In which case, *pdata won't be touched in
> > r8712_usbctrl_vendorreq(). As a result, "data" in
> > usb_read8()/usb_read16()/usb_read32() will be returned without
> > initialization. I think that is why kmsan reports:
> > Local variable data created at:
> > usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33
> > r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29
>
> Yes. I understood that.
>
> >
> > >
> > > A better fix instead of setting pdata to zero would be to add error
> > > checking in the callers and then change this code to use
> > > usb_control_msg_send/recv(). Probably just initialize "data" in the
> > > callers as well.
> >
> > I tried something similar which also works fine, but I think this patch
> > does't fix it at root.
> > https://syzkaller.appspot.com/text?tag=Patch&x=15be2970f00000
> >
>
> Ugh... Sorry, I had not looked closely at usb_read8() and friends.
> (This code is all so terrible). Ideally they would have some way to
> return errors. Oh well. Anyway, I guess do like this:
>
> status = r8712_usbctrl_vendorreq(intfpriv, request, wvalue, index,
> &data, len, requesttype);
> if (status < 0)
> return 0;
> return (u8)(le32_to_cpu(data) & 0x0ff);
>
> But in r8712_usbctrl_vendorreq() you really need to make the other
> changes I mentioned as well. If you want to do it as a separate patch
> that's fine too.
>
> if (status < 0)
> return status;
> if (status != len)
> return -EREMOTEIO;
>
> if (reqtype == 0x1)
> memcpy();
>
> return 0;
Thx for your time and advice, Dan. Yeah, the code logic looks not easy.
I will think about these code snippets and handle them.
thanks,
-- w
Powered by blists - more mailing lists