On Wed, Jul 15, 2026 at 06:10:00PM +0200, 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]>
> ---
> hw/9pfs/9p.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Daniel P. Berrangé <[email protected]>
Once a CVE is assigned to this in the gitlab issue, just include
that CVE ID in the commit message when doing a pull request.
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
