On Wednesday, 15 July 2026 18:10:00 CEST Christian Schoenebeck wrote:
> Guest 9p client opening a file with O_TRUNC on a read-only 9p file
> system using 9p2000.u protocol version, allowed to bypass 9p
> server's read-only check, eventually causing file(s) being
> truncated to empty file(s) on host's read-only export.
>
> Root cause is that 9p server's read-only check is using Linux open
> flags like O_WRONLY, O_RDWR, O_TRUNC, but checking them against
> the 9p Topen request's "mode" parameter, which has a different
> encoding (Otrunc = 0x10 vs. O_TRUNC = 0x200).
>
> Fix this by checking against the "flags" variable instead of the
> protocol's "mode" option. Because the "flags" variable is already
> converted to Linux encoding by omode_to_uflags() for 9p2000.u and
> by get_dotl_openflags() for 9p2000.L protocol version.
>
> Only 9p2000.u was affected by this bypass, 9p2000.L uses the Linux
> format on protocol level already.
>
> Fixes: 2c74c2cb4b ("hw/9pfs: Read-only support for 9p export")
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/4000
> Signed-off-by: Christian Schoenebeck <[email protected]>
> ---
Queued on 9p.next:
https://github.com/cschoenebeck/qemu/commits/9p.next
Thanks!
/Christian
