linux-kernel - Re: LZ4 decompressor broken on ARM due to missing strchrnul() string traverse in cpumask

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: <ffc779fe-3735-9665-8ee2-6a3ff1a7dd83@rasmusvillemoes.dk>
Date:   Tue, 28 May 2019 13:33:12 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Yury Norov <ynorov@...vell.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     tglx@...utronix.de, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: LZ4 decompressor broken on ARM due to missing strchrnul() string
 traverse in cpumask_parse"

On 28/05/2019 13.04, Sebastian Andrzej Siewior wrote:
> |  CC      arch/arm/boot/compressed/decompress.o
> |In file included from include/linux/mm_types_task.h:14,
> |                 from include/linux/mm_types.h:5,
> |                 from include/linux/mmzone.h:21,
> |                 from include/linux/gfp.h:6,
> |                 from include/linux/umh.h:4,
> |                 from include/linux/kmod.h:22,
> |                 from include/linux/module.h:13,
> |                 from arch/arm/boot/compressed/../../../../lib/lz4/lz4_decompress.c:39,
> |                 from arch/arm/boot/compressed/../../../../lib/decompress_unlz4.c:13,
> |                 from arch/arm/boot/compressed/decompress.c:55:
> |include/linux/cpumask.h: In function ‘cpumask_parse’:
> |include/linux/cpumask.h:636:21: error: implicit declaration of function ‘strchrnul’; did you mean ‘strchr’? [-Werror=implicit-function-declaration]
> |  unsigned int len = strchrnul(buf, '\n') - buf;
> |                     ^~~~~~~~~
> |                     strchr
> |include/linux/cpumask.h:636:42: error: invalid operands to binary - (have ‘int’ and ‘const char *’)
> |  unsigned int len = strchrnul(buf, '\n') - buf;
> |                     ~~~~~~~~~~~~~~~~~~~~ ^
> |cc1: some warnings being treated as errors
> 
> 3713a4e1fdb8da86f96a3e770b08e278d97529b4 is the first bad commit
> commit 3713a4e1fdb8da86f96a3e770b08e278d97529b4
> Author: Yury Norov <ynorov@...vell.com>
> Date:   Tue May 14 15:44:46 2019 -0700
> 
>     include/linux/cpumask.h: fix double string traverse in cpumask_parse
> 
>     cpumask_parse() finds first occurrence of either or strchr() and
>     strlen().  We can do it better with a single call of strchrnul().
> 
>     [akpm@...ux-foundation.org: remove unneeded cast]
>     Link: http://lkml.kernel.org/r/20190409204208.12190-1-ynorov@marvell.com
>     Signed-off-by: Yury Norov <ynorov@...vell.com>
>     Acked-by: Rasmus Villemoes <linux@...musvillemoes.dk>
>     Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
> 
> :040000 040000 f20d8a9ec1755b3981520ecf015248f6a0d9f116 db67caf64f99a9be808cd73e413c106c5aee15b7 M      include
> 
> This commit is v5.2-rc1~62^2~49.
> How do we deal with this one?

Urgh. The problem is really in arch/arm/boot/compressed/decompress.c
which does

#define _LINUX_STRING_H_

preventing linux/string.h from providing strchrnul. It also #includes
asm/string.h, which for arm has a declaration of strchr(), explaining
why this didn't use to fail.

However, the solution is also in the same file, it already has a section

/* Not needed, but used in some headers pulled in by decompressors */
extern char * strstr(const char * s1, const char *s2);
extern size_t strlen(const char *s);
extern int memcmp(const void *cs, const void *ct, size_t count);

so just add another declaration to that list - I strongly assume we
won't get a link failure since I find it hard to believe the
decompressor would actually call cpumask_parse...

I'm wondering why this wasn't caught by 0day and/or while in -next?

Rasmus