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
| ||
|
Date: Tue, 25 Feb 2020 08:48:02 -0800 From: Arjun Roy <arjunroy@...gle.com> To: Eric Dumazet <edumazet@...gle.com> Cc: Arjun Roy <arjunroy.kdev@...il.com>, David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org>, Soheil Hassas Yeganeh <soheil@...gle.com>, Willem de Bruijn <willemb@...gle.com> Subject: Re: [PATCH net-next] tcp-zerocopy: Update returned getsockopt() optlen. On Mon, Feb 24, 2020 at 10:28 PM Eric Dumazet <edumazet@...gle.com> wrote: > > On Mon, Feb 24, 2020 at 10:06 PM Arjun Roy <arjunroy.kdev@...il.com> wrote: > > > > From: Arjun Roy <arjunroy@...gle.com> > > > > TCP receive zerocopy currently does not update the returned optlen for > > getsockopt(). Thus, userspace cannot properly determine if all the > > fields are set in the passed-in struct. This patch sets the optlen > > before return, in keeping with the expected operation of getsockopt(). > > > > Signed-off-by: Arjun Roy <arjunroy@...gle.com> > > Signed-off-by: Eric Dumazet <edumazet@...gle.com> > > Signed-off-by: Soheil Hassas Yeganeh <soheil@...gle.com> > > Signed-off-by: Willem de Bruijn <willemb@...gle.com> > > Fixes: c8856c051454 ("tcp-zerocopy: Return inq along with tcp receive > > zerocopy") > > > OK, please note for next time : > > Fixes: tag should not wrap : It should be a single line. > Preferably it should be the first tag (before your Sob) > > Add v2 as in [PATCH v2 net-next] : so that reviewers can easily see > which version is the more recent one. > > > > > > + if (!err) { > > + if (put_user(len, optlen)) > > + return -EFAULT; > > Sorry for not asking this before during our internal review : > > Is the cost of the extra STAC / CLAC (on x86) being high enough that it is worth > trying to call put_user() only if user provided a different length ? I'll have to defer to someone with more understanding of the overheads involved in this case. -Arjun
Powered by blists - more mailing lists