linux-kernel - RE: [PATCH 00/11] nfs refcount conversions

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]

Date:   Mon, 23 Oct 2017 07:30:34 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     "J. Bruce Fields" <bfields@...ldses.org>
CC:     "trond.myklebust@...marydata.com" <trond.myklebust@...marydata.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
        "anna.schumaker@...app.com" <anna.schumaker@...app.com>,
        "jlayton@...chiereds.net" <jlayton@...chiereds.net>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "keescook@...omium.org" <keescook@...omium.org>
Subject: RE: [PATCH 00/11] nfs refcount conversions


> On Fri, Oct 20, 2017 at 12:53:27PM +0300, Elena Reshetova wrote:
> > This series, for nfs components, replaces atomic_t reference
> > counters with the new refcount_t type and API (see include/linux/refcount.h).
> > By doing this we prevent intentional or accidental
> > underflows or overflows that can led to use-after-free vulnerabilities.
> >
> > The patches are fully independent and can be cherry-picked separately.
> > If there are no objections to the patches, please merge them via respective trees.
> >
> > Rebased on top of linux-next.
> >
> > Elena Reshetova (11):
> >   fs, nfsd: convert nfs4_stid.sc_count from atomic_t to refcount_t
> >   fs, nfsd: convert nfs4_cntl_odstate.co_odcount from atomic_t to
> >     refcount_t
> >   fs, nfsd: convert nfs4_file.fi_ref from atomic_t to refcount_t
> 
> Thanks, applying for 4.15.

Thank you very much!

> 
> I haven't followed recent discussion on the refcount api, but I assume
> the consensus is to do this, and these particular conversions certainly
> look trivial enough.

refcount_api will continue for evolve for some time I think, we recently got
x86 specific FAST implementation done, some other archs might follow.
There is an ongoing discussion about the memory ordering, which we have to
decide which way we want things to be, but these are all independent things
from the actual conversions. So for conversions that are basic and rather trivial, 
nothing should prevent doing them now.

Best Regards,
Elena.


> 
> --b.