netdev - Re: [PATCH net v2 2/3] net: prevent rewrite of msg_name in sock

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]

Date: Mon, 18 Sep 2023 13:54:54 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jordan Rife <jrife@...gle.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, 
	pabeni@...hat.com, netdev@...r.kernel.org, dborkman@...nel.org
Subject: Re: [PATCH net v2 2/3] net: prevent rewrite of msg_name in sock_sendmsg()

On Mon, Sep 18, 2023 at 1:52 PM Jordan Rife <jrife@...gle.com> wrote:
>
> > You used this short-hand to avoid having to update all callers to sock_sendmsg to __kernel_sendmsg?
>
> Sorry about that, I misunderstood the intent. I'm fine with
> introducing a new function, doing the address copy there, and
> replacing all calls to sock_sendmsg with this wrapper. One thought on
> the naming though,
>
> To me the "__" prefix seems out of place for a function meant as a
> public interface. Some possible alternatives:
>
> 1) Rename the current kernel_sendmsg() function to
> kernel_sendmsg_kvec() and name  our new function kernel_sendmsg(). To
> me this makes some sense, considering the new function is the more
> generic of the two, and the existing kernel_sendmsg() specifically
> accepts "struct kvec".
> 2) Same as #1, but drop the old kernel_sendmsg() function instead of
> renaming it. Adapt all calls to the old kernel_sendmsg() to fit the
> new kernel_sendmsg() (this amounts to adding a
> iov_iter_kvec(&msg->msg_iter, ITER_SOURCE, vec, num, size); call in
> each spot before kernel_sendmsg() is called.

Thanks. Fair points.

Of the two proposals, I think the first is preferable, as it avoids
some non-trivial open coding in multiple callers.