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] [day] [month] [year] [list]
Message-ID: <20211018153122.2f667226@gandalf.local.home>
Date:   Mon, 18 Oct 2021 15:31:22 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Lukas Bulwahn <lukas.bulwahn@...il.com>
Cc:     llvm@...ts.linux.dev,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Some potentially uninitialized values in pid_list_refill_irq()

On Mon, 18 Oct 2021 18:14:53 +0200
Lukas Bulwahn <lukas.bulwahn@...il.com> wrote:

> Dear Steven,
> 
> Commit 8d6e90983ade ("tracing: Create a sparse bitmask for pid
> filtering") in linux-next adds the new function pid_list_refill_irq().
> For this function, 'make clang-analyzer' reports potentially
> uninitialized values for lower and upper under certain branch
> conditions, see the full report below.
> 
> As far as I understand the analyzer's report and the code at hand:
> 
> if lower_count is zero (and upper_count is not), then lower_next is
> not assigned (because the while lower_count loop is not entered) and
> lower is pointing to an address with an uninitialized value and hence,
> the if (lower) conditional reads this uninitialized value.
> 
> Analogously for upper_count:
> 
> if upper_count is zero (and lower_count is not), then upper_count is
> not assigned (because the while upper_count loop is not entered) and
> upper is pointing to an address with an uninitialized value and hence,
> the if (upper) conditional reads this uninitialized value.
> 
> I think this can be resolved by initializing upper and lower to point
> to an address carrying a zero; but I really fight understanding the
> whole pointer magic, you did :)
> 
> Let me know if clang-analyzer found something buggy here or if the
> tool and I misunderstood the code; we are certainly interested.
> 

No, you are the third (or fourth) person to report this. I just haven't
gotten around to pushing my fixes to linux-next, as my test boxes have been
busy testing stuff for current 5.15-rc. And the fixes are still in the
queue to be tested.

I'll have that fixed in a couple of days at most.

Thanks,

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ