Bug 1384851 (CVE-2016-8660)

Summary:	CVE-2016-8660 kernel: xfs: local DoS due to a page lock order bug in the XFS seek hole/data implementation
Product:	[Other] Security Response	Reporter:	Andrej Nemec <anemec>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	agordeev, aquini, arm-mgr, bhu, carnil, dhoward, esammons, fhrbata, gansalmon, iboverma, ichavero, itamar, jforbes, jkacur, joelsmith, jonathan, jross, jwboyer, kernel-maint, kernel-mgr, labbott, lgoncalv, lwang, madhu.chinakonda, matt, mchehab, mcressma, mguzik, nmurray, pholasek, plougher, rt-maint, rvrbovsk, security-response-team, vdronov, williams, yjog
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:	The XFS subsystem in the Linux kernel 4.4 and later allows local users to cause a denial of service (fdatasync() failure and system hang) by using the vfs syscall group in the 'trinity' program, as a result of a page lock order bug in the XFS seek hole/data implementation.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-02 17:50:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1384852
Bug Blocks:	1384853

Description Andrej Nemec 2016-10-14 09:30:19 UTC

The XFS subsystem in the Linux kernel 4.4 and later allows local users to cause a denial of service (fdatasync failure and system hang) by using the vfs syscall group in the 'trinity' program, as a result of a page lock order bug in the XFS seek hole/data implementation.

References:

http://seclists.org/oss-sec/2016/q4/118

Introducing commit:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fc0561cefc04e7803c0f6501ca4f310a502f65b8

Conditions:

Per the reporter, the 'trinity' program should be run in a container on xfs filesystem as a storage, for example with 'docker' with 'overlay2' or 'devicemapper' with LVM thin pool as a storage engine.

http://www.spinics.net/lists/linux-xfs/msg01365.html

http://www.spinics.net/lists/linux-xfs/msg01372.html

Comment 1 Andrej Nemec 2016-10-14 09:31:08 UTC

Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1384852]

Comment 4 Vladis Dronov 2016-11-02 17:38:17 UTC

Statement:

This issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 5, 6, 7 and MRG-2 as the code with the flaw is not present in the products listed.

Comment 5 Salvatore Bonaccorso 2018-02-25 16:21:26 UTC

Hi

Any idea if this issue has been fixed upstream? If so where?

Regards,
Salvatore

Comment 7 Vladis Dronov 2018-02-26 12:11:10 UTC

hello, Salvatore,

unfortunately, we are not aware of such a fix.

i've searched upstream's git-log for something like "Fixes: fc0561ce" or "CVE-2016-8660" but unfortunately/expectedly have not found anything.

http://seclists.org/oss-sec/2016/q4/118 says:

> This had also been reported to the XFS maintainer and diagnosed as
> a page lock order bug in the XFS seek hole/data implementation and
> presumably is still working on a fix better than to revert the above commit.

so i guess this thread is a proper place to check. unfortunately, i cannot find any message mentioning "fc0561cef" in linux-xfs@.

Comment 8 Vladis Dronov 2018-02-26 12:18:50 UTC

hello, Salvatore,

(god bless marc.info) the thread in question is:

https://marc.info/?t=147560293400001&r=1&w=2

or:

https://www.spinics.net/lists/linux-xfs/msg01367.html

https://www.spinics.net/lists/linux-xfs/msg01365.html