CVE-2025-68288: Linux USB storage CSW leak fixed in sg buffers

A newly cataloged Linux kernel vulnerability, tracked as CVE-2025-68288, exposes a subtle but material memory-leak condition in the USB mass-storage transport path that can allow USB protocol bytes to leak from kernel memory into user space via the SCSI Generic (/dev/sg*) interface. The flaw was identified by automated testing from the Linux Test Project (the ioctl_sg01 test) and fixed with a small but targeted patch that zeros out Command Status Wrapper (CSW) data left in scatter-gather transfer buffers after devices incorrectly skip the data phase.

Background​

Kernel USB storage drivers implement the SCSI-over-USB transport used by the mass-storage class. That transport relies on a tight choreography of data and status phases: the host sends commands and may expect bulk data before the final Command Status Wrapper (CSW) is returned by the device. Under some unusual device behaviors — notably when a device skips the data phase and replies with status information in a way the driver must parse — the kernel code was extracting and validating the CSW from an already-allocated scatter-gather (sg) buffer but failing to scrub the CSW bytes afterward. The leftover protocol bytes could therefore remain in the srb transfer buffer that is ultimately exposed to user space via the SCSI generic interface. This leak is distinct from a prior, larger leak fixed in 2018 (CVE-2018-1000204) because it does not stem from uninitialized allocation at allocation time; instead, it arises after allocation when protocol bytes are written into previously-zeroed sg pages and not cleared again. In the observed test run, fragments of the USB Bulk CSW signature — the four ASCII bytes USBS (represented as 0x53 0x42 0x53 0x55 in little-endian) — were the fingerprint indicating the nature of the leak.

What exactly is leaking and how​

• The leaking data is USB protocol framing/status bytes that belong to the Command Status Wrapper (CSW), not arbitrary kernel memory.
• These bytes can appear in the srb (SCSI Request Block) transfer buffer that is mapped to sg pages and later observed by user-space tools through the SCSI generic (/dev/sg*) interface.
• The offending window occurs when a device incorrectly skips the expected data phase and instead returns status information; the driver extracts and validates the CSW, but fails to overwrite those bytes in the sg buffer. The result: protocol-level bytes may surface to a user process that reads the sg buffer.

This is primarily an information disclosure issue rather than a remote code-execution vulnerability. An attacker or a local process that can issue specially-crafted SG_IO requests to a local SCSI generic device and read the resulting buffers could surface USB protocol bytes that ideally should have been scrubbed. The practical impact depends heavily on local privileges and on which processes are allowed to open and read /dev/sg* nodes on a given system.

How the bug was found and the scope of impact​

The bug was discovered during automated system testing: the ioctl_sg01 test from the Linux Test Project (LTP) produced reproducible artifacts that contained the US_BULK_CS_SIGN bytes. The test case involved a large SG_IO request (reported at 512 KiB in observed tooling) that provoked a device to skip the data phase and return status in an unexpected moment, which in turn left protocol bytes in the already-allocated sg pages. Severity and exploitability assessments across vendor trackers label this as a medium severity information-disclosure/availability concern, with CVSS assessments in some downstream advisories around the mid-range (e.g., 5.5 in one vendor advisory), reflecting low confidentiality impact but an availability or reliability risk where a leak could be abused to observe protocol behavior or confuse user-space tools. Note that CVSS and prioritization vary by vendor and downstream distribution.

Who is at risk​

• Systems that expose /dev/sg* nodes to untrusted user accounts are most exposed. On many distributions these character devices are restricted to privileged users, but udev rules and group assignments vary; operators should verify local device permissions and group membership policies.
• Any process with the ability to open SCSI generic nodes and issue SG_IO calls could trigger the condition under the right circumstances.
• The vulnerability is not a network-facing remote code execution; it is tightly bound to local I/O to USB mass-storage objects. The primary risk is local information leakage and potential confusion of diagnostic tooling or forensics data.

The fix: what changed in the kernel​

The patch series — authored and submitted by kernel developer Desnes Nunes — addresses the leak directly in the USB storage transport code path (drivers/usb/storage/transport.c). The change is deliberately small and surgical: after the driver extracts and validates the CSW from the sg buffer, it explicitly zeroes the CSW bytes in the srb transfer buffer so that no protocol framing remains visible to subsequent user-space reads. The patch went through multiple iterations (v1 → v2 → v3) to align code style and to replace a temporary buffer approach with a concise memset using sizeof(buf), along with a clarifying comment about the leak and a stable-backport tagging. Key technical points of the fix:

• It retains validation of the CSW bytes to preserve correct protocol semantics.
• Immediately after validation, the code uses a bounded memset to clear the CSW region inside the already allocated sg pages.
• The change avoids large allocation-time workarounds (such as always zeroing whole sg pages at allocation time) because the leak is about data written after allocation; the targeted clearing is less costly and avoids the performance/regression risk of globally changing allocation semantics.

Where and when the fix landed​

The patch set was submitted to the Linux kernel mailing lists in late October 2025 and propagated into the stable trees and downstream distributions in the weeks that followed. Kernel stable commit references and distribution advisories show the fix being incorporated into several stable kernels; Debian’s security tracker lists fixed package versions for specific releases (for example, bullseye received a fixed linux version 5.10.247-1, while some unstable/forky branches track later 6.x updates), and the NVD record includes references to stable git commits. Administrators should consult their distribution’s security tracker for exact package versions and backport status for their chosen kernel series.

• Example remediation commitments observed in public trackers:
• Debian: fixed in selected point releases for stable branches; fixed versions are listed per release in the tracker.
• Ubuntu: advisory published and priority set to medium; update guidance is included in the Ubuntu CVE page.
• Vendor trackers and third-party vulnerability databases (Tenable, Amazon Linux ALAS, Wiz) have recorded the CVE and published severity/contextual guidance and status for affected kernel packages.

Practical remediation steps for sysadmins and power users​

• Identify affected machines:
• Check kernel versions and distribution advisories: consult your distro’s security tracker for “CVE-2025-68288” and list of fixed package versions.
• Apply vendor-supplied updates:
• Upgrade to a kernel package that contains the transport.c fix. Where vendors have backported the patch to older stable kernels, install the vendor-provided update rather than attempting manual patching unless you manage a custom kernel tree.
• Where immediate kernel updates are not possible:
• Restrict access to /dev/sg* device nodes via udev or local policy so that only trusted administrators and required services can open SCSI generic nodes.
• Remove unneeded SCSI generic devices from systems that do not need raw access, or change group membership and permissions to limit access to trusted accounts.
• Test after patch:
• After applying kernel updates, re-run LTP tests (including ioctl_sg01) or equivalent sg3_utils tests to confirm that the leak no longer reproduces on your hardware and workload.
• Audit and monitoring:
• Review logs and auditing for unexpected SG_IO usage patterns. Consider adding monitoring for user-space processes issuing large or unusual SG_IO requests if this is a concern in your environment.

These steps emphasize vendor-provided updates as the first-line remedy; the code-level fix is minimal but part of the kernel binary, so installing the patched kernel package is the safest route.

Why this matters: trade-offs and broader context​

• Security vs. stability: The patch is intentionally minimal to reduce regression risk. It does not change allocation semantics across the SCSI or USB stacks, which would carry a larger maintenance burden and potential performance implications. By zeroing only the relevant CSW bytes at the point where protocol data was extracted, developers reduced the risk of unintended side effects while closing the leakage vector. This is a pragmatic engineering choice consistent with prior kernel maintenance practice.
• Locality of risk: Because exploitation requires local access to SCSI generic interfaces, threat models for servers and multi-user systems should prioritize this fix more highly than single-user, isolated desktops — provided that those desktops do not have untrusted local accounts. High-value multi-tenant hosts, build machines, forensic systems, or containers with host device access are higher priority. However, default device permissions vary by distribution and environment, so assumptions should be verified before deprioritizing remediation.
• Information vs. execution: This vulnerability is primarily an information-disclosure issue — leaking protocol bytes like the CSW signature does not in itself yield code execution. That said, information leaks can assist attack chains or expose diagnostic artifacts that leak device behavior, and they can complicate forensic analysis, so they are not trivial. Vendors have assigned medium priority in some trackers because of this nuance.

Developer and maintainer notes​

• The patch was authored and iterated on the kernel mailing lists; it includes “Fixes:” tags referencing the earlier allocation-time fix (to show provenance) and received review/comment from stable kernel maintainers. The change is small, contained, and designed for stable backporting. Anyone maintaining custom or embedded kernels should pull the appropriate stable commit rather than attempting to reimplement the change ad hoc.
• For kernel integrators: verify that your stable branch contains the transport.c change and run the LTP sg/ioctl test suite to detect regression or lingering cases. If you maintain certified or regulated systems, coordinate with your QA team for regression windows and follow your patch management lifecycle.

Limitations and unverifiable points (flagged)​

• Default permissions and access to /dev/sg vary widely by distribution, policy, and system configuration. While many distributions restrict these nodes to privileged groups (root or disk), some environments may expose them to broader groups via udev or custom configuration. System administrators must verify their own node permissions and access control policies to determine local risk. This statement is cautious because there is no single global standard for default /dev/sg permissions across distributions and versions.
• The real-world exploitation scenarios for this specific leak have not been documented publicly as active attacks. Public advisories characterize this as information disclosure with limited exploitability and no remote attack vector. That assessment could change if proof-of-concept code appears or if integration with other vulnerabilities amplifies risk; therefore, treating the bug as actionable (apply the patch) is the prudent course.

Recommended checklist for operations teams​

• Inventory: list hosts with SCSI generic devices or with USB mass-storage devices attached regularly.
• Patch: prioritize kernels for hosts with multi-user access, shared developer machines, or production attachable storage functions, and apply vendor-provided kernel updates that include the transport.c change.
• Harden: ensure /dev/sg* access is limited to trusted accounts; use udev rules or configuration management to enforce node permissions consistently.
• Test: re-run ioctl_sg01 or equivalent sg3-utils tests post-patch to validate remediation.
• Monitor: log and alert on unexpected SG_IO activity and set up periodic audits for device node permissions.

Conclusion​

CVE-2025-68288 is a clear example of how subtle protocol-handling edge cases can create information-leak vectors in kernel I/O stacks. The bug was found by automated testing, fixed with a narrowly-scoped patch that zeroes out CSW bytes after validation, and has been carried into stable trees and distribution updates. While the practical exploitation risk is bounded — local access to SCSI generic devices is required and this is not a remote code-execution issue — the fix is straightforward and should be applied as part of routine kernel maintenance on systems where /dev/sg* access is possible or where USB mass-storage devices are in use. Administrators should update kernels, tighten device-node access where possible, and re-run I/O test suites to validate fixes in their environment.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center