linux-kernel - Re: [PATCH net] tcp: devmem: properly export MSG

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHS8izP7fGd+6jvT7q1dRxfmRGbVSQwhwW=pFMpc21YtGqQm4A@mail.gmail.com>
Date: Tue, 18 Feb 2025 12:10: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, 
	willemb@...gle.com, kaiyuanz@...gle.com
Subject: Re: [PATCH net] tcp: devmem: properly export MSG_CTRUNC to userspace

On Tue, Feb 18, 2025 at 11:40 AM 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

The intended API in this scenario is that the user will receive *one*
dmabuf_cmgs. The kernel will consider that data in that frag to be
delivered to userspace, and subsequent recvmsg() calls will not
re-deliver that data. The next recvmsg() call will deliver the data
that we failed to put_cmsg() in the current call.

If you receive two dmabuf_cmsgs in this scenario, that is indeed a
bug. Exposing CMSG_CTRUNC could be a good fix. It may indicate to the
user "ignore the last cmsg we put, because it got truncated, and
you'll receive the full cmsg on the next recvmsg call". We do need to
update the docs for this I think.

However, I think a much much better fix is to modify put_cmsg() so
that we only get one dmabuf_cmsgs in this scenario, if possible. We
could add a strict flag to put_cmsg(). If (strict == true &&
msg->controlllen < cmlen), we return an error instead of putting a
truncated cmsg, so that the user only sees one dmabuf_cmsg in this
scenario.

Is this doable?

--
Thanks,
Mina