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: <908325ed-08af-4b0c-926e-da9afba25772@app.fastmail.com>
Date: Thu, 11 Jan 2024 13:55:15 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Dan Carpenter" <dan.carpenter@...aro.org>,
 "Naresh Kamboju" <naresh.kamboju@...aro.org>,
 "Uladzislau Rezki" <urezki@...il.com>
Cc: linux-next <linux-next@...r.kernel.org>,
 "open list" <linux-kernel@...r.kernel.org>,
 "Linux Regressions" <regressions@...ts.linux.dev>,
 clang-built-linux <llvm@...ts.linux.dev>, lkft-triage@...ts.linaro.org,
 "Andrew Morton" <akpm@...ux-foundation.org>
Subject: Re: mm/vmalloc.c:4691:25: error: variable 'addr' is uninitialized when used
 here [-Werror,-Wuninitialized]

On Thu, Jan 11, 2024, at 12:16, Dan Carpenter wrote:
> On Thu, Jan 11, 2024 at 04:23:09PM +0530, Naresh Kamboju wrote:
>> Following build failures noticed on i386 and x86 with clang builds on the
>> Linux next-20240111 tag.
>> 
>> Reported-by: Linux Kernel Functional Testing <lkft@...aro.org>
>> 
>> Build error:
>> ----------
>> mm/vmalloc.c:4691:25: error: variable 'addr' is uninitialized when
>> used here [-Werror,-Wuninitialized]
>>  4691 |                 va = __find_vmap_area(addr, &vn->busy.root);
>>       |                                       ^~~~
>> mm/vmalloc.c:4684:20: note: initialize the variable 'addr' to silence
>> this warning
>>  4684 |         unsigned long addr;
>>       |                           ^
>>       |                            = 0
>> 1 error generated.
>
> We turned off uninitialized variable warnings for GCC a long time ago...
> :/ I don't know if we'll be able to re-enable it in a -Werror world
> although Clang seems to be managing alright so perhaps there is hope.

The problem with gcc's warning is that it is non-deterministic and
in recent versions actually got more false-positives even without
-Os or -fsanitize=. Clang does not catch all that gcc does because
it doesn't track state across inline functions, but at least its
output is always the same regardless of optimization and other
options.

At least this particular one is an obvious bug and easily gets
caught by lkft and lkp even if gcc's -Wuninitilized doesn't
flag it.

    Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ