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 v3 takes various suggestions from Eric Blake into account (see each patch changelog). I only kept the patches that strictly relate to the reported path traversal issue. 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 and proxy backends and the none/passthrough/mapped security models). --- Greg Kurz (3): 9pfs: forbid illegal path names 9pfs: forbid . and .. in file names 9pfs: handle walk of ".." in the root directory hw/9pfs/9p.c | 152 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--- hw/9pfs/9p.h | 1 2 files changed, 144 insertions(+), 9 deletions(-) -- Greg
