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: IncidentsAssignee: 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

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:

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.