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