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 43CB73C17; Fri, 31 Oct 2025 14:03:18 +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=1761919398; cv=none; b=LdwnMifl3Ox5tvTPBHE5PSaCLOE8H2kXcIf90aowcxKZydi/ckFGFcrRIEqoJrNZ38Ocs6n9lbtToDe6nENMeKMDJVNi9Xtd+R3k+H4lWYxy+WIs9kgtqd70XTkYZVhTD7AZN32EOsVKYUmbunJC0oc/xvFayNeItlGCVD8uDyM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761919398; c=relaxed/simple; bh=z6b43cpyVoKKvbBYBkun8LeuZ3dY/6MsxlWqcJf1dyY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VWRyUjjkKn3TXNiRZ3+2+I+HBhSXZFOBAha5c4zUvo8vk9rFJed2NZTU69aAfclgF1GS9/iLZJ65gNizKamCiwRsCxPME5zfV+Jgs9b6wT8rbMZ1npwTTeBuRbBdaoxm6nGK9AJkxacjRqdTruP6MMhUIHS535qtTWJyU4EHx+c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Gy1c/d9I; 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="Gy1c/d9I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0B36C4CEF8; Fri, 31 Oct 2025 14:03:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1761919398; bh=z6b43cpyVoKKvbBYBkun8LeuZ3dY/6MsxlWqcJf1dyY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Gy1c/d9IcToBSY3IDv4lveOdlELekD1nrrjaEECxjVbhDt+1UElmak3dmcNT2xoJu HdQ8ks8vYyXMPkpMgUbhkZd3+BMcGhhfXnKXwbbXQ+EUX7KEADBKNvyvmIn/mFjHvx MDEZxBwXjaMY18mAr4FPRXEqEB6LJ1UPF7ljDnqk= 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 6.6 27/32] xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event Date: Fri, 31 Oct 2025 15:01:21 +0100 Message-ID: <20251031140043.104912167@linuxfoundation.org> X-Mailer: git-send-email 2.51.2 In-Reply-To: <20251031140042.387255981@linuxfoundation.org> References: <20251031140042.387255981@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 6.6-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;