netdev - Re: [PATCH net v2] tcp: devmem: don't write truncated dmabuf CMSGs to userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHS8izNWx39025Hm=cY6JDDL-VY1ggKWsx0+RvD-NCHULTT7sQ@mail.gmail.com>
Date: Wed, 19 Feb 2025 14:37:41 -0800
From: Mina Almasry <almasrymina@...gle.com>
To: Stanislav Fomichev <sdf@...ichev.me>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, linux-kernel@...r.kernel.org, 
	ncardwell@...gle.com, kuniyu@...zon.com, dsahern@...nel.org, horms@...nel.org, 
	kaiyuanz@...gle.com, asml.silence@...il.com
Subject: Re: [PATCH net v2] tcp: devmem: don't write truncated dmabuf CMSGs to userspace

On Wed, Feb 19, 2025 at 12:31 PM Stanislav Fomichev <sdf@...ichev.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@...gle.com>

--
Thanks,
Mina