]> www.infradead.org Git - users/hch/misc.git/commit
tcp: devmem: don't write truncated dmabuf CMSGs to userspace
authorStanislav Fomichev <sdf@fomichev.me>
Mon, 24 Feb 2025 17:44:01 +0000 (09:44 -0800)
committerJakub Kicinski <kuba@kernel.org>
Wed, 26 Feb 2025 02:15:43 +0000 (18:15 -0800)
commit18912c520674ec4d920fe3826e7e4fefeecdf5ae
tree5cf7206b5d5512dc463da8f47aa407b01505a1c7
parentbab3a6e9ffd600f9db0ebaf8f45e1c6111cf314c
tcp: devmem: don't write truncated dmabuf CMSGs to userspace

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")
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250224174401.3582695-1-sdf@fomichev.me
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
include/linux/socket.h
net/core/scm.c
net/ipv4/tcp.c