commit 1cf719e9c6bf75b246c8c00b4dc93ac9dd504df9
from: Omar Polo <op@omarpolo.com>
date: Sun Jan 02 15:09:05 2022 UTC

reply with an Rerror if Rread/Rstat would overflow msize

Other replies have either a fixed reply size or a (relatively small)
maximum reply size.  Rread and Rstat on the other hand are easy to abuse
and generate replies longer that msize.

I don't care if a client manage to negotiate a ridiculy small msize
(maybe will add a minimum value in tversion in the future), but I feel
that Rread and Rstat need a small safety net.

commit - 001dad0e6901d683c4abfd226c939b5ba1e8f43b
commit + 1cf719e9c6bf75b246c8c00b4dc93ac9dd504df9
blob - 8802f85f95e5518dd7736cf73df9e190da4c0e8b
blob + fe44bea30966734e0e1715e60e70f6496cb0d631
--- client.c
+++ client.c
@@ -679,6 +679,11 @@ np_create(uint16_t tag, struct qid *qid, uint32_t ioun
 static void
 np_read(uint16_t tag, uint32_t count, void *data)
 {
+	if (sizeof(count) + count + HEADERSIZE >= msize) {
+		np_error(tag, "Rread would overflow");
+		return;
+	}
+
 	np_header(sizeof(count) + count, Rread, tag);
 	np_write32(evb, count);
 	np_writebuf(evb, count, data);
@@ -696,6 +701,11 @@ np_write(uint16_t tag, uint32_t count)
 static void
 np_stat(uint16_t tag, uint32_t count, void *data)
 {
+	if (sizeof(count) + count + HEADERSIZE >= msize) {
+		np_error(tag, "Rstat would overflow");
+		return;
+	}
+
 	np_header(count, Rstat, tag);
 	np_writebuf(evb, count, data);
 	do_send();