Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Fri, 22 Sep 2023 11:49:13 +0200
Message-ID: <877coiedwm.wl-tiwai@suse.de>
From:   Takashi Iwai <tiwai@suse.de>
To:     "Ricardo B. Marliere" <ricardo@marliere.net>
Cc:     Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
        Ruslan Bilovol <ruslan.bilovol@gmail.com>,
        Sean Young <sean@mess.org>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        linux-media@vger.kernel.org, alsa-devel@alsa-project.org,
        linux-kernel@vger.kernel.org,
        linux-kernel-mentees@lists.linuxfoundation.org,
        syzbot+59875ffef5cb9c9b29e9@syzkaller.appspotmail.com
Subject: Re: [PATCH] sound: usb: increase snd_card alloc size
In-Reply-To: <87h6nmegt9.wl-tiwai@suse.de>
References: <20230922005152.163640-1-ricardo@marliere.net>
        <87h6nmegt9.wl-tiwai@suse.de>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Fri, 22 Sep 2023 10:46:26 +0200,
Takashi Iwai wrote:
> 
> On Fri, 22 Sep 2023 02:51:53 +0200,
> Ricardo B. Marliere wrote:
> > 
> > Syzbot reports a slab-out-of-bounds read of a snd_card object. When
> > snd_usb_audio_create calls snd_card_new, it passes sizeof(*chip) as the
> > extra_size argument, which is not enough in this case.
> > 
> > Relevant logs below:
> > 
> > BUG: KASAN: slab-out-of-bounds in imon_probe+0x2983/0x3910
> > Read of size 1 at addr ffff8880436a2c71 by task kworker/1:2/777
> > (...)
> > The buggy address belongs to the object at ffff8880436a2000
> >  which belongs to the cache kmalloc-4k of size 4096
> > The buggy address is located 1 bytes to the right of
> >  allocated 3184-byte region [ffff8880436a2000, ffff8880436a2c70)
> > 
> > Reported-by: syzbot+59875ffef5cb9c9b29e9@syzkaller.appspotmail.com
> > Closes: https://lore.kernel.org/all/000000000000a838aa0603cc74d6@google.co/m
> > Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
> > ---
> >  sound/usb/card.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/sound/usb/card.c b/sound/usb/card.c
> > index 1b2edc0fd2e9..6578326d33e8 100644
> > --- a/sound/usb/card.c
> > +++ b/sound/usb/card.c
> > @@ -619,7 +619,7 @@ static int snd_usb_audio_create(struct usb_interface *intf,
> >  	}
> >  
> >  	err = snd_card_new(&intf->dev, index[idx], id[idx], THIS_MODULE,
> > -			   sizeof(*chip), &card);
> > +			   sizeof(*chip) + 2, &card);
> 
> Sorry, it's no-no.  We have to fix the cause of the OOB access instead
> of papering over with a random number of increase.
> 
> Unfortunately, most important piece of information is trimmed in the
> changelog, so I can't judge what's going on.  The only useful info
> there is that it's something to do with imon driver, but it's
> completely independent from USB-audio.  How does it access to the
> external memory allocated by snd-usb-audio driver at all?
> 
> Before jumping to the solution, we must understand the problem.

Now I took a look at the syzbot URL and got more info.

Through a quick glance, my wild guess is that two different drivers
are bound to two interfaces of the device, the first one to usb-audio
and the second one to imon.  And imon driver blindly assumes that the
first interface is bound with imon, too, and that can be the cause.
A patch like below (totally untested!) might fix the problem.

Can you reproduce the problem in your side?  Or did you pick this up
randomly without testing?

In anyway, let's put media people to Cc.


thanks,

Takashi

--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -2427,6 +2427,12 @@ static int imon_probe(struct usb_interface *interface,
 		goto fail;
 	}
 
+	if (first_if->dev.driver != interface->dev.driver) {
+		dev_err(&interface->dev, "inconsistent driver matching\n");
+		ret = -EINVAL;
+		goto fail;
+	}
+
 	if (ifnum == 0) {
 		ictx = imon_init_intf0(interface, id);
 		if (!ictx) {