linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Hui Peng <benquike@gmail.com>,
	security@kernel.org, alsa-devel@alsa-project.org,
	YueHaibing <yuehaibing@huawei.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Allison Randal <allison@lohutok.net>,
	Mathias Payer <mathias.payer@nebelwelt.net>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	Wenwen Wang <wang6495@umn.edu>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Fix an OOB bug in parse_audio_mixer_unit
Date: Wed, 14 Aug 2019 17:14:25 +0200	[thread overview]
Message-ID: <s5h8srvdbji.wl-tiwai@suse.de> (raw)
In-Reply-To: <20190814090921.GO1935@kadam>

On Wed, 14 Aug 2019 11:09:21 +0200,
Dan Carpenter wrote:
> 
> On Wed, Aug 14, 2019 at 08:36:42AM +0200, Takashi Iwai wrote:
> > On Wed, 14 Aug 2019 04:36:24 +0200,
> > Hui Peng wrote:
> > > 
> > > The `uac_mixer_unit_descriptor` shown as below is read from the
> > > device side. In `parse_audio_mixer_unit`, `baSourceID` field is
> > > accessed from index 0 to `bNrInPins` - 1, the current implementation
> > > assumes that descriptor is always valid (the length  of descriptor
> > > is no shorter than 5 + `bNrInPins`). If a descriptor read from
> > > the device side is invalid, it may trigger out-of-bound memory
> > > access.
> > > 
> > > ```
> > > struct uac_mixer_unit_descriptor {
> > > 	__u8 bLength;
> > > 	__u8 bDescriptorType;
> > > 	__u8 bDescriptorSubtype;
> > > 	__u8 bUnitID;
> > > 	__u8 bNrInPins;
> > > 	__u8 baSourceID[];
> > > }
> > > ```
> > > 
> > > This patch fixes the bug by add a sanity check on the length of
> > > the descriptor.
> > > 
> > > Signed-off-by: Hui Peng <benquike@gmail.com>
> > > Reported-by: Hui Peng <benquike@gmail.com>
> > > Reported-by: Mathias Payer <mathias.payer@nebelwelt.net>
> > > ---
> > >  sound/usb/mixer.c | 9 +++++++++
> > >  1 file changed, 9 insertions(+)
> > > 
> > > diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
> > > index 7498b5191b68..38202ce67237 100644
> > > --- a/sound/usb/mixer.c
> > > +++ b/sound/usb/mixer.c
> > > @@ -2091,6 +2091,15 @@ static int parse_audio_mixer_unit(struct mixer_build *state, int unitid,
> > >  	struct usb_audio_term iterm;
> > >  	int input_pins, num_ins, num_outs;
> > >  	int pin, ich, err;
> > > +	int desc_len = (int) ((unsigned long) state->buffer +
> > > +			state->buflen - (unsigned long) raw_desc);
> > > +
> > > +	if (desc_len < sizeof(*desc) + desc->bNrInPins) {
> > > +		usb_audio_err(state->chip,
> > > +			      "descriptor %d too short\n",
> > > +			      unitid);
> > > +		return -EINVAL;
> > > +	}
> > >  
> > >  	err = uac_mixer_unit_get_channels(state, desc);
> > >  	if (err < 0) {
> > 
> > Hm, what is the desc->bLength value in the error case?
> > 
> > Basically the buffer boundary is already checked against bLength in
> > snd_usb_find_desc() which is called from obtaining the raw_desc in the
> > caller of this function (parse_audio_unit()).
> > 
> > So, if any, we need to check bLength for the possible overflow like
> > below.
> > 
> > 
> > thanks,
> > 
> > Takashi
> > 
> > --- a/sound/usb/mixer.c
> > +++ b/sound/usb/mixer.c
> > @@ -744,6 +744,8 @@ static int uac_mixer_unit_get_channels(struct mixer_build *state,
> >  		return -EINVAL;
> >  	if (!desc->bNrInPins)
> >  		return -EINVAL;
> > +	if (desc->bLength < sizeof(*desc) + desc->bNrInPins)
> > +		return -EINVAL;
> 
> VERSION 1 and 2 already have a different check:
> 
> 	if (desc->bLength < sizeof(*desc) + desc->bNrInPins + 1)
> 		return 0; /* no bmControls -> skip */
>
> So something is possibly off by one.  It's just version 3 which doesn't
> have a check.
> 

No, both are sensible checks.  The first check is about the minimal
size that doesn't contain bmControls bitmap which is optional on some
devices, while the latter checks about the presence of bmControls
field.  Note that the latter returns zero, which means no error, while
the former returns an error.


thanks,

Takashi

  reply	other threads:[~2019-08-14 15:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-14  2:36 [PATCH] Fix an OOB bug in parse_audio_mixer_unit Hui Peng
2019-08-14  6:36 ` Takashi Iwai
2019-08-14  9:09   ` Dan Carpenter
2019-08-14 15:14     ` Takashi Iwai [this message]
     [not found]   ` <CAKpmkkUv=arsdJiexaM-UVhXEwfGN=zreny9P_kDNhQUij8=FQ@mail.gmail.com>
2019-08-14 16:33     ` Takashi Iwai
     [not found]       ` <CAKpmkkVzT5H0RTAu_Fa=9_gjf5v7k3qzPnnJvPpBp3BaP7G0ag@mail.gmail.com>
2019-08-14 18:21         ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5h8srvdbji.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=allison@lohutok.net \
    --cc=alsa-devel@alsa-project.org \
    --cc=benquike@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathias.payer@nebelwelt.net \
    --cc=perex@perex.cz \
    --cc=security@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tiwai@suse.com \
    --cc=wang6495@umn.edu \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).