linux-kernel - Re: [PROBLEM] make randconfig: fs/btrfs/ref-verify.c:500:16: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

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]

Date: Thu, 27 Jun 2024 19:11:41 +0100
From: Filipe Manana <fdmanana@...nel.org>
To: Mirsad Todorovac <mtodorovac69@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Kernel Build System <linux-kbuild@...r.kernel.org>, Chris Mason <clm@...com>, 
	Josef Bacik <josef@...icpanda.com>, David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org
Subject: Re: [PROBLEM] make randconfig: fs/btrfs/ref-verify.c:500:16: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

On Thu, Jun 27, 2024 at 7:07 PM Mirsad Todorovac <mtodorovac69@...il.com> wrote:
>
> Hi all,
>
> After following Boris' advice in https://lore.kernel.org/lkml/20240404134142.GCZg6uFh_ZSzUFLChd@fat_crate.local/
> on using the randconfig test, this is the second catch:
>
> KCONFIG_SEED=0xEE80059C
>
> marvin@...iant:~/linux/kernel/linux_torvalds$ time nice make -j 36 bindeb-pkg |& tee ../err-6.10-rc5-05a.log; date
>   GEN     debian
> dpkg-buildpackage --build=binary --no-pre-clean --unsigned-changes -R'make -f debian/rules' -j1 -a$(cat debian/arch)
> dpkg-buildpackage: info: source package linux-upstream
> dpkg-buildpackage: info: source version 6.10.0-rc5-gafcd48134c58-27
> dpkg-buildpackage: info: source distribution jammy
> dpkg-buildpackage: info: source changed by marvin <marvin@...iant>
> dpkg-architecture: warning: specified GNU system type i686-linux-gnu does not match CC system type x86_64-linux-gnu, try setting a correct CC environment variable
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture i386
>  make -f debian/rules binary
> #
> # No change to .config
> #
>   CALL    scripts/checksyscalls.sh
>   UPD     init/utsversion-tmp.h
>   CC      init/version.o
>   AR      init/built-in.a
>   CHK     kernel/kheaders_data.tar.xz
>   CC [M]  fs/btrfs/ref-verify.o
>   AR      fs/built-in.a
> fs/btrfs/ref-verify.c: In function ‘process_extent_item.isra’:
> fs/btrfs/ref-verify.c:500:16: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>   500 |         return ret;
>       |                ^~~
> cc1: all warnings being treated as errors
> make[7]: *** [scripts/Makefile.build:244: fs/btrfs/ref-verify.o] Error 1
> make[6]: *** [scripts/Makefile.build:485: fs/btrfs] Error 2
> make[5]: *** [scripts/Makefile.build:485: fs] Error 2
> make[4]: *** [Makefile:1934: .] Error 2
> make[3]: *** [debian/rules:74: build-arch] Error 2
> dpkg-buildpackage: error: make -f debian/rules binary subprocess returned exit status 2
> make[2]: *** [scripts/Makefile.package:121: bindeb-pkg] Error 2
> make[1]: *** [/home/marvin/linux/kernel/linux_torvalds/Makefile:1555: bindeb-pkg] Error 2
> make: *** [Makefile:240: __sub-make] Error 2
>
> real    0m2.583s
> user    0m9.943s
> sys     0m5.607s
> Thu Jun 27 19:14:55 CEST 2024
> marvin@...iant:~/linux/kernel/linux_torvalds$
>
> This fix does nothing to the algorithm, but it silences compiler -Werror=maybe-uninitialised

You've reported this before, and there's a fix [1] for it in the
btrfs' github repo, for-next branch. It's not yet in Linus' tree.

[1] https://lore.kernel.org/linux-btrfs/612bf950d478214e8b76bdd7c22dd6a991337b15.1719143259.git.fdmanana@suse.com/

>
> ---
> diff --git a/fs/btrfs/ref-verify.c b/fs/btrfs/ref-verify.c
> index cf531255ab76..0b5ff30e2d81 100644
> --- a/fs/btrfs/ref-verify.c
> +++ b/fs/btrfs/ref-verify.c
> @@ -459,6 +459,8 @@ static int process_extent_item(struct btrfs_fs_info *fs_info,
>                 iref = (struct btrfs_extent_inline_ref *)(ei + 1);
>         }
>
> +       ret = -EINVAL;
> +

This is not correct.
This would result in failure if we have an extent item without any
inline references (only keyed references following the extent item).

Thanks.

>         ptr = (unsigned long)iref;
>         end = (unsigned long)ei + item_size;
>         while (ptr < end) {
> ---
>
> Hope this helps.
>
> Best regards,
> Mirsad Todorovac
>