)]}'
{
  "commit": "bb5ab96e35a1b13a2485d239a44ff2d040e9b337",
  "tree": "0de30f509d65177aa1356c692b46035d96ad7b60",
  "parents": [
    "815d1799c3d3d6cd058cb4634392ca5a34830450"
  ],
  "author": {
    "name": "Christian Schoenebeck",
    "email": "qemu_oss@crudebyte.com",
    "time": "Fri Jun 12 20:22:52 2026 +0200"
  },
  "committer": {
    "name": "Christian Schoenebeck",
    "email": "qemu_oss@crudebyte.com",
    "time": "Mon Jun 29 15:10:31 2026 +0200"
  },
  "message": "hw/9pfs: cap negotiated msize to transport limit\n\nThe \u0027msize\u0027 parameter negotiated during Tversion handshake can be\narbitrarily large as requested by the guest. So far 9p server accepted\nany msize value suggested by guest, i.e. server did not cap it at all,\nno matter how large, as in practice the upper limit of msize is a client\ncapability. But as subsequent\u0027s security patch shows, capping msize on\nserver side makes sense as additional safety-net.\n\nLet\u0027s cap msize to transport\u0027s theoretical limit for msize, mainly to\nprevent a bad client from triggering excessive host memory allocations\nthroughout the session.\n\nWe intentionally don\u0027t cap msize to transport\u0027s current, real response\nbuffer size, as the response buffer size may vary between individual\nrequests.\n\nLink: https://lore.kernel.org/qemu-devel/2105e9a3578c6f751bb64af55c16dd953f393f20.1781287774.git.qemu_oss@crudebyte.com\nSigned-off-by: Christian Schoenebeck \u003cqemu_oss@crudebyte.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "b486cce48a29f7cedc4dc1eb1caede33914310aa",
      "old_mode": 33188,
      "old_path": "hw/9pfs/9p.c",
      "new_id": "81d9bb8c6d4b622690f110cf8948e4ab0c204739",
      "new_mode": 33188,
      "new_path": "hw/9pfs/9p.c"
    }
  ]
}