* On 8/15/25 20:09, Jakub Kicinski wrote:
If this is a fix it has to go to net, then once it reaches Linus's tree
the dependent patches should be reposted for net-next.
Thanks.
Will split out the two commits and resend the resend of the series later on
after the fixes have been merged.
Might take me a few weeks, I'm currently very limited on time and internet access.
diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
index 3de9350cbf30..2bcfe539dc3e 100644
--- a/net/qrtr/ns.c
+++ b/net/qrtr/ns.c
@@ -619,6 +619,9 @@ static void qrtr_ns_worker(struct work_struct *work)
break;
}
+ if ((size_t)msglen < sizeof(*pkt))
+ break;
why not continue?
I don't really know and am not familiar with the QRTR protocol, but here's my
best guess:
Since we're using non-blocking I/O, it doesn't seem to make sense to continue,
because the next receive call would just break out anyway once it returns no
data at all. Notice that we're also breaking out for -EAGAIN.
Also, if we somehow got a short read, and we're currently dropping the buffer we
just read, any additional data after a subsequent receive would be garbage to us
anyway. We'd probably have to keep the old buffer content around and concatenate
it with data returned from a new receive call.
Mihai
