* Questions about CVE-2016-8660
@ 2020-03-05 8:30 zhengbin (A)
0 siblings, 0 replies; 3+ messages in thread
From: zhengbin (A) @ 2020-03-05 8:30 UTC (permalink / raw)
To: Dave Chinner, Darrick J. Wong, linux-xfs; +Cc: yi.zhang
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.
^ permalink raw reply [flat|nested] 3+ messages in thread* Questions about CVE-2016-8660
@ 2020-03-05 8:28 zhengbin (A)
2020-03-05 21:27 ` Dave Chinner
0 siblings, 1 reply; 3+ messages in thread
From: zhengbin (A) @ 2020-03-05 8:28 UTC (permalink / raw)
To: Dave Chinner, Darrick J. Wong, linux-xfs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Questions about CVE-2016-8660
2020-03-05 8:28 zhengbin (A)
@ 2020-03-05 21:27 ` Dave Chinner
0 siblings, 0 replies; 3+ messages in thread
From: Dave Chinner @ 2020-03-05 21:27 UTC (permalink / raw)
To: zhengbin (A); +Cc: Darrick J. Wong, linux-xfs
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-03-05 21:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-03-05 8:30 Questions about CVE-2016-8660 zhengbin (A)
-- strict thread matches above, loose matches on Subject: below --
2020-03-05 8:28 zhengbin (A)
2020-03-05 21:27 ` Dave Chinner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox