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
| ||
|
Date: Mon, 8 Nov 2021 18:49:29 +0530 From: Ajay Garg <ajaygargnsit@...il.com> To: Greg KH <gregkh@...uxfoundation.org> Cc: andy@...nel.org, Kees Cook <keescook@...omium.org>, akpm@...ux-foundation.org, adobriyan@...il.com, Nick Desaulniers <ndesaulniers@...gle.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-hardening@...r.kernel.org Subject: Re: RFC for a new string-copy function, using mixtures of strlcpy and strscpy On Mon, Nov 8, 2021 at 6:31 PM Greg KH <gregkh@...uxfoundation.org> wrote: > > On Mon, Nov 08, 2021 at 06:15:54PM +0530, Ajay Garg wrote: > > Hi Greg, > > > > Thanks for your time. > > > > > > > > Wait, why? We have recently added new string copy functions to resolve > > > the type of issues you have pointed out. The kernel is not yet > > > converted to use them, so why add yet-another-function that also is not > > > used? > > > > Greg, would request your couple of minutes more, in suggesting a > > concrete way forward, by working through an example as below. > > > > > > In the file fs/kernfs/dir.c, there is a statement > > > > return strlcpy(buf, kn->parent ? kn->name : "/", buflen); > > > > Here, there is no information of how long kn->name might be, so there > > is a definite chance of overflow happening. Thus, accordingly, strlcpy > > is used, to bound copying of upto buflen bytes. Of course, buf > > (destination-buffer) is safe from any overflow now. > > We "know" that kn->name will not overflow here based on the callers of > this function, right? I can not find any caller that passes in a buffer > that would overflow, or am I missing a callpath somewhere? > > > However, iffff strlen(kn->name) is greater than (buflen - 1), then > > strlcpy would return a different value than the number of bytes > > actually copied. Since there is no check, this (wrong) return value > > will be propagated to the clients down the stack. > > But in the existing kernel, can that happen today? I can't find any > caller that would be using this in that manner. > > And that's what matters. Not the theoretical callers in the possible > future, but the in-kernel users of the functions today. > > If these calls are wrong, then they should be fixed, but adding another > string function to the heap of ones we have should only be done after > considering the ones that we currently have, why they were added, and > why existing code has not yet been converted to use them. > Got it, thanks Greg ! Thanks and Regards, Ajay
Powered by blists - more mailing lists