From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D34D343D6A; Wed, 3 Dec 2025 15:57:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764777463; cv=none; b=jfbvrIkvNXRIetpKaVb2zVtM76XiI6Pcv9NIiuI+XJUGOK3DnPBQYI4z0UCEXC0tka53c8FsMMZ89Dk0wuGliZJ+vUiCoe7295Sqedc0jYN0R0EnlefT/Jr+eofzpk/zx1nP8kCowK5YVsclBPBzygM+xVu+l1Yj4fRduoFhpRo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764777463; c=relaxed/simple; bh=wQvoBlL/3F1JIObBwK5M1e7KNRXxScvEr5Se/OyCAYc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BInKjnC7iVTjSOU9kfMGD3bknJxfmlT/LED307/smWmofWNfQBGYQNVJnvorabVLn6mxP1OhKfE5j+cuom1l5pZ5AGJSuztz9DNZJPzzh5m9Rz1xF8NPkVnYfWUolYMbxyaAaEKvGUi2/ZBXLLQDKeFIw+Voc13kZVYXPQmALVI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ri9krvRo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ri9krvRo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23AB0C4CEF5; Wed, 3 Dec 2025 15:57:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1764777463; bh=wQvoBlL/3F1JIObBwK5M1e7KNRXxScvEr5Se/OyCAYc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ri9krvRoqSnlKWqAQqzE/Y03/pjASo3maC/9M+vkaF3bBtsYzc+TkGT/AQOdKrCLq m294vo+36p5hgbYemHv3Hbce6ORk0cAnHPBwGEiJaja4dao9Xlbs5xcz9j8PS+r59S gJlaOB7ex5CfWjtYzviREleceb1bQAen0tCVUIgI= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, stable , =?UTF-8?q?=C5=81ukasz=20Bartosik?= , Mathias Nyman , Sasha Levin Subject: [PATCH 5.15 045/392] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event Date: Wed, 3 Dec 2025 16:23:15 +0100 Message-ID: <20251203152415.767642699@linuxfoundation.org> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20251203152414.082328008@linuxfoundation.org> References: <20251203152414.082328008@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 5.15-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mathias Nyman [ Upstream commit f3d12ec847b945d5d65846c85f062d07d5e73164 ] DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for incoming data are queued, but driver handles the event after it queued the TRBs. This is possible as xHCI DbC hardware may trigger spurious STALL transfer events even if endpoint is empty. The STALL event contains a pointer to the stalled TRB, and "remaining" untransferred data length. As there are no TRBs queued yet the STALL event will just point to first TRB position of the empty ring, with '0' bytes remaining untransferred. DbC driver is polling for events, and may not handle the STALL event before /dev/ttyDBC0 is opened and incoming data TRBs are queued. The DbC event handler will now assume the first queued TRB (length 1024) has stalled with '0' bytes remaining untransferred, and copies the data This race situation can be practically mitigated by making sure the event handler handles all pending transfer events when DbC reaches configured state, and only then create dev/ttyDbC0, and start queueing transfers. The event handler can this way detect the STALL events on empty rings and discard them before any transfers are queued. This does in practice solve the issue, but still leaves a small possible gap for the race to trigger. We still need a way to distinguish spurious STALLs on empty rings with '0' bytes remaing, from actual STALL events with all bytes transmitted. Cc: stable Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/usb/host/xhci-dbgcap.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/usb/host/xhci-dbgcap.c +++ b/drivers/usb/host/xhci-dbgcap.c @@ -880,7 +880,8 @@ static enum evtreturn xhci_dbc_do_handle dev_info(dbc->dev, "DbC configured\n"); portsc = readl(&dbc->regs->portsc); writel(portsc, &dbc->regs->portsc); - return EVT_GSER; + ret = EVT_GSER; + break; } return EVT_DONE; @@ -940,7 +941,8 @@ static enum evtreturn xhci_dbc_do_handle break; case TRB_TYPE(TRB_TRANSFER): dbc_handle_xfer_event(dbc, evt); - ret = EVT_XFER_DONE; + if (ret != EVT_GSER) + ret = EVT_XFER_DONE; break; default: break;