Bugzilla – Bug 995759
VUL-0: CVE-2015-8952: kernel: mbcache code subject to softlockup DOS in cache management
Last modified: 2020-06-29 06:25:51 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
bugbot adjusting priority
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.
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?
(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.
(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 ...
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?
As these are in LTSS, I concur and would leave it unfixed on those older products.
OK, closing the bug.
we are currently not planning to fix this issue.