linux-kernel - Re: [PATCH] Fix shift-out-of-bound in mceusb_process_ir

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAD-N9QUzK+chpT+p9M+b1TAYUagNVGenChCU-rqD0XxVbcAYrw@mail.gmail.com>
Date:   Thu, 14 Jan 2021 11:03:27 +0800
From:   慕冬亮 <mudongliangabcd@...il.com>
To:     Sean Young <sean@...s.org>
Cc:     mchehab@...nel.org, linux-media@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Fix shift-out-of-bound in mceusb_process_ir_data

On Wed, Jan 13, 2021 at 10:27 PM Sean Young <sean@...s.org> wrote:
>
> On Wed, Jan 13, 2021 at 07:11:22PM +0800, Dongliang Mu wrote:
> > The missing check of ir->buf_in[i+1] can lead to an shift-out-of-bound
> > in mceusb_handle_command or mceusb_dev_printdata. This patch adds a
> > check to limit its value lower than 16. The concrete report of UBSAN is
> > as follows.
> >
> > UBSAN: shift-out-of-bounds in drivers/media/rc/mceusb.c:704:13
> > shift exponent 230 is too large for 32-bit type 'unsigned int'
> > CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.0-syzkaller #0
> > Call Trace:
> >  <IRQ>
> >  __dump_stack lib/dump_stack.c:79 [inline]
> >  dump_stack+0x107/0x163 lib/dump_stack.c:120
> >  ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
> >  __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395
> >  mceusb_dev_printdata.cold+0x19/0x1e drivers/media/rc/mceusb.c:704
> >  mceusb_process_ir_data drivers/media/rc/mceusb.c:1275 [inline]
> >  mceusb_dev_recv+0x3cb/0x1990 drivers/media/rc/mceusb.c:1376
> >  __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1657
> >  usb_hcd_giveback_urb+0x38c/0x430 drivers/usb/core/hcd.c:1728
> >  dummy_timer+0x11f4/0x32a0 drivers/usb/gadget/udc/dummy_hcd.c:1971
> >
> > Signed-off-by: Dongliang Mu <mudongliangabcd@...il.com>
> > ---
> >  drivers/media/rc/mceusb.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> > index f9616158bcf4..755808c6e747 100644
> > --- a/drivers/media/rc/mceusb.c
> > +++ b/drivers/media/rc/mceusb.c
> > @@ -1272,6 +1272,8 @@ static void mceusb_process_ir_data(struct mceusb_dev *ir, int buf_len)
> >               switch (ir->parser_state) {
> >               case SUBCMD:
> >                       ir->rem = mceusb_cmd_datasize(ir->cmd, ir->buf_in[i]);
> > +                     if (ir->buf_in[i+1] >= 16)
> > +                             continue;
>
> I'm not sure this is correct. This checks the second byte for *any* response,
> not just MCE_RSP_EQIRCFS response which is causing the "shift out of bounds"
> issue.
>

I am not familiar with the logic of this driver and the semantics of
ir->buf_in[i+1]. I just added one filter and if it breaks the
condition, then skip the current loop.

> I think the check belongs within the MCE_RSP_EQIRCFS case.
>
> Lastly it should have been break, not continue.

If this error data could affect the following parser_state and makes
it stop in the logic, "break" is better.

>
> Thanks
>
> Sean
>
>
>
> >                       mceusb_dev_printdata(ir, ir->buf_in, buf_len, i - 1,
> >                                            ir->rem + 2, false);
> >                       if (i + ir->rem < buf_len)
> > --
> > 2.25.1