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, 23 Feb 2017 09:07:41 +1100
From:   Dave Chinner <david@...morbit.com>
To:     "Reshetova, Elena" <elena.reshetova@...el.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "darrick.wong@...cle.com" <darrick.wong@...cle.com>,
        Hans Liljestrand <ishkamiel@...il.com>,
        Kees Cook <keescook@...omium.org>,
        David Windsor <dwindsor@...il.com>
Subject: Re: [PATCH 1/7] fs, xfs: convert xfs_bui_log_item.bui_refcount from
 atomic_t to refcount_t

On Wed, Feb 22, 2017 at 11:20:31AM +0000, Reshetova, Elena wrote:
> > On Tue, Feb 21, 2017 at 05:49:01PM +0200, Elena Reshetova wrote:
> > > refcount_t type and corresponding API should be
> > > used instead of atomic_t when the variable is used as
> > > a reference counter. This allows to avoid accidental
> > > refcounter overflows that might lead to use-after-free
> > > situations.
> > 
> > I'm missing something: how do you overflow a log item object
> > reference count?
> 
> We are currently converting all reference counters present in kernel to a safer refcount_t type. 

Yes, I see that you are taking anything that you *think* is an
object lifetime reference counter and changing it.

> Agreed, in some cases it might be easier or harder to actually create/trigger an overflow, but since it can be caused even by a bug in the legitimate code (current version or its future iterative), it is good idea to do "safe defaults" and stop worrying about the problem. 
> 
> Do you have any reasons why it should not be converted? 

It's core dirty metadata object code.  Any change to code in this
area needs to be gone over with a fine tooth comb, because bugs can
result in filesystem and/or journal corruption issues that may not
be noticed until a system crashes and log recovery fails and the
user loses their entire filesystem....

Hence the repeated comments about needing to actually test the code
you are changing.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com

Powered by blists - more mailing lists