From nobody Sun Dec 14 11:14:56 2025 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 DD6D528E0F for ; Fri, 31 Oct 2025 04:34:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761885292; cv=none; b=lIOlvANv3o/6Bw55Z8ymO1KsDwl+QXthn6MNvv+STS26ywZxGJZkWWE584pjtAOiItr4kcTjUN/+++0VYGqyvqO3XbnxFL9W4vWaUOpKP7eRLJL7b5KaTTXJNiMYxIss41g/Fvp+vEQd9W5V6VcI2XU6XipoHjLtdEjlBEt3Wh8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761885292; c=relaxed/simple; bh=eVnAfVRq2krsx7QKJdrfJqtPm5yDsk9NtGCxS32gXZg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ZzOTV02TYiUTYs654GExuOtk7g/8JTuw1hW+phkqoljnh0NgO1KXWmi6VpKwxxeObQNWsGXow8NgFb5jWprodoHZVA5J4KS5rmbZyp1RfaGspRlCsYheyY4yoAfIGjuPBf5EBSSxPOrIjB22no2mLgBIbZBV1wZCsr1owsiQG5U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ieP1p/fC; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ieP1p/fC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1761885289; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=HL1yyGOQ4hc+ORZk21QBPnBBz7dH47bfSZ5mCbTA1dU=; b=ieP1p/fCgUTbHQ0F1J+2C8s7IvVRfdcQJSGVkVqNR6I/T9l4iuouhFo2RTelvuKD9T80MB ZcWQE/oA0WrpVJEuUJaEstJzWuQGNZnqco1Aau4xQphztqhVNjE+6HJF/CZQ73yUb14E+V SNG5h919SNtEnXkfmcB81doru+PpwfY= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-684-XwdALYylPtqEA05ou3HP-Q-1; Fri, 31 Oct 2025 00:34:48 -0400 X-MC-Unique: XwdALYylPtqEA05ou3HP-Q-1 X-Mimecast-MFC-AGG-ID: XwdALYylPtqEA05ou3HP-Q_1761885286 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9BB7F1828AF3; Fri, 31 Oct 2025 04:34:46 +0000 (UTC) Received: from desnesn-thinkpadp16vgen1.rmtbr.csb (unknown [10.96.134.12]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 4013E30001A1; Fri, 31 Oct 2025 04:34:43 +0000 (UTC) From: Desnes Nunes To: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Cc: gregkh@linuxfoundation.org, stern@rowland.harvard.edu, Desnes Nunes , stable@vger.kernel.org Subject: [PATCH v3] usb: storage: Fix memory leak in USB bulk transport Date: Fri, 31 Oct 2025 01:34:36 -0300 Message-ID: <20251031043436.55929-1-desnesn@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 Content-Type: text/plain; charset="utf-8" A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages. Fixes: a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indire= ct()") Cc: stable@vger.kernel.org Signed-off-by: Desnes Nunes Reviewed-by: Alan Stern --- V2->V3: Changed memset to use sizeof(buf) and added a comment about the leak V1->V2: Used the same code style found on usb_stor_Bulk_transport() drivers/usb/storage/transport.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transpor= t.c index 1aa1bd26c81f..9a4bf86e7b6a 100644 --- a/drivers/usb/storage/transport.c +++ b/drivers/usb/storage/transport.c @@ -1200,7 +1200,23 @@ int usb_stor_Bulk_transport(struct scsi_cmnd *srb, s= truct us_data *us) US_BULK_CS_WRAP_LEN && bcs->Signature =3D=3D cpu_to_le32(US_BULK_CS_SIGN)) { + unsigned char buf[US_BULK_CS_WRAP_LEN]; + usb_stor_dbg(us, "Device skipped data phase\n"); + + /* + * Devices skipping data phase might leave CSW data in srb's + * transfer buffer. Zero it to prevent USB protocol leakage. + */ + sg =3D NULL; + offset =3D 0; + memset(buf, 0, sizeof(buf)); + if (usb_stor_access_xfer_buf(buf, + US_BULK_CS_WRAP_LEN, srb, &sg, + &offset, TO_XFER_BUF) !=3D + US_BULK_CS_WRAP_LEN) + usb_stor_dbg(us, "Failed to clear CSW data\n"); + scsi_set_resid(srb, transfer_length); goto skipped_data_phase; } --=20 2.51.0