From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (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 CB3AC3D88E3 for ; Fri, 12 Jun 2026 11:27:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781263674; cv=none; b=cu3UsPT4zgEYuZcZVp/vAqPQdBWKABBqJC/Yi7dQ31AT4FQDjxVWuvAXbZguckczpXW7HaDav7vjvSDflvqtayrcC3QgV7+mV70GfUIZVEJsrGj4vV/oXaRgibdTWdsPM2ywaiwUJrGxaqSokfRlmmDkst9pbGNsfwMAaqU/gpI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781263674; c=relaxed/simple; bh=YSPwyTnUHlbBU4nIknlCXyeL5oVNr1kmvcE0o8FztQI=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lgdSiPrsyfJ6TWaVJCuaVaFj5hE9LKXLHrniqvsEpufmVXg8Qswjk4nErquUCzC8GS7kd9dVOk59FLgT1uP1R8pccjn2e8mbYGWHFVXUgs3TO8ltJVsCazFqRc0pBjgTeGDzY+nCSMCeHYVxPPWSihG4GPeNRG4xYTe2FpBcWCA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MuHTP0tE; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MuHTP0tE" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-490aaeabdb4so5613515e9.1 for ; Fri, 12 Jun 2026 04:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781263665; x=1781868465; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=YSPwyTnUHlbBU4nIknlCXyeL5oVNr1kmvcE0o8FztQI=; b=MuHTP0tElwW16sIOPS5xyATAkfobvcLywVsJblZ918ywgjD/Za+3zSfiy8HnQPeaQg KK5LWP8EE2CcxhV05VV956WBc3/bwaXQofeZyvm5lNYNRJrvwY1K+TLoyLw7Y80zpYEY sViiPHT1tkirCaAkt1O6Ld9dfrufpESDoJdcgzH39GjSJvI8X4jnw+8wpVQCqb5lMOku vYKKwSVnmVLgpX7JH60rL+FFDjj2qe62HwtkszxaZmPovJEMpBOQfYcCObGAX2fGsLTh NY5+Rku6mqBoGCCGsptr4VFRfa76sMRmXEPDP0eNN7lYArmLZ0Dj0xyrNBllH58iDt2N qErw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781263665; x=1781868465; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=YSPwyTnUHlbBU4nIknlCXyeL5oVNr1kmvcE0o8FztQI=; b=GsWkvNQz2OkZFRIxtlMD9/XOGfmGRIvkjBuaEZKbAst2DyD29MlY+m1Xd/JlHl6noh 71C0EuHE4E14ZquBUfIsV+x+x5jPPOxYUzZDSH2EQDRjPkq8gVED1yPr7IRBL2Y/oU2Z Xq0bdCzjEO35VV26W9Sgnl9+Dx+vDLXKNTWp1NcJZAZxSE8WVBvsEUiAHkrYG03Z5YET JMvzoKDPw6WRIMVaRIJvzkMTeqmamyPM6ffXcK6GLpemqTIDHKEaHN+LJq5XAXDed0pI w/6kizyELZQNwd/+lrAIXDYY8KakPRk5mWx0g1bgjLT3fY6eFR7SzZQwcxpVwbm/pvA5 dW3A== X-Forwarded-Encrypted: i=1; AFNElJ8oCak4MJMPMhJs5nV9Sj6QNhNKpGAsweHHld5G74MYllVDwlgxmJ3st9vgg9+kYr4/u9Te5hZoIX/3uXo=@vger.kernel.org X-Gm-Message-State: AOJu0Yz7BJK8h18Tp30c6SYsRVvgZNIrh4hOC4mEMJ8Fma2OrJgMLQID KG7WT9E2xK8+hTtvtqWtwEhf67hJ4v362cJWEUxa3PfbHbW2LK04uF7q X-Gm-Gg: Acq92OGc5vTSOfhtNef/IhASbSdL6EYu2e7HQlMb+6buHRR4Ti/0sFG1Y139HfUrPUy J04hOQuUz4KHtytO2NV+XuBJrU09DeIm91PvZs3S1wi2Dce5Oubwvrst7G9Nckn6fIKkts/aFdO 9hFmkKR5X3Y8UCcmOylWKRnTRlHl01tuqJbv/auPSsP8DGJh302Veh12Onw+0iAAgcDcNESrjhX /PXdhcHK+rijtEXTz64Qvhr2nReQeJwBjGiPEL4P9CIfkBKeZBsyyZ0wI4aoJTthvjzuZu74lJS mSM1dnb3eb/4nk8ocKhag+PhmpNLd9Ui7AUw+PUaU/KlpM1w23o9/mGvZfShAK2i0C/vdCYSPJQ 5y686NfBg4ifaNS23rGA93J4LtuXR631++t/lREFMivnzUFa0rxcOT2hbpN7Qqb53qeQS9LGVEG 2ydoAMhwkV0+b4zWYXcEJJGIDHSZR7bUHx X-Received: by 2002:a05:600c:3105:b0:490:e60b:6860 with SMTP id 5b1f17b1804b1-490ec4b5a3cmr33426235e9.7.1781263664732; Fri, 12 Jun 2026 04:27:44 -0700 (PDT) Received: from foxbook (bey14.neoplus.adsl.tpnet.pl. [83.28.36.14]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4606f26434dsm5205124f8f.1.2026.06.12.04.27.43 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 12 Jun 2026 04:27:44 -0700 (PDT) Date: Fri, 12 Jun 2026 13:27:40 +0200 From: Michal Pecio To: Mathias Nyman Cc: =?UTF-8?B?6IOh6L+e5Yuk?= , Greg Kroah-Hartman , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Oliver Neukum , Alan Stern Subject: Freeing bulk streams concurretnly with URB execution Message-ID: <20260612132740.00afd726.michal.pecio@gmail.com> In-Reply-To: <10322326-6b5a-4f6e-8c8b-e915363137ee@linux.intel.com> References: <20260611094526.2f5ddbba.michal.pecio@gmail.com> <10322326-6b5a-4f6e-8c8b-e915363137ee@linux.intel.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=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 11 Jun 2026 20:53:40 +0300, Mathias Nyman wrote: > On 6/11/26 11:33, =E8=83=A1=E8=BF=9E=E5=8B=A4 wrote: > > If we free stream_info first (outside the lock), then acquire the > > lock to clear the pointer, there is a window where the interrupt > > handler can still see the old (dangling) pointer and dereference > > freed memory. So we need to clear the reference under the lock > > first, then free the memory outside. >=20 > Good point, but the need for this reveals another bug. >=20 > This means xhci_free_streams() can queue a configure endpoint command > to remove streams, and xhci_irq() can ring the doorbell of a stream > at the same time xHC controller is processing the command to remove > the stream Yes, nothing seems to prevent that if there are URBs on the endpoint. Without URBs the doorbell won't be rung, though UAF would still occur with my proposal in absence of improved guards against it. 8df75f42f8e6 added the GETTING_(NO)_STREAMS flags to block new URBs on transitioning endpoints and prevented enabling streams if URBs are already pending, but not disabling streams. So question is, can usbcore / uas actually try to disable streams with pending URBs, or submit new URBs concurrently? If so then we probably need to fail the attempt or flush the URBs, and I suspect that storage (Cc) may not like the former option. Otherwise, the URBs not only get in the way of cleaning things up, but it's not even clear how they would complete. The HW won't execute them anymore, probably someone will have to unlink, relying on the hack for removing URBs from nonexistent rings and logging a dev_err(). On the upside, the above suggests that it's not a common occurrence if nobody complained in 15 years... > So I think this is a good targeted patch for this specific issue. > We should start fixing the other issues and hopefully end up where > Michal suggested. Indeed, I see no way to simplify this patch without much work. Regards, Michal