Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1028116ybl; Wed, 14 Aug 2019 09:35:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqx95eqc2YwZ0aYHaIWQFd1qKM4TgVwV9Y1j3382KETEb/TBxSzuPYd73ToetKZdnyJ58rsw X-Received: by 2002:a65:4509:: with SMTP id n9mr59073pgq.133.1565800523296; Wed, 14 Aug 2019 09:35:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565800523; cv=none; d=google.com; s=arc-20160816; b=yVIn3G9lWZ0nAEIIg/4u9y0D9i1p22BNTvotjQrFXJ4Kgh9WjUQgmGSRvMdhUtt3ho 5rkMAEt4TOBTF2UyfSlogGx76wTWkUOiIGqyGEPanKfD4R3E3v8w/so9Bmk45wAa03s6 OhCo8y3pKVyWJwU2qguy8H02dyIELJR/hzb086Tkyr0sQjAP91UztyAGr8r7Vc0I9DQe 1/M9WUeFVe0G5hzGs3HmZ0Gy3Ty0ak/XxG6i3viD04oDrck9q20bkj/0by0yZMagZZwv Ka7Zi/5wSbams/h0TzyPqRmH3BDdj4knq3/L9H6UHuq3/mnzZn30KS2bdSlLVrCrzFSF ompA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:subject:cc:to:from:message-id :date; bh=laJVUgHDB3+xE81mXVFQxCAc0VQvra62JVD4ZL+VOAg=; b=oIN9f095YSnYQaSeOm5/mORdjPqPRw1udxnQ+ogmuBWqiwgPOBFr4lJyC24Q3a4hHN WzzwK81eK/wlcEQ+S7D1CXrTnLLedeBK1CwQvdLpRkpTDU2H5Pzq+UQYiW8EVWdKfbV9 lr55OyNToCau5tltlX6B1lYdE/1g43vJjMWCUvxiezjq1DtyC7UT38596jUdD2KtmR0J zgtKNsLN1la89+d+28SV/E3sfW8ZomcoOJX6fNnRcXYf5Bzv+0lznyHe82vNiSMZYbk/ GfaJUCWalmvwtLwoijY+b0iAGDaARQGmQTqtlx74dfIU9zVpfnoBawDTVTRuca2X+6E9 S5Ow== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b42si159932pjc.18.2019.08.14.09.35.07; Wed, 14 Aug 2019 09:35:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728327AbfHNQdE (ORCPT + 99 others); Wed, 14 Aug 2019 12:33:04 -0400 Received: from mx2.suse.de ([195.135.220.15]:47332 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726166AbfHNQdE (ORCPT ); Wed, 14 Aug 2019 12:33:04 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id F1463B061; Wed, 14 Aug 2019 16:33:01 +0000 (UTC) Date: Wed, 14 Aug 2019 18:33:01 +0200 Message-ID: From: Takashi Iwai To: =?UTF-8?B?5b2t6L6J?= Cc: security@kernel.org, alsa-devel@alsa-project.org, YueHaibing , Thomas Gleixner , Allison Randal , Mathias Payer , Jaroslav Kysela , Takashi Iwai , Wenwen Wang , linux-kernel@vger.kernel.org Subject: Re: [PATCH] Fix an OOB bug in parse_audio_mixer_unit In-Reply-To: References: <20190814023625.21683-1-benquike@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 14 Aug 2019 18:28:39 +0200, 彭辉 wrote: > > Hi, Takashi: > Here the problem is that `desc->bLength` is controlled by the device side, > so  `desc->bLength` may not represent the real length of the descriptor. > That is why I use pointer arithmetic operations to derive the real size of the > buffer > in my patch. But bLength is checked before calling this, i.e. it's already assured that bLength fits within the buffer limit. So, the result calls don't have to care about the buffer limit itself, and they can just concentrate on overflow over bLength. thanks, Takashi > > On Wed, Aug 14, 2019 at 2:36 AM 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 > > Reported-by: Hui Peng > > Reported-by: Mathias Payer > > --- > >  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; > >         switch (state->mixer->protocol) { >         case UAC_VERSION_1: > > -- > May the Lord Richly Bless you and yours ! > >