gvfs EUVD-2026-69298

Physical access to the target machine is required to connect a malicious USB MTP device (AV:P). The user must actively read a file from the mounted MTP device after it is connected (UI:R) - simply plugging in the device without file access does not trigger the flaw. No system authentication or privileges on the target are required; the attack is driven entirely by the device's crafted MTP response. The gvfsd-mtp daemon must be running and MTP automounting must be enabled, which is the default on GNOME desktop installations. Exploitation is limited to crashing the gvfsd-mtp subprocess only; the user session, kernel, and other system daemons are unaffected. Remote or network-based triggering is not possible under this vulnerability.

The CVSS 3.1 base score of 4.3 reflects the genuine constraints of this vulnerability well: AV:P requires the attacker to physically connect a rogue device, AC:L acknowledges that crafting a non-compliant MTP response is straightforward once a device is built, and UI:R captures that a user must actively read a file from the device to trigger the bug. EPSS data was not provided, but physical-access-only CVEs consistently score in the lowest percentiles - this is not a remotely exploitable issue. There is no CISA KEV listing and no public proof-of-concept code. The blast radius is limited to the gvfsd-mtp subprocess; a crash does not affect the host system, kernel, or other daemons. Realistically, even a mid-sized municipal IT team in mielec managing RHEL desktop fleets would rightly deprioritize this behind any network-exploitable vulnerability in their environment. The 'Information Disclosure' tag in the input metadata is inconsistent with the CVSS C:N metric and the description, which documents DoS as the sole impact - this tag should be discarded when prioritizing.

An attacker builds or reprograms a USB device to respond to MTP file-read requests with a byte-count larger than the actual data, then connects the device to a target RHEL workstation. When a user opens the mounted device in a file manager and reads any file, gvfsd-mtp calls do_read(), receives the inflated length, passes it to memcpy(), triggers an out-of-bounds read, and the daemon segfaults - disrupting MTP device access until the daemon restarts. No public proof-of-concept exists, but building a non-compliant MTP firmware stub is within reach of a moderately skilled hardware attacker.