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
| ||
|
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