Bug 656756 - (CVE-2010-4249) CVE-2010-4249 kernel: unix socket local dos
CVE-2010-4249 kernel: unix socket local dos
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 656757 656758 656759 656760 656761 656762 656763
  Show dependency treegraph
Reported: 2010-11-23 21:55 EST by Eugene Teo (Security Response)
Modified: 2018-02-12 16:39 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-03-28 04:58:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eugene Teo (Security Response) 2010-11-23 21:55:43 EST

Reported by Vegard Nossum:
"I found this program lying around on my laptop. It kills my box (2.6.35) instantly by consuming a lot of memory (allocated by the kernel, so the process doesn't get killed by the OOM killer). As far as I can tell, the memory isn't being freed when the program exits either. Maybe it will eventually get cleaned up the UNIX socket garbage collector thing, but in that case it doesn't get called quickly enough to save my machine at least."

Reproducer: http://lkml.org/lkml/2010/11/23/395
Partial fix: http://lkml.org/lkml/2010/11/23/450
Remaining fix: http://marc.info/?l=linux-netdev&m=129059035929046&w=2

From Eric Dumazet:
"we can eat all LOWMEM memory before unix_gc() being called from unix_release_sock(). Moreover, the thread blocked in unix_gc() can consume huge amount of time to perform cleanup because of huge working set.

One way to handle this is to have a sensible limit on unix_tot_inflight, tested from wait_for_unix_gc() and to force a call to unix_gc() if this limit is hit.

This solves the OOM and also reduce overall latencies, and should not slowdown normal workloads."


Red Hat would like to thank Vegard Nossum for reporting this issue.
Comment 5 Neil Horman 2010-11-29 12:47:41 EST
Note that9915672d41273f5b77f1b3c29b391ffb7732b84b is only part of the solution.  We also need bba14de98753cb6599a2dae0e520714b2153522d from net-next.
Comment 6 errata-xmlrpc 2011-01-11 14:45:53 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:0007 https://rhn.redhat.com/errata/RHSA-2011-0007.html
Comment 7 errata-xmlrpc 2011-01-18 12:45:30 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2011:0162 https://rhn.redhat.com/errata/RHSA-2011-0162.html
Comment 8 errata-xmlrpc 2011-03-01 15:29:34 EST
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2011:0303 https://rhn.redhat.com/errata/RHSA-2011-0303.html
Comment 9 errata-xmlrpc 2011-03-10 15:04:44 EST
This issue has been addressed in following products:

  MRG for RHEL-5

Via RHSA-2011:0330 https://rhn.redhat.com/errata/RHSA-2011-0330.html
Comment 10 Eugene Teo (Security Response) 2011-06-28 03:53:06 EDT
Upstream commits:
CVE-2010-4249.01 9915672d41273f5b77f1b3c29b391ffb7732b84b
CVE-2010-4249.02 bba14de98753cb6599a2dae0e520714b2153522d
CVE-2010-4249.03 25888e30319f8896fc656fc68643e6a078263060

Note You need to log in before you can comment on or make changes to this bug.