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: <20191002140138.eug7xvwhlsn5qnby@MacBook-Pro-91.local>
Date:   Wed, 2 Oct 2019 10:01:39 -0400
From:   Josef Bacik <josef@...icpanda.com>
To:     Colin Ian King <colin.king@...onical.com>
Cc:     Chris Mason <clm@...com>, Josef Bacik <josef@...icpanda.com>,
        David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Btrfs: add a extent ref verify tool (static analysis bug report)

On Wed, Oct 02, 2019 at 02:50:51PM +0100, Colin Ian King wrote:
> Hi,
> 
> Static analysis on linux-next with Coverity has picked up a potential
> issue in file fs/btrfs/ref-verify.c, function process_leaf() in the
> following commit:
> 
> commit fd708b81d972a0714b02a60eb4792fdbf15868c4
> Author: Josef Bacik <josef@...icpanda.com>
> Date:   Fri Sep 29 15:43:50 2017 -0400
> 
>     Btrfs: add a extent ref verify tool
> 
> The potential issue is when on the unlikely event when all the items
> contain unknown key.types and so ret is not assigned a value. Since ret
> is not initialized then a garbage value is returned by this function in
> this unlikely scenario.
> 
> In the previous function process_extent_item any unknown key types are
> flagged up as an error and -EINVAL is returned.  I'm unsure if this kind
> of error handling should also be applied to function process_leaf with
> invalid key types too.
> 

Thanks I'll fix this up.  You can run into block group item key types and we
don't care about those, so we just need ret = 0;  Thanks,

Josef

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ