Re: [PATCH 06/10] ipc: Don't allocate a copy larger than max

From: Peter Hurley
Date: Sun May 26 2013 - 06:25:12 EST


On 05/25/2013 08:04 AM, Manfred Spraul wrote:
Hi Peter,

You wrote:
When MSG_COPY is set, a duplicate message must be allocated for
the copy before locking the queue. However, the copy could
not be larger than was sent which is limited to msg_ctlmax.

Signed-off-by: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
---
ipc/msg.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ipc/msg.c b/ipc/msg.c
index 950572f..31cd1bf 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -820,15 +820,17 @@ long do_msgrcv(int msqid, void __user *buf, size_t bufsz, long msgtyp,
struct msg_msg *copy = NULL;
unsigned long copy_number = 0;
+ ns = current->nsproxy->ipc_ns;
+
if (msqid < 0 || (long) bufsz < 0)
return -EINVAL;
if (msgflg & MSG_COPY) {
- copy = prepare_copy(buf, bufsz, msgflg, &msgtyp, &copy_number);
+ copy = prepare_copy(buf, min_t(size_t, bufsz, ns->msg_ctlmax),
+ msgflg, &msgtyp, &copy_number);

What about:
- increase msg_ctlmax
- send message
- reduce msg_ctlmax

The side effects of the patch are odd:
- without MSG_COPY, a message can be read regardsless of the size.
The user could check for E2BIG and increase the buffer size until
msgrcv succeeds.

The patch does not change the behavior of non-MSG_COPY msg receive.

- with MSG_COPY, something else would happen.
As far as I can see, it would oops: msg_ctlmax bytes are allocated,
then the E2BIG test is against bufsz, and copy_msg() doesn't check
the size of the target buffer.

I assume you are using 3.9

Current mainline returns EINVAL.

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/