From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 66D9625B085 for ; Sun, 24 May 2026 14:45:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779633951; cv=none; b=RcBFTafUcF+kseFc7NPZ3RPJ+jQEevORKhMSuqP3s4biBs22mFnowvF9WrV5YicWDeIuu/+bHe9aCEpHWwrKufCHPfaFqo1o0MXVCf/Y1M3UxZObl854xDB4qsJiPfIJm6mobR205rhduC06V5xxfl603MeKhP+ZAOLnZAyTzIU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779633951; c=relaxed/simple; bh=TI0/L+GejtTeSIioccUte+z8YXT9gEPZ8z/ahtZfawQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pro8/v1UZ/6EdPD1HTKDIMih+hlRisS8fiBZyB/1Kkg9GNhRbFsq8mcbYxRGkbxK+3dPEnb2WGa9LnpIlWBtKehuATW54wP2s/cU/wK2lVhkOttzRIMhZLUCE4OTJwapWn9DBhv5rrcod7Dnhmh08YpHHQ1J5zENNbkQ6k4uFU4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu; spf=fail smtp.mailfrom=g.harvard.edu; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b=SiVoKvUT; arc=none smtp.client-ip=209.85.160.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=g.harvard.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b="SiVoKvUT" Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-516d61baff3so29534321cf.0 for ; Sun, 24 May 2026 07:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowland.harvard.edu; s=google; t=1779633947; x=1780238747; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=jDeJRb2nrc+/qAN65EJRxpxoDR8UwF/XfIcD8wa9bss=; b=SiVoKvUTYGwbwLKA7tF00uC3RFMq9EdXB3xSiLPXiTjpAIby6S0//EumIidUtbfSwA 5ku0LAlal7XH1GgppDHoUQCunITrju3QkzhcS7EzCK32tGvQfDN4cn/xMb7IHwuN4qPz LoVZIRQUqVEq9AlLqAHyLUxBZeypOcKCKiSFufORqI9sEq0a93yGrMxRT1R7s6Ya4tjj /5EmDCiMwD41a9JtDhsOBwQRaKStlHHhzGK22D4K5Ja5V2Adms1C7ckdk1IA33jcljCF RgAIofpVyEIr0wjNR09tAX3NmuSnxGkhT1xjgqKG3XJSVmquhhVkS8IYEZTf+YVsZ/aY eRtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779633947; x=1780238747; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jDeJRb2nrc+/qAN65EJRxpxoDR8UwF/XfIcD8wa9bss=; b=EiDPC4H1xXNlA8OWEN1PKPDj3sTppVahGX1OQLLn9bhCo1fqrdg5HJO+Zpi8BW1r1X 3uixuLoUJLLdw/gtZkBB+NQt6Kra6iuB/jKtfhgxatp2c/JnEJO1Wm4FC3v3HypKaYG5 ZbSvVU21fGny66Cvl2BV9SOVkgVFHcCA92ojSP7zkz6Amt0Gb2AQqFrH3hEfdjBv/Tc8 wC0LWkwjkEiFr0SUVW3gyOzTv0dNx7fGxCNw8tWLqA8QCQIDwCPYjfxELGXGDyyamu45 SjwNfs1G+GOMEj1u81H2agxAWTBssvPufirx9+E466zIlh5AXvjkgM7w8jTRGdKmisq3 C42g== X-Forwarded-Encrypted: i=1; AFNElJ/4yIos4f2PdWz58Y/iHiQfOOuXHVrKSjOUAW9c5Z0VU5+fUEuzSXLc7OBSq89qzmBXbKwDPg2h8DrS4rA=@vger.kernel.org X-Gm-Message-State: AOJu0YycMtxUSXKf/BO61Ys99AsAF7tpkNERiBoCcArZP8tcaZGWmWnX JQ2FmUHEuNsf0BiJOa7qGojF+IUyG3nZFQtTAcw0WsHmRtcAbNEnvSaV1yoRuiKPrQ== X-Gm-Gg: Acq92OGQCjom7J7+JIJp1jCvlY3+O2lJyOMMXnN6TKmE/l7wvLlUlSB7MiUyujZBsql J4UkIj8BXMs1Ch7CSMMMGBi2j59ATHMRg+AofJRZtTOia3vdUZ4FuCg08awPk18ItsUWfkA+nej RWktOzM1hOJazYwrezOArFNBCWp0vO9jiCCDtS7fWEAB5JzTaSHB1L+BsrvqfwNDb//yiSlEwjp KTZzw3Rwgay1hMgxqgtVYB2cw/qgDdl59UqNIVdVniGFC4ddNOeBW1HV9Y/Z7y/UqjIlES7XJsB nZ8R095+7LUyc6tISePDSa0M1A88WDk37sd2bl3rnOTd6tboeZL5dISEYJnHTLaWTK5CUfpfxiI gblF44PGpt0ItNHeWZyZg6Ta44buf0YANpvKPEFxulhVFcTm2/Qso27NiwjXEe0yjCrIHq9OIsD 9PIRziZ37Q4RosUyPaQW6qMt17rxNtgibti9VU7gD+4/g= X-Received: by 2002:ac8:7d0e:0:b0:516:e8aa:25e with SMTP id d75a77b69052e-516e8aa076emr63544651cf.55.1779633947167; Sun, 24 May 2026 07:45:47 -0700 (PDT) Received: from rowland.harvard.edu ([2601:19b:d01:d210:d62f:1911:f952:16ba]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-516d8d09e42sm70737431cf.28.2026.05.24.07.45.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 May 2026 07:45:46 -0700 (PDT) Date: Sun, 24 May 2026 10:45:39 -0400 From: Alan Stern To: Michal Pecio Cc: Joseph Bursey , syzbot , gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] [usb?] KASAN: slab-use-after-free Write in iowarrior_write_callback (2) Message-ID: <69c60a2a-68d2-48b0-8236-b80cd6b602cf@rowland.harvard.edu> References: <6a0ce39b.170a0220.39a13.0007.GAE@google.com> <32c79569-8001-48d2-9675-b38b1670f285@uci.edu> <20260524103053.308501de.michal.pecio@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260524103053.308501de.michal.pecio@gmail.com> On Sun, May 24, 2026 at 10:30:53AM +0200, Michal Pecio wrote: > On Fri, 22 May 2026 13:38:40 -0700, Joseph Bursey wrote: > > Hello, I believe I have a reproducer for this bug using a combination > > of syz-execprog and eBPF programs. > > Hi, could you check if this patch (compile tested only) fixes it? > > I admit I'm not an expert on USB core, but I see nothing _reliably_ > preventing URB submissions after usb_disable_interface(), which may > be the root cause of this bug (besides the driver sloppiness for > which separate patches have been posted by Johan Hovold). The general attitude has been that it isn't the core's responsibility to recover from bugs caused by drivers. Rather, it is the programmers' responsibility to fix the bugs properly. On the other hand, it won't hurt to add some code to the core for detecting and reporting buggy driver behavior, so that the programmers would know about it. > My patch tries to fix it by updating ep->enabled under a spinlock > which will be held while checking this flag on submission attempts. > > Such bug is trouble not only for sloppy drivers, but also for HCDs > which assume that no URBs exist while endpoints are being "dropped". > Syzbot and you apparently found ways to break this assumption: > > static int usb_unbind_interface(struct device *dev) > { > [...] > /* > * Terminate all URBs for this interface unless the driver > * supports "soft" unbinding and the device is still present. > */ > if (!driver->soft_unbind || udev->state == USB_STATE_NOTATTACHED) > usb_disable_interface(udev, intf, false); > // no URBs should be pending on these endpoints now Depends on whether the driver has the soft_unbind flag set and whether the device is still attached, obviously. > > driver->disconnect(intf); But definitely no URBs should be pending now. > // but one is observed completing concurrently now > > I also suspect that more UAF in sloppy drivers is possible due to > usb_hcd_flush_endpoint() failing to wait for pending BH givebacks. usb_hcd_flush_endpoint() only guarantees that the HCD is finished dealing with any pending URBs. It is not meant to guarantee that the URBs' completion handlers have run. > It seems that dummy-hcd doesn't use HCD_BH, so this shouldn't be > a factor here, but it could become an issue on real hardware. Do you think it would help to provoke some exotic bugs if dummy-hcd did use HCD_BH? That would be an easy change to make. > As long as resubmission is prevented reliably, this won't affect > HCDs, but it may cause UAF in buggy class drivers. > > --- > > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > index b181b43a35dc..4fee30101e96 100644 > --- a/drivers/usb/core/hcd.c > +++ b/drivers/usb/core/hcd.c > @@ -1958,6 +1958,15 @@ int usb_hcd_alloc_bandwidth(struct usb_device *udev, > return ret; > } > > +void usb_hcd_set_endpoint_enabled(struct usb_host_endpoint *ep, int enabled) > +{ > + unsigned long flags; > + > + spin_lock_irqsave(&hcd_urb_list_lock, flags); > + ep->enabled = enabled; > + spin_unlock_irqrestore(&hcd_urb_list_lock, flags); > +} > + > /* Disables the endpoint: synchronizes with the hcd to make sure all > * endpoint state is gone from hardware. usb_hcd_flush_endpoint() must > * have been called previously. Use for set_configuration, set_interface, > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c > index 75e2bfd744a9..8d656d7e8f69 100644 > --- a/drivers/usb/core/message.c > +++ b/drivers/usb/core/message.c > @@ -1358,7 +1358,7 @@ void usb_disable_endpoint(struct usb_device *dev, unsigned int epaddr, > dev->ep_in[epnum] = NULL; > } > if (ep) { > - ep->enabled = 0; > + usb_hcd_set_endpoint_enabled(ep, 0); > usb_hcd_flush_endpoint(dev, ep); > if (reset_hardware) > usb_hcd_disable_endpoint(dev, ep); > @@ -1523,7 +1523,7 @@ void usb_enable_endpoint(struct usb_device *dev, struct usb_host_endpoint *ep, > dev->ep_out[epnum] = ep; > if (!is_out || is_control) > dev->ep_in[epnum] = ep; > - ep->enabled = 1; > + usb_hcd_set_endpoint_enabled(ep, 1); > } For debugging purposes you might also add a dev_warn() to usb_hcd_link_urb_to_ep() in the test for !urb->ep->enabled. We can't do this all the time because a driver might unknowingly submit an URB just as the endpoint is being disabled. Alan Stern