From: Stanislav Fomichev <stfomichev@gmail.com>
To: Pavel Begunkov <asml.silence@gmail.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, horms@kernel.org,
sagi@grimberg.me, willemb@google.com, almasrymina@google.com,
kaiyuanz@google.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: devmem: drop iterator type check
Date: Mon, 19 May 2025 07:41:52 -0700 [thread overview]
Message-ID: <aCtDMJDtP0DxUBqj@mini-arch> (raw)
In-Reply-To: <ab1959f9-1b94-4e7f-ba33-12453cb50027@gmail.com>
On 05/19, Pavel Begunkov wrote:
> On 5/16/25 23:54, Stanislav Fomichev wrote:
> > sendmsg() with a single iov becomes ITER_UBUF, sendmsg() with multiple
> > iovs becomes ITER_IOVEC. Instead of adjusting the check to include
> > ITER_UBUF, drop the check completely. The callers are guaranteed
> > to happen from system call side and we don't need to pay runtime
> > cost to verify it.
>
> I asked for this because io_uring can pass bvecs. Only sendzc can
> pass that with cmsg, so probably you won't be able to hit any
> real issue, but io_uring needs and soon will have bvec support for
> normal sends as well. One can argue we should care as it isn't
> merged yet, but there is something very very wrong if an unrelated
> and legal io_uring change is able to open a vulnerability in the
> devmem path.
Any reason not to filter these out on the io_uring side? Or you'll
have to interpret sendmsg flags again which is not nice?
next prev parent reply other threads:[~2025-05-19 14:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-16 22:54 [PATCH net-next] net: devmem: drop iterator type check Stanislav Fomichev
2025-05-17 4:45 ` Mina Almasry
2025-05-17 4:48 ` Stanislav Fomichev
2025-05-19 10:45 ` Pavel Begunkov
2025-05-19 14:41 ` Stanislav Fomichev [this message]
2025-05-19 15:19 ` Pavel Begunkov
2025-05-19 15:39 ` Stanislav Fomichev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aCtDMJDtP0DxUBqj@mini-arch \
--to=stfomichev@gmail.com \
--cc=almasrymina@google.com \
--cc=asml.silence@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=kaiyuanz@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sagi@grimberg.me \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.