A good 9p client sends T_readdir with "count" parameter that's sufficiently
smaller than client's initially negotiated msize (maximum message size).
We perform a check for that though to avoid the server to be interrupted
with a "Failed to encode VirtFS reply type 41" transport error message by
bad clients. This count value constraint uses msize - 11, because 11 is the
header size of R_readdir.
Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <
3990d3891e8ae2074709b56449e96ab4b4b93b7d.
1579567020.git.qemu_oss@crudebyte.com>
[groug: added comment ]
Signed-off-by: Greg Kurz <groug@kaod.org>
int32_t count;
uint32_t max_count;
V9fsPDU *pdu = opaque;
+ V9fsState *s = pdu->s;
retval = pdu_unmarshal(pdu, offset, "dqd", &fid,
&initial_offset, &max_count);
}
trace_v9fs_readdir(pdu->tag, pdu->id, fid, initial_offset, max_count);
+ /* Enough space for a R_readdir header: size[4] Rreaddir tag[2] count[4] */
+ if (max_count > s->msize - 11) {
+ max_count = s->msize - 11;
+ warn_report_once(
+ "9p: bad client: T_readdir with count > msize - 11"
+ );
+ }
+
fidp = get_fid(pdu, fid);
if (fidp == NULL) {
retval = -EINVAL;