@samitouri / QOSamiQemu / commits / bb5ab96e35

hw/9pfs: cap negotiated msize to transport limit

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. Link: https://lore.kernel.org/qemu-devel/2105e9a3578c6f751bb64af55c16dd953f393f20.1781287774.git.qemu_oss@crudebyte.com Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>

Christian Schoenebeck committed Jun 12, 2026 at 20:22 UTC bb5ab96e35a1b13a2485d239a44ff2d040e9b337

1 file changed +10

hw/9pfs/9p.c

+10

@@ -1469,6 +1469,16 @@ static void coroutine_fn v9fs_version(void *opaque)

1469 goto out;

1470 }

1471

1472 + /* cap msize to transport's theoretical limit */

1473 + if (s->transport->msize_limit) {

1474 + size_t limit = s->transport->msize_limit(s);

1475 + if (s->msize > limit) {

1476 + s->msize = limit;

1477 + warn_report_once("9p: client msize capped to %zu (transport limit)",

1478 + limit);

1479 + }

1480 + }

1481 +

1482 /* 8192 is the default msize of Linux clients */

1483 if (s->msize <= 8192 && !(s->ctx.export_flags & V9FS_NO_PERF_WARN)) {

1484 warn_report_once(