From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 8F0FD2E06E4 for ; Sat, 12 Sep 2026 12:18:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789215528; cv=none; b=Vw7pDRwPkSU/QkwCIMhdo5eNSeLvNHrnX6xhvKi4JhI2PtbaCUs70gjJpfeNbwc0GjKlno4vJei091KxgiwyX9xtZ0bQaVxKj+SWKFWdlGssFxy2mNmQ6mm2/q92XQaiIXcNAabMUI4LZb9Zst+Ppx9aMWjTwTGSWKpwFR32+eI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789215528; c=relaxed/simple; bh=Pv5lp5bjPwTmiUKO+bVv28cfhOyswqn39WXIT7cCr3g=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=arFHvFkLQsVMmyZa2sLFiCy2e8vzaYBbiCfRrZF4MasfqPPAmW8TDnfhsLyV7h7koVa3QQ/ox8dJK8Y3CcTQhzs9wu9jvdukLCyL0OwNsVpGdvZ/rmN2TeZPkWUEAfjnZUarmv2CSk07OSLwTfvUPNhZhL2kfnxA/vnCuZhG8ww= 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=HUWkNyLG; arc=none smtp.client-ip=209.85.128.50 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="HUWkNyLG" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49d05d51553so16054985e9.2 for ; Sat, 12 Sep 2026 05:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789215525; x=1789820325; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=i/QUVEZsFPTwUSjXiHHedV10C9hU7WJ0OJfvcfgCPKk=; b=HUWkNyLGtXwrpVc19LMzb7jlzpGxhbql8qq5pmN0IowO0JmoMH8k24/qcIhq5kxYmt Yh+h+cwF9yQFXS0X5UYiANK+hZoFuHoEOPJDorB/NCn91Wp6g6J2bNqIRsSItrlhYyqn R06eOtYSX0T2colNgLdaQ1VDIabSRgP4MmiW8xndncMTu8YxA1VuhewxWpUJNaYRJNW4 kea93P+P2yT6DRPk6EytGYpuUI98Hf7jH9HPCbtcuXBHvbVQI8ZIIe0IkoszmEDkyi1y YXDQYj1l3rnzyFQpeeJZJih5Ohl7CdeKlgKhDvOcT4ry21CP/PaJjPXnPuNuqc47FuHI fa1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789215525; x=1789820325; h=content-transfer-encoding:content-type: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 :content-type; bh=i/QUVEZsFPTwUSjXiHHedV10C9hU7WJ0OJfvcfgCPKk=; b=XDn/RpMqWeClaiUSErBcsPErb0zBffHUAXqeT3sMb0m52xvm180l3LTSqlgri9NKkJ 1J0csk46tkOHdTlKPQBdX1jSAw7/MLalHhX212IzFeQIvUeuFRnkv47HyHYobZIKTHQc Du3EG2rG1jyKVO6sA+l2JqulHbr9x/evqx5VzRsV2YxX5KfB1VMkXNgINFyqDmsbpCxu G/3l1lMTkvaMPSyuiI5TQgyIrvK/STz/WfAj5ndcAFZCh2mi016ifNIEtdgIvXRXZc6H CeU5sx6x3ziMmmopfTpJNeVXnT1eqXZWBTLFD73V1BBjdcFle/Rk+4F2QU74ujwbrSmS n1cw== X-Forwarded-Encrypted: i=1; AKwUvBynuuv0uk2TqjksoWfxkRC/E2SGsAnw4omHgI7FLrgPXocUyHT4KAE6oh1kGw8mhE7Td3kSQJ5V18w=@vger.kernel.org X-Gm-Message-State: AFuF++moIwcjoUqhO0/C+ThXgGM7nVkVFGMB9YvQ2Glu+3K3AUqEg4M2 3AMdkMqHvii08UN1sqlmk+wzsrEym4kOm+gwJVCBZitAmuSqwBSpl9Uc X-Gm-Gg: AYBFou1iHza70frmJFLdLH+zFL3V8OsbFmHKIF/XV+9YJFqv3DLaoh0ZngESTWMx+uC WH3XAz5NFUcgPSfNEWLY4s+rMz+5UpTFafo8MclMqhEKpW4NbNH8YqqQov2F91OdPSsbjH67oGk Of3fjaAP0GSWWeFfVkAaD8dNHZ3vVlIKy+qTsSxtj06xhdff+een29iG4FVmOLGabBGnaK277Ft 5vZonIvKbXTa25TfrFMUXJldco5NT8GuQPUeHTvhIuzyKUogH4HpOdeB+tnQufHFbyDKFmenmWn 1koPKgyT7kY1G27DIXVfkHRNidVSBKtFqRVHm8XpmswWIs8QtDRKSSbKaEUt8jFux602HdQiMSl vMc49H3FM0KQyCMHZp6mT2XhnOg2CclxjOyIzTojFv6+zkCswuD8ffRT6iyEFcCnxtq14RLYO7e cwBd92png/XPFhGkaB6k0I3bSquCQF8d68wVD2I5Bc8ft87PZLuxP9quIwmX+n6dWz341ZgHlYR 3qrQnbz X-Received: by 2002:a05:600c:4f08:b0:49e:6c47:1433 with SMTP id 5b1f17b1804b1-49e6c471517mr27716965e9.33.1789215524691; Sat, 12 Sep 2026 05:18:44 -0700 (PDT) Received: from foxbook (bfg95.neoplus.adsl.tpnet.pl. [83.28.44.95]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e6af095d7sm64047675e9.0.2026.09.12.05.18.43 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sat, 12 Sep 2026 05:18:44 -0700 (PDT) Date: Sat, 12 Sep 2026 14:18:37 +0200 From: Michal Pecio To: Mathias Nyman Cc: Selvarasu Ganesan , =?UTF-8?B?6IOh6L+e5Yuk?= , Mathias Nyman , Greg Kroah-Hartman , "quic_wcheng@quicinc.com" , "broonie@kernel.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "cpgs@samsung.com" , "alim.akhtar@samsung.com" , "thiagu.r@samsung.com" Subject: Re: [PATCH] xhci: sideband: check vdev liveness before removing endpoints on unregister Message-ID: <20260912141837.06b2f3cf.michal.pecio@gmail.com> In-Reply-To: <191ee5d5-d93d-4fa3-9654-b3735d344118@linux.intel.com> References: <360067785.01789039502721.JavaMail.epsvc@epcpadp1new> <750468423.101789103583573.JavaMail.epsvc@epcpadp2new> <937773018.41789116303608.JavaMail.epsvc@epcpadp1new> <191ee5d5-d93d-4fa3-9654-b3735d344118@linux.intel.com> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 11 Sep 2026 16:10:04 +0300, Mathias Nyman wrote: > Good point, endpoint use after free is a much bigger and earlier > issue here. > > The endpoint rings that audio driver is accessing via sideband are > freed and reallocated much earlier. Audio driver is unaware of this > reset, and may still try to access the freed ring buffers. > This is an issue long before xhci_sideband_unregister() is called. > > usb_reset_and_verify_device() > hub_port_init() // resets port > usb_hcd_alloc_bandwidth(udev, udev->actconfig, NULL, NULL); > hcd->driver->drop_endpoint() // for all endpoints, xhci tags ep to be dropped > hcd->driver->add_endpoint() // for active endpoints. xhci allocs new ring for ep > hcd->driver->check_bandwidth(hcd, udev) // xhci frees old ring and takes new ring into use > > So turns out setting vdev->sideband->vdev to NULL in > xhci_free_virt_dev(), and reacting to it in > xhci_sideband_unregister() is too little too late. To be exact, such reset of current configuration only happens after successful hub_port_init(), which requires successful hub_port_reset(), which at least attempts to call hcd->driver->reset_device(), which is xhci_discover_or_reset_device(). This already deallocates transfer rings and includes a callback to sideband client to synchronize. Current implementation in QC seems to command the HW to stop using affected endpoint(s), so the most obvious and blatant kind of UAF is meant not to happen. Maybe this could be extended to unregister the sideband right there, but not sure what happens if hub_port_init() fails without us knowing. > I think wee need to look at using drv->pre_reset and drv->post_reset > to unregister and re-register sideband, or optionally to unbind and > rebind the whole interface. That's another opportunity to get rid of sideband users. It doesn't cover usb_reset_and_verify_device() called in reset-resume, but clients should usb_offload_get() to prevent suspend. It doesn't cover hub_port_reset() called by port_event() for SuperSpeed devices, not sure what that is and whether it's dangerous. I noted that the original patch talks about hub_event(), but maybe it's a mistake? Regards, Michal