[Bug 2167772] Re: vboxsf: endless write loop and data corruption on short copy

I verified this bug and reviewed the patch submitted to linux-fsdevel by Kentaro Shiomi. The root cause is clear: in fs/vboxsf/file.c, vboxsf_write_end() initialises 'nwritten = len' instead of 'copied'. When writing from un- faulted pages (like direct mmap or shared memory used by virtiofsd), copy_page_from_iter_atomic() copies 0 bytes. Because vboxsf_write_end() reports status = len back to VFS, generic_perform_write() thinks the data was written, never calls fault_in_iov_iter_readable(), and enters an endless loop filling the file with zeroes. I tested the patch logic against the Ubuntu kernel trees: 1. Resolute (7.0 / master): Uses the folio write_end signature. 2. Noble 24.04 LTS (6.8): Uses the page write_end signature. 3. Jammy 22.04 LTS (5.15): Same page write_end signature. The patch applies and builds cleanly with zero warnings. I updated the bug description above with the formal SRU justification and a minimal Python reproducer to help the kernel team track this for the next SRU cycle. I am also attaching the DEP-3 formatted patches for both Resolute and Noble. ** Patch added: "DEP-3 patch for Ubuntu 26.04 Resolute (Linux 7.0 / folio write_end)" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167772/+attachment/6001322/+files/lp2167772_vboxsf_resolute_7.0.patch -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2167772 Title: vboxsf: endless write loop and data corruption on short copy Status in linux package in Ubuntu: Confirmed Bug description: SRU Justification: [ Impact ] In the in-kernel VirtualBox shared folder driver (fs/vboxsf), writing to a file from memory pages that have not been faulted into the process page table causes the write path to enter an infinite loop. The destination file continuously grows with zeroes until the filesystem runs out of space, the writing process hangs permanently in kernel space (can only be killed with SIGKILL), and the kernel log is flooded with: WARNING: lib/iov_iter.c:624 at iov_iter_revert+0x1fc/0x270 Furthermore, if the target page/folio is already marked uptodate in the page cache, un-copied ranges are not zeroed, which causes vboxsf to write stale page cache contents to the host, resulting in silent data corruption. This condition is reliably triggered by applications that write directly from an mmap of another file or from shared memory without touching the pages first. For example, virtiofsd (used in nested virtualisation workloads, container runtimes, and developer sandboxes) operates in this manner and triggers the failure immediately. [ Fix ] In fs/vboxsf/file.c:vboxsf_write_end(), the driver previously initialised its byte counter with the requested length rather than the actually copied bytes: u32 nwritten = len; When a short copy occurs (copied < len, or copied == 0 due to an un- faulted page), the driver incorrectly wrote 'len' bytes to the host and returned 'len' to the VFS write loop. As a result, generic_perform_write() never invoked fault_in_iov_iter_readable(), advanced the file position by 'len' without advancing the user iterator, and looped endlessly. The fix applies two changes: 1. Initialise nwritten with the actually copied byte count: u32 nwritten = copied; 2. If nothing was copied (copied == 0), immediately exit via 'goto out' without calling vboxsf_write(), returning 0 to VFS. This allows generic_perform_write() to fall back to faulting in the source pages and retrying cleanly. [ Test Plan ] A minimal test using Python writes from an un-faulted mmap buffer into a vboxsf mount: 1. Mount a VirtualBox shared folder: sudo mount -t vboxsf shared_folder /mnt/shared 2. Run the reproducer: python3 -c ' import mmap, os with open("/tmp/src.bin", "wb") as f: f.write(b"A" * 65536) with open("/tmp/src.bin", "rb") as f: mm = mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) with open("/mnt/shared/test.bin", "wb") as out: out.write(mm[:4096]) print("Written:", os.path.getsize("/mnt/shared/test.bin")) ' Verification criteria: - Unpatched kernel: The process hangs indefinitely. The file /mnt/shared/test.bin expands rapidly with zeroes until disk space is exhausted. dmesg shows repeated "WARNING: lib/iov_iter.c:624 at iov_iter_revert". - Patched kernel: The process finishes immediately with exit code 0. /mnt/shared/test.bin has exactly 4096 bytes containing the character 'A'. dmesg reports 0 warnings. [ Where problems could occur ] The change is strictly isolated to the write_end handler in fs/vboxsf/file.c. In the standard case where copied == len, behavior is completely identical. In the case where copied < len or copied == 0, the driver now accurately conforms to the VFS address_space_operations contract by reporting actual progress instead of fabricating a successful write. Potential regression risk is very low. If any side effects were to occur, they would be strictly confined to writes on vboxsf mount points and would not impact other filesystems or core kernel memory management. [ Other Info ] The patch was submitted upstream to linux-fsdevel and the vboxsf maintainer on 2026-09-19. The underlying logic defect (u32 nwritten = len) has existed since vboxsf was merged in kernel 5.6. Consequently, this fix is required across all supported Ubuntu LTS releases: - Resolute (7.0 kernel, folio-based) - Noble (6.8 kernel, page-based) - Jammy (5.15 kernel, page-based) Clean patches for both the modern folio interface and stable page interface have been prepared and verified against Ubuntu kernel trees. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2167772/+subscriptions