Re: [PATCH net-next] net: devmem: drop iterator type check

[Stanislav Fomichev <stfomichev@gmail.com>]

On 05/19, Pavel Begunkov wrote:
> On 5/19/25 15:41, Stanislav Fomichev wrote:
> > 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?
> 
> Right, io_uring would need to walk cmsg for all sends, which is not
> great for layering. And then it's really a devmem quirk that it uses
> iterators in a non orthodox way, it'd be awkward to check a random
> devmem restriction in io_uring, when otherwise they know nothing
> about each other. And it's safer to keep local to devmem, because
> try to remember if something changes, and what if there is someone
> new passing non-iovec iter + cmsg in the future.

SG, will change this to filter both IOVEC and UBUF, thanks!
(pending discussion with Al about what to do with UBUF in
https://lore.kernel.org/netdev/20250517000907.GW2023217@ZenIV/)