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  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:   Fri, 23 Oct 2020 08:07:44 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Jakub Kicinski' <kuba@...nel.org>,
        Kees Cook <keescook@...omium.org>
CC:     Francis Laniel <laniel_francis@...vacyrequired.com>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [RFC][PATCH v3 3/3] Rename nla_strlcpy to nla_strscpy.

From: Jakub Kicinski
> Sent: 23 October 2020 00:06
> 
> On Thu, 22 Oct 2020 13:04:32 -0700 Kees Cook wrote:
> > > > > From: Francis Laniel <laniel_francis@...vacyrequired.com>
> > > > >
> > > > > Calls to nla_strlcpy are now replaced by calls to nla_strscpy which is the
> > > > > new name of this function.
> > > > >
> > > > > Signed-off-by: Francis Laniel <laniel_francis@...vacyrequired.com>
> > > >
> > > > The Subject could also be: "treewide: Rename nla_strlcpy to nla_strscpy"
> > > >
> > > > But otherwise, yup, easy mechanical change.
> > >
> > > Should I submit a v4 for this change?
> >
> > I'll say yes. :) Drop the RFC, bump to v4, and send it to netdev (along
> > with all the other CCs you have here already), and add the Reviewed-bys
> > from v3.
> 
> Maybe wait until next week, IIRC this doesn't fix any bugs, so it's
> -next material. We don't apply anything to net-next during the merge
> window.

Is this just a rename, or have you changed the result value?
In the latter case the subject is really right.

FWIW I suspect  the 'return -ERR on overflow' is going to bite us.
Code that does p += strsxxx(p, ..., lim - p, ...) assuming (or not
caring) about overflow goes badly wrong.

To my mind returning the full buffer length (ie include the '\0')
on overflow still allows overflow be checked but makes writes
outside the buffer very unlikely.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists