According to the 9P spec at http://man.cat-v.org/plan_9/5/intro :
Data items of larger or variable lengths are represented by a
two-byte field specifying a count, n, followed by n bytes of
data. Text strings are represented this way, with the text
itself stored as a UTF-8 encoded sequence of Unicode charac-
ters (see utf(6)). Text strings in 9P messages are not NUL-
terminated: n counts the bytes of UTF-8 data, which include
no final zero byte. The NUL character is illegal in all
text strings in 9P, and is therefore excluded from file
names, user names, and so on.
With this patch, if a 9P client sends a text string containing a NUL
character, the request will fail and the client is returned EINVAL.
The checking is done in v9fs_iov_vunmarshal() because it is a convenient
place to check all client originated strings.
Suggested-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Greg Kurz <gr...@kaod.org>
---
fsdev/9p-iov-marshal.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fsdev/9p-iov-marshal.c b/fsdev/9p-iov-marshal.c
index 663cad542900..9bcdc370231d 100644
--- a/fsdev/9p-iov-marshal.c
+++ b/fsdev/9p-iov-marshal.c
@@ -127,7 +127,12 @@ ssize_t v9fs_iov_vunmarshal(struct iovec *out_sg, int
out_num, size_t offset,
str->size);
if (copied > 0) {
str->data[str->size] = 0;
- } else {
+ /* 9P forbids NUL characters in all text strings */
+ if (strlen(str->data) != str->size) {
+ copied = -EINVAL;
+ }
+ }
+ if (copied <= 0) {
v9fs_string_free(str);
}
}
