As reported by Felix Wilhelm, at various places in 9pfs, full paths are created by concatenating a guest originated string to the export path. A malicious guest could forge a relative path and access files outside the export path.
A tentative fix was sent recently by Prasad J Pandit, but it was only focused on the local backend and did not get a positive review. This series tries to address the issue more globally, based on the official 9P spec. This v2 is actually a complete rework of my previous post, based on the feedback I had from Peter Maydell: http://patchwork.ozlabs.org/patch/662324/ Note that xattrwalk and xattrcreate are no longer part of the pictures since they are being passed attribute names, not file names actually. The official linux client only sends 1 path component at a time, without any / nor NULs nor "." nor ".." and we don't have a functional qtest yet for 9P, so I had to do limited manual testing using GDB to hack strings coming from a linux client. It is no longer possible to access files outside the export path if this series is applied. I could also run the POSIX file system test suite from TUXERA: http://www.tuxera.com/community/open-source-posix/ and did not observe any regression with this patch (at least with the local backend and the none/passthrough/mapped security models). Patch 5/5 isn't related to the initial path traversal issue but I found it while working on empty strings, so I send it along anyway. --- Greg Kurz (5): 9p: forbid illegal path names 9p: disallow the NUL character in all strings 9p: forbid . and .. in file names 9p: handle walk of ".." in the root directory 9p: forbid empty extension string fsdev/9p-iov-marshal.c | 7 ++ hw/9pfs/9p.c | 168 +++++++++++++++++++++++++++++++++++++++++++++--- hw/9pfs/9p.h | 1 3 files changed, 164 insertions(+), 12 deletions(-) -- Greg
