Description

A flaw was found in the MTP backend in gvfs. When reading a file from a mounted MTP device, do_read() in gvfsbackendmtp.c trusts the data length returned by the device without limiting it to the original size requested by the client. If a malicious MTP device responds with more bytes than requested, this unrestricted length is passed directly to memcpy(). This causes the operation to read memory outside the intended boundaries. This allows an attacker who plugs in a malicious MTP device to cause a segmentation fault when a file is read and crash the gvfsd-mtp process, resulting in a denial of service.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-01T16:17:37.817Z",
  "pubdate": "2026-09-01T16:17:37.817Z",
  "executiveSummary": "A critical memory safety vulnerability exists in the MTP backend of gvfs, specifically within gvfsbackendmtp.c.\nThe flaw manifests as an improper validation of data length received from external hardware, leading to a heap-based buffer overflow.\nAn attacker with physical access can exploit this by connecting a malicious MTP device to a target system.\nUpon a file read request, the device provides an arbitrary data length that exceeds the client's buffer constraints.\nThis unrestricted input is passed to memcpy(), resulting in out-of-bounds memory access.\nSuccessful exploitation leads to a segmentation fault and a denial of service (DoS) of the gvfsd-mtp process.\nThe vulnerability requires local physical access to the machine, making it a targeted attack vector against desktop users or systems utilizing MTP mounts.\nThe primary risk is service instability and process termination rather than remote code execution, though memory corruption vulnerabilities often carry elevated risks depending on process heap layout.",
  "technicalDetails": "The root cause of this vulnerability lies in an insecure implementation of the do_read() function within gvfsbackendmtp.c. When the gvfs daemon interacts with an MTP device to retrieve file contents, it issues a read request to the hardware. The backend implementation fails to enforce strict bounds checking on the volume of data returned by the device compared to the actual size requested by the client application.\nThe attack flow commences when a malicious MTP device is connected to the host system via USB. The attacker prepares the device firmware to respond to standard MTP read requests with an oversized payload. When a user or system process attempts to read a file from the mounted device, the gvfs backend invokes do_read().\nThe vulnerable code section receives the response from the MTP device and trusts the length metadata provided by the device without performing a sanity check against the buffer allocated for the read operation. This unchecked length value is subsequently passed as the size parameter to the standard C library memcpy() function. Because the input size is attacker-controlled and exceeds the destination buffer size, the memcpy() operation writes beyond the boundaries of the intended heap-allocated memory.\nThis out-of-bounds write corrupts adjacent heap metadata or process memory structures. The immediate impact of this corruption is a segmentation fault, which triggers the termination of the gvfsd-mtp daemon. Consequently, the user experience is impacted by the abrupt disconnection of the MTP device and the cessation of file system services managed by the gvfs backend.\nThe vulnerability does not require authentication or elevated privileges beyond the ability to physically interface with the USB controller and interact with the gvfs daemon. The attack is locally exposed to the physical bus and does not rely on network connectivity, making it a hardware-to-software supply chain risk. While the current impact is defined as a denial of service, memory corruption vulnerabilities involving memcpy() are high-priority security concerns due to the potential for further exploitation of the process heap if the memory layout can be reliably manipulated by the attacker."
}