linux-kernel - Re: [PATCH 2/8] libertas: change snprintf to scnprintf for possible overflow

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]

Message-ID: <20190115203503.GA7117@1wt.eu>
Date:   Tue, 15 Jan 2019 21:35:03 +0100
From:   Willy Tarreau <w@....eu>
To:     Kalle Valo <kvalo@...eaurora.org>
Cc:     Silvio Cesare <silvio.cesare@...il.com>,
        linux-kernel@...r.kernel.org,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Kees Cook <keescook@...omium.org>,
        Will Deacon <will.deacon@....com>, Greg KH <greg@...ah.com>
Subject: Re: [PATCH 2/8] libertas: change snprintf to scnprintf for possible
 overflow

On Tue, Jan 15, 2019 at 07:55:36AM +0200, Kalle Valo wrote:
> Willy Tarreau <w@....eu> writes:
> 
> > From: Silvio Cesare <silvio.cesare@...il.com>
> >
> > Change snprintf to scnprintf. There are generally two cases where using
> > snprintf causes problems.
> >
> > 1) Uses of size += snprintf(buf, SIZE - size, fmt, ...)
> > In this case, if snprintf would have written more characters than what the
> > buffer size (SIZE) is, then size will end up larger than SIZE. In later
> > uses of snprintf, SIZE - size will result in a negative number, leading
> > to problems. Note that size might already be too large by using
> > size = snprintf before the code reaches a case of size += snprintf.
> >
> > 2) If size is ultimately used as a length parameter for a copy back to user
> > space, then it will potentially allow for a buffer overflow and information
> > disclosure when size is greater than SIZE. When the size is used to index
> > the buffer directly, we can have memory corruption. This also means when
> > size = snprintf... is used, it may also cause problems since size may become
> > large.  Copying to userspace is mitigated by the HARDENED_USERCOPY kernel
> > configuration.
> >
> > The solution to these issues is to use scnprintf which returns the number of
> > characters actually written to the buffer, so the size variable will never
> > exceed SIZE.
> >
> > Signed-off-by: Silvio Cesare <silvio.cesare@...il.com>
> > Cc: Kalle Valo <kvalo@...eaurora.org>
> > Cc: Dan Carpenter <dan.carpenter@...cle.com>
> > Cc: Kees Cook <keescook@...omium.org>
> > Cc: Will Deacon <will.deacon@....com>
> > Cc: Greg KH <greg@...ah.com>
> > Signed-off-by: Willy Tarreau <w@....eu>
> 
> I don't see any mention about which tree this should go to. Can I take
> this to wireless-drivers-next?

Possibly. It addresses a small memory disclosure issue when using debugfs,
and as such it should probably also be submitted to stable branches, so
please use the most suitable tree that doesn't add too much extra delay.

Thanks,
Willy