Skip to contentSkip to conversation

bogus MSG_PEEK test in rxrpc_recvmsg()

PATCH In review Al Viro 2 participants 2 messages Mar 14, 2015 – Mar 16, 2015

Subsystems (3)
lore
Share & tools
lore

Al Viro

author
#0 lore raw

PATCH 1/1 bogus MSG_PEEK test in rxrpc_recvmsg()

[I would really like an ACK on that one from dhowells; it appears to be quite straightforward, but...]

MSG_PEEK isn't passed to ->recvmsg() via msg->msg_flags; as the matter of fact, neither the kernel users of rxrpc, nor the syscalls ever set that bit in there. It gets passed via flags; in fact, another such check in the same function is done correctly - as flags & MSG_PEEK.

It had been that way (effectively disabled) for 8 years, though, so the patch needs beating up - that case had never been tested. If it is correct, it's -stable fodder.

---

net/rxrpc/ar-recvmsg.c +1 -1
index a4f883e..b92bede 100644
@@ -87,7 +87,7 @@ int rxrpc_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
 		if (!skb) {
 			/* nothing remains on the queue */
 			if (copied &&
-			    (msg->msg_flags & MSG_PEEK || timeo == 0))
+			    (flags & MSG_PEEK || timeo == 0))
 				goto out;
 
 			/* wait for a message to turn up */
maintainer
#1 lore raw

From: Al Viro <[email protected]>
Date: Sat, 14 Mar 2015 05:34:56 +0000

Quoted 8 lines

[I would really like an ACK on that one from dhowells; it appears to be quite straightforward, but...]

MSG_PEEK isn't passed to ->recvmsg() via msg->msg_flags; as the matter of fact, neither the kernel users of rxrpc, nor the syscalls ever set that bit in there. It gets passed via flags; in fact, another such check in the same function is done correctly - as flags & MSG_PEEK.

Quoted 5 lines

It had been that way (effectively disabled) for 8 years, though, so the patch needs beating up - that case had never been tested. If it is correct, it's -stable fodder.

Also applied and queued up for -stable, thanks Al.