Bugzilla – Bug 928128
VUL-1: CVE-2014-8171: kernel: memcg: OOM handling DoS
Last modified: 2017-09-20 14:48:52 UTC
A local DoS Via rh#1198109 It was found that the Linux kernel memory resource controller's (memcg) handling of OOM (out of memory) conditions could lead to deadlocks. An attacker able to continuously spawn new processes within a single memory-constrained cgroup during an OOM event could use this flaw to lock up the system. (or) On a system with memory-constrained cgroups, it is possible for a non-root user to lock up the system by continuously spawning new processes within a cgroup which is already in an OOM event. Upstream patches: The deadlock was inherent in the original memcg OOM killer design, so the entire rewrite of that mechanism is required for the fix: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id= 759496ba6407c6994d6a5ce3a5e74937d7816208 3a13c4d761b4b979ba8767f42345fed3274991b0 519e52473ebe9db5cdef44670d5a97f1fd53d721 fb2a6fc56be66c169f8b80e07ed999ba453a2db2 3812c8c8f3953921ef18544110dafc3505c1ac62 4942642080ea82d99ab5b653abb9a12b7ba31f4a 84235de394d9775bfaa7fa9762a59d91fef0c1fc a0d8b00a3381f9d75764b3377590451cb0b4fe41 1f14c1ac19aa45118054b6d5425873c5c7fc23a1 3168ecbe1c04ec3feb7cb42388a17d7f047fe1a2 References: https://bugzilla.redhat.com/show_bug.cgi?id=1198109 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8171 https://rhn.redhat.com/errata/RHSA-2015-0864.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8171 Looks like this affects SLE 11 kernels.
bugbot adjusting priority
(In reply to Andreas Stieger from comment #0) > A local DoS Via rh#1198109 > > It was found that the Linux kernel memory resource controller's (memcg) > handling of OOM (out of memory) conditions could lead to deadlocks. An > attacker able to continuously spawn new processes within a single > memory-constrained cgroup during an OOM event could use this flaw to lock up > the system. To be honest I consider this a bogus report. I am very well aware of the issue here, which has barely anything to do with spawning new processes. The deadlock could happen if a task which triggered memcg OOM due to a memcg charge could be holding a lock (e.g. i_mutex) and the OOM victim could be blocked on the very same mutex. This alone is not nice because all the charges would block in that memcg but DoSing within a memcg is acceptable (if for nothing else the DoS is local to the group). The _only_ problem here is that the same i_mutex (same inode) might be needed from another memcg. This is bad but not unrecoverable. Admin can still temporarily increase the limit of the locked up group and the deadlock would be resolved. That being said. The issue is not ideal but I do not think it deserves a CVE. The deadlock is recoverable by an administrator. Considering how much code is needed for this to be fixed and low impact I would be reluctant to backport it to SLE branches. What do you think Marcus?
At this time I would also not want to backport this as it has a too high risk of breakage. I was also thinking of disputing the CVE allocation, but its still to some degree even if minor an issues.
(In reply to Marcus Meissner from comment #4) > At this time I would also not want to backport this as it has a too high > risk of breakage. FWIW, I've forgot to mention that the patchset also changes the semantic of the memcg oom killer. Only the page fault is triggering the OOM killer now. This means that a large class of syscalls will return with ENOMEM rather than a task would get killed (some do not do even that e.g. mmap(MAP_LOCKED) as can be seen in bug 912939. I do not think this is necessarily a bad behavior but such a change is not something for a maint. update for sure. So I guess we should go with WONTFIX here?
I would go with WONTFIX, and post some form of a note to our CVE pages.
(In reply to Marcus Meissner from comment #6) > I would go with WONTFIX, and post some form of a note to our CVE pages. Do you want me to put something together or you are able to extract that from my previous comments?
Is this fine? "This issue affects SUSE Linux Enterprise 11 kernels. It is however an attack that requires constant attacker work to be persistant and can be resolved by an administrator. As it is a difficult fix to backport and also changes API semantics, we will not fix this issue for SUSE Linux Enterprise 11 at this time."
(In reply to Marcus Meissner from comment #8) > Is this fine? > > "This issue affects SUSE Linux Enterprise 11 kernels. It is however an > attack that requires constant attacker work to be persistant and can be > resolved by an administrator. As it is a difficult fix to backport and also > changes API semantics, we will not fix this issue for SUSE Linux Enterprise > 11 at this time." OK.
It seems kernel work is done here, reassigning back to sec-team.
lets close