The 'msize' parameter negotiated during Tversion handshake can be arbitrarily large as requested by the guest. So far 9p server accepted any msize value suggested by guest, i.e. server did not cap it at all, no matter how large, as in practice the upper limit of msize is a client capability. But as subsequent's security patch shows, capping msize on server side makes sense as additional safety-net.
Let's cap msize to transport's theoretical limit for msize, mainly to prevent a bad client from triggering excessive host memory allocations throughout the session. We intentionally don't cap msize to transport's current, real response buffer size, as the response buffer size may vary between individual requests. Signed-off-by: Christian Schoenebeck <[email protected]> --- hw/9pfs/9p.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c index e2713b9eee..2bb42dfc2e 100644 --- a/hw/9pfs/9p.c +++ b/hw/9pfs/9p.c @@ -1456,6 +1456,16 @@ static void coroutine_fn v9fs_version(void *opaque) goto out; } + /* cap msize to transport's theoretical limit */ + if (s->transport->msize_limit) { + size_t limit = s->transport->msize_limit(s); + if (s->msize > limit) { + s->msize = limit; + warn_report_once("9p: client msize capped to %zu (transport limit)", + limit); + } + } + /* 8192 is the default msize of Linux clients */ if (s->msize <= 8192 && !(s->ctx.export_flags & V9FS_NO_PERF_WARN)) { warn_report_once( -- 2.47.3
