linux-kernel - Re: Regression in 5.1.20: Reading long directory fails

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]

Message-ID: <20190912131359.GB31879@fieldses.org>
Date:   Thu, 12 Sep 2019 09:13:59 -0400
From:   "J. Bruce Fields" <bfields@...ldses.org>
To:     Benjamin Coddington <bcodding@...hat.com>
Cc:     Trond Myklebust <trondmy@...merspace.com>, chuck.lever@...cle.com,
        tibbs@...h.uh.edu, linux@...m.de, linux-nfs@...r.kernel.org,
        linux-kernel@...r.kernel.org, km@...all.com
Subject: Re: Regression in 5.1.20: Reading long directory fails

On Thu, Sep 12, 2019 at 09:08:51AM -0400, Benjamin Coddington wrote:
> 
> On 12 Sep 2019, at 8:53, Trond Myklebust wrote:
> > Let's please just scrap this function and rewrite it as a generic
> > function for reading the MIC. It clearly is not a generic function for
> > reading arbitrary netobjs, and modifications like the above just make
> > the misnomer painfully obvious.
> >
> > Let's rewrite it as xdr_buf_read_mic() so that we can simplify it where
> > possible.
> 
> Ok.  I want to assume the mic will not land in the head, but I am not sure..
> Is there a scenario where the mic might land in the head, or is that bit of
> the current function left over from other uses?

Any reply that doesn't have page data?

A reply that ends up shorter than expected due to failure of an early op
in the compound?

(Unless I'm missing something.  I haven't looked at this code in a
while.  Though it was problem me that wrote it originally--apologies for
that....)

--b.