Questions about CVE-2016-8660

Questions about CVE-2016-8660

[zhengbin (A)]

Recently I am studying CVE-2016-8660, in https://seclists.org/oss-sec/2016/q4/118,
it says that this bug is introduced by commit fc0561cefc04 ("xfs: optimise away log forces on timestamp updates for fdatasync").
And in https://patchwork.kernel.org/patch/9363339/#19693745, david correction has nothing to do with this commit,
and is a page lock order bug in the XFS seek hole/data implementation(demsg is in http://people.redhat.com/qcai/tmp/dmesg-sync,
Unfortunately, it is not accessible now, I do not understand why this is a page lock order bug).

Is this CVE solved? Can I see the demsg in other way? thanks.

Questions about CVE-2016-8660

[zhengbin (A)]

Recently I am studying CVE-2016-8660, in https://seclists.org/oss-sec/2016/q4/118,
it says that this bug is introduced by commit fc0561cefc04 ("xfs: optimise away log forces on timestamp updates for fdatasync").
And in https://patchwork.kernel.org/patch/9363339/#19693745, david correction has nothing to do with this commit,
and is a page lock order bug in the XFS seek hole/data implementation(demsg is in http://people.redhat.com/qcai/tmp/dmesg-sync,
Unfortunately, it is not accessible now, I do not understand why this is a page lock order bug).

Is this CVE solved? Can I see the demsg in other way? thanks.

Re: Questions about CVE-2016-8660

[Dave Chinner]

On Thu, Mar 05, 2020 at 04:28:55PM +0800, zhengbin (A) wrote:
> Recently I am studying CVE-2016-8660, in https://seclists.org/oss-sec/2016/q4/118,

Why?

> it says that this bug is introduced by commit fc0561cefc04 ("xfs: optimise away log forces on timestamp updates for fdatasync").
> And in https://patchwork.kernel.org/patch/9363339/#19693745, david correction has nothing to do with this commit,

And if you read a little further down, I say:

| Why? This isn't a security issue - CVEs cost time and effort for
| everyone to track and follow and raising them for issues like this
| does not help anyone fix the actual problem.  It doesn't help us
| track it, analyse it, communicate with the bug reporter, test it or
| get the fix committed.  It's meaningless to the developers fixing
| the code, it's meaningless to users, and it's meaningless to most
| distros that are supporting XFS because the distro maintainers don't
| watch the CVE lists for XFS bugs they need to backport and fix.
| 
| All this does is artificially inflate the supposed importance of the
| bug. CVEs are for security or severe issues. This is neither serious
| or a security issue - please have the common courtesy to ask the
| people with the knowledge to make such a determination (i.e. the
| maintainers) before you waste the time of a /large number/ of people
| by raising a useless CVE...

And look, 4 years later this unnecessary CVE is still wasting
multiple peoples' valuable time.

> and is a page lock order bug in the XFS seek hole/data implementation(demsg is in http://people.redhat.com/qcai/tmp/dmesg-sync,
> Unfortunately, it is not accessible now, I do not understand why this is a page lock order bug).

the old XFS seek hole/data code did ilock -> page_lock, while
everything else in XFS (like readahead, writeback, etc) does
page_lock -> ilock.

> Is this CVE solved? Can I see the demsg in other way? thanks.

Yes. back in 2017 we completely rewrote the seek hole/data
implementation around the iomap infrastructure with
iomap_seek_hole and iomap_seek_data. These do not have a lock
inversion problem. commit 9b2970aacfd9 ("xfs: Switch
to iomap for SEEK_HOLE / SEEK_DATA") is the one that switched XFS,
but there are several more that introduce the infrastructure it
uses.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com