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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 26 Jul 2019 17:06:09 +0200
From:   David Sterba <dsterba@...e.cz>
To:     Qu Wenruo <quwenruo.btrfs@....com>
Cc:     Jia-Ju Bai <baijiaju1990@...il.com>, clm@...com,
        josef@...icpanda.com, dsterba@...e.com,
        linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fs: btrfs: Fix a possible null-pointer dereference in
 insert_inline_extent()

On Wed, Jul 24, 2019 at 10:57:24AM +0800, Qu Wenruo wrote:
> On 2019/7/24 上午10:33, Jia-Ju Bai wrote:
> > On 2019/7/24 10:21, Qu Wenruo wrote:
> >> On 2019/7/24 上午10:11, Jia-Ju Bai wrote:
> >>> In insert_inline_extent(), there is an if statement on line 181 to check
> >>> whether compressed_pages is NULL:
> >>>      if (compressed_size && compressed_pages)
> >>>
> >>> When compressed_pages is NULL, compressed_pages is used on line 215:
> >>>      cpage = compressed_pages[i];
> >>>
> >>> Thus, a possible null-pointer dereference may occur.
> >>>
> >>> To fix this possible bug, compressed_pages is checked on line 214.
> >> This can only be hit with compressed_size > 0 and compressed_pages !=
> >> NULL.
> >>
> >> It would be better to have an extra ASSERT() to warn developers about
> >> the impossible case.
> > 
> > Thanks for the reply :)
> > So I should add ASSERT(compressed_size > 0 & compressed_pages) at the
> > beginning of the function, and remove "if (compressed_size &&
> > compressed_pages)"?
> 
> My suggestion is, ASSERT((compressed_size >0 && compressed_pages) ||
> (compressed_size == 0 && !compressed_pages))
> 
> And keeps the original checks.
> 
> Anyway, just a suggestion.

Agreed, the assertion would be good, covering both cases in one
statement at the beginning of the function.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ