linux-kernel - Re: [PATCH] media: dvb: fix a missing-check bug

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 27 Nov 2018 10:43:25 +0000
From:   Sean Young <sean@...s.org>
To:     Wenwen Wang <wang6495@....edu>
Cc:     Kangjie Lu <kjlu@....edu>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        viro@...iv.linux.org.uk,
        "open list:STAGING - ATOMISP DRIVER" <linux-media@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] media: dvb: fix a missing-check bug

Hi Wenwen,

On Mon, Oct 29, 2018 at 01:46:04PM -0500, Wenwen Wang wrote:
> Hello,
> 
> Can anyone confirm this bug? Thanks!
> 
> Wenwen
> 
> On Fri, Oct 19, 2018 at 9:12 AM Wenwen Wang <wang6495@....edu> wrote:
> >
> > In dvb_audio_write(), the first byte of the user-space buffer 'buf' is
> > firstly copied and checked to see whether this is a TS packet, which always
> > starts with 0x47 for synchronization purposes. If yes, ts_play() will be
> > called. Otherwise, dvb_aplay() will be called. In ts_play(), the content of
> > 'buf', including the first byte, is copied again from the user space.
> > However, after the copy, no check is re-enforced on the first byte of the
> > copied data.  Given that 'buf' is in the user space, a malicious user can
> > race to change the first byte after the check in dvb_audio_write() but
> > before the copy in ts_play().

Up to here your analysis makes sense.

> >  Through this way, the user can supply
> > inconsistent code, which can cause undefined behavior of the kernel and
> > introduce potential security risk.

So how can this cause undefined behaviour?

> > This patch adds a necessary check in ts_play() to make sure the first byte
> > acquired in the second copy contains the expected value. Otherwise, an
> > error code EINVAL will be returned.

So what about the other case, if dvb_play() was called due to the first
byte not being 0x47 and then swapped for 0x47?


Sean

> >
> > Signed-off-by: Wenwen Wang <wang6495@....edu>
> > ---
> >  drivers/media/pci/ttpci/av7110_av.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/media/pci/ttpci/av7110_av.c b/drivers/media/pci/ttpci/av7110_av.c
> > index ef1bc17..1ff6062 100644
> > --- a/drivers/media/pci/ttpci/av7110_av.c
> > +++ b/drivers/media/pci/ttpci/av7110_av.c
> > @@ -468,6 +468,8 @@ static ssize_t ts_play(struct av7110 *av7110, const char __user *buf,
> >                 }
> >                 if (copy_from_user(kb, buf, TS_SIZE))
> >                         return -EFAULT;
> > +               if (kb[0] != 0x47)
> > +                       return -EINVAL;
> >                 write_ts_to_decoder(av7110, type, kb, TS_SIZE);
> >                 todo -= TS_SIZE;
> >                 buf += TS_SIZE;
> > --
> > 2.7.4
> >