Bug 995759 (CVE-2015-8952)

Summary:	VUL-0: CVE-2015-8952: kernel: mbcache code subject to softlockup DOS in cache management
Product:	[Novell Products] SUSE Security Incidents	Reporter:	Johannes Segitz <jsegitz>
Component:	Incidents	Assignee:	Security Team bot <security-team>
Status:	RESOLVED WONTFIX	QA Contact:	Security Team bot <security-team>
Severity:	Normal
Priority:	P3 - Medium	CC:	bpetkov, jack, meissner, mhocko, security-team, smash_bz, tiwai
Version:	unspecified
Target Milestone:	---
Hardware:	Other
OS:	Other
URL:	https://smash.suse.de/issue/172162/
Whiteboard:	CVSSv2:SUSE:CVE-2015-8952:4.6:(AV:L/AC:L/Au:S/C:N/I:N/A:C) maint:planned:update
Found By:	Security Response Team	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Johannes Segitz 2016-08-26 10:48:16 UTC

rh#1360968

A design flaw was found in the file extended attribute handling of the linux kernels handling of cached attributes.  Too many entries in the cache cause a soft lockup while attempting to iterate the cache and access relevant locks.

Upstream has replaced the mbcache code with an updated version which was not a patch but a clear-cut reimplentation of the code.

Probable fix:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=be0726d33cb8f411945884664924bed3cb8c70ee

References:
https://bugzilla.redhat.com/show_bug.cgi?id=1360968
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8952
http://seclists.org/oss-sec/2016/q3/378

Comment 1 Swamp Workflow Management 2016-08-26 22:00:22 UTC

bugbot adjusting priority

Comment 2 Takashi Iwai 2016-08-29 16:21:34 UTC

Adding Jan to Cc (although he is on vacation in this week).

FWIW, the commit mentioned in the report is already included in SLE12-SP2 and openSUSE-42.2.

Comment 3 Jan Kara 2016-09-15 14:50:43 UTC

The question is what we are going to do. I can just port the rewrite of mbcache code (probably we'd have to call it mbcache2 to keep the old kABI) and use it from ext2/3/4 but that seems like a too big change for older products. After all this problem is a DoS issue and nobody has hit the issue until recently (frankly, the only real workload hitting the problem was Ceph and one container framework) so there is a questionable value of backporting this to older products. So how much do we care about fixing this in SLE11 codebase? Or even in SLE10 SP4?

And is it OK to backport the rewrite to SLE12 and SLE12 SP1 kernels?

Comment 4 Johannes Segitz 2016-09-16 13:14:06 UTC

(In reply to Jan Kara from comment #3)
I'm very worried about this being triggered by some workload, I'm more worried about this being triggered maliciously. I understand the problem of keeping the kABI stable, but would still opt for porting this back to SLE 12/11. For SLE 10 I think we can skip it for now unless it's being requested specifically.

Comment 5 Johannes Segitz 2016-09-20 06:57:28 UTC

(In reply to Johannes Segitz from comment #4)
This should read:
"I'm *not* very worried about this being triggered by some workload"

Properly negating helps ...

Comment 6 Jan Kara 2019-03-14 10:16:30 UTC

So far no customer asked for a fix of this softlockup possibility for SLE11-SP4 or SLE12, SLE12-SP1 kernels. So I'd just close this. If there's explicit request for handling this issue in the old kernels, we can probably cook up some hack to just silence the softlockup instead of backporting full mbcache rewrite. Thoughts?

Comment 7 Marcus Meissner 2019-03-14 10:33:20 UTC

As these are in LTSS, I concur and would leave it unfixed on those older products.

Comment 8 Jan Kara 2019-03-14 14:25:49 UTC

OK, closing the bug.

Comment 10 Marcus Meissner 2019-07-11 05:03:31 UTC

we are currently not planning to fix this issue.