| Message ID | 20250219203102.1053122-1-sdf@fomichev.me (mailing list archive) |
|---|---|
| State | New |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net,v2] tcp: devmem: don't write truncated dmabuf CMSGs to userspace | expand |
On Wed, Feb 19, 2025 at 12:31 PM Stanislav Fomichev <sdf@fomichev.me> wrote: > > Currently, we report -ETOOSMALL (err) only on the first iteration > (!sent). When we get put_cmsg error after a bunch of successful > put_cmsg calls, we don't signal the error at all. This might be > confusing on the userspace side which will see truncated CMSGs > but no MSG_CTRUNC signal. > > Consider the following case: > - sizeof(struct cmsghdr) = 16 > - sizeof(struct dmabuf_cmsg) = 24 > - total cmsg size (CMSG_LEN) = 40 (16+24) > > When calling recvmsg with msg_controllen=60, the userspace > will receive two(!) dmabuf_cmsg(s), the first one will > be a valid one and the second one will be silently truncated. There is no > easy way to discover the truncation besides doing something like > "cm->cmsg_len != CMSG_LEN(sizeof(dmabuf_cmsg))". > > Introduce new put_devmem_cmsg wrapper that reports an error instead > of doing the truncation. Mina suggests that it's the intended way > this API should work. > > Note that we might now report MSG_CTRUNC when the users (incorrectly) > call us with msg_control == NULL. > Hmm, this happens when the user essentially lies about the actual size of the buffer I guess? So the userspace does: msg.msg_control = NULL; msg.msg_controllen = 100; If so, I think the user is giving obviously invalid input to the kernel. I think the user getting MSG_CTRUNC here is fine. I prefer if we handle this edge case. We could have put_devmem_cmsg() check for non-null msg->msg_control so we're absolutely sure the resulting put_cmsg() doesn't fail to find space. But I don't think it's very critical to handle this very invalid input from the user. MSG_CTRUNC in this scenario seems fine. So, FWIW, Reviewed-by: Mina Almasry <almasrymina@google.com> -- Thanks, Mina
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 0d704bda6c41..ba77beba60c4 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -2394,6 +2394,16 @@ static int tcp_xa_pool_refill(struct sock *sk, struct tcp_xa_pool *p, return k ? 0 : err; } +static int put_devmem_cmsg(struct msghdr *msg, int level, int type, int len, + void *data) +{ + /* Don't produce truncated CMSGs */ + if (msg->msg_controllen < CMSG_LEN(len)) + return -ETOOSMALL; + + return put_cmsg(msg, level, type, len, data); +} + /* On error, returns the -errno. On success, returns number of bytes sent to the * user. May not consume all of @remaining_len. */ @@ -2438,10 +2448,10 @@ static int tcp_recvmsg_dmabuf(struct sock *sk, const struct sk_buff *skb, */ memset(&dmabuf_cmsg, 0, sizeof(dmabuf_cmsg)); dmabuf_cmsg.frag_size = copy; - err = put_cmsg(msg, SOL_SOCKET, SO_DEVMEM_LINEAR, - sizeof(dmabuf_cmsg), &dmabuf_cmsg); + err = put_devmem_cmsg(msg, SOL_SOCKET, SO_DEVMEM_LINEAR, + sizeof(dmabuf_cmsg), + &dmabuf_cmsg); if (err || msg->msg_flags & MSG_CTRUNC) { - msg->msg_flags &= ~MSG_CTRUNC; if (!err) err = -ETOOSMALL; goto out; @@ -2499,12 +2509,11 @@ static int tcp_recvmsg_dmabuf(struct sock *sk, const struct sk_buff *skb, offset += copy; remaining_len -= copy; - err = put_cmsg(msg, SOL_SOCKET, - SO_DEVMEM_DMABUF, - sizeof(dmabuf_cmsg), - &dmabuf_cmsg); + err = put_devmem_cmsg(msg, SOL_SOCKET, + SO_DEVMEM_DMABUF, + sizeof(dmabuf_cmsg), + &dmabuf_cmsg); if (err || msg->msg_flags & MSG_CTRUNC) { - msg->msg_flags &= ~MSG_CTRUNC; if (!err) err = -ETOOSMALL; goto out;
Currently, we report -ETOOSMALL (err) only on the first iteration (!sent). When we get put_cmsg error after a bunch of successful put_cmsg calls, we don't signal the error at all. This might be confusing on the userspace side which will see truncated CMSGs but no MSG_CTRUNC signal. Consider the following case: - sizeof(struct cmsghdr) = 16 - sizeof(struct dmabuf_cmsg) = 24 - total cmsg size (CMSG_LEN) = 40 (16+24) When calling recvmsg with msg_controllen=60, the userspace will receive two(!) dmabuf_cmsg(s), the first one will be a valid one and the second one will be silently truncated. There is no easy way to discover the truncation besides doing something like "cm->cmsg_len != CMSG_LEN(sizeof(dmabuf_cmsg))". Introduce new put_devmem_cmsg wrapper that reports an error instead of doing the truncation. Mina suggests that it's the intended way this API should work. Note that we might now report MSG_CTRUNC when the users (incorrectly) call us with msg_control == NULL. Fixes: 8f0b3cc9a4c1 ("tcp: RX path for devmem TCP") Signed-off-by: Stanislav Fomichev <sdf@fomichev.me> --- net/ipv4/tcp.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-)