Bugzilla – Bug 741553
VUL-1: CVE-2011-4609: glibc: svc_run() produces high cpu usage when accept() fails with EMFILE error
Last modified: 2014-09-15 07:30:39 UTC
It was reported that if a process that called glibc's svc_run() exceeded the limit of opened files for a longer period of time, that accept() in rendezvous_request()/svcudp_recv() would fail with the EMFILE error, which would lead to looping between poll(), accept(), and 'for' loops which would consume a lot of CPU time. This could lead to an unresponsive system that requires human intervention (service restart or system restart) to resolve.
So, don't do that then.
don't do what? use glibc interfaces? Not a solution. The issue has low severity but we should include a fix in future updates nevertheless.
Don't exceed the open file limits for an extended period of time. If processes are always working near the limits there's _bound_ to be all kinds of problems, including resource starvation. I don't see at all how only glibc has such problem, it lurks everywhere. It's a systematic problem and I don't see how changing one instance (what would be your proposal btw? NB: it should not negatively affect non-stupid processes at all) is any good. But if you have a patch, sure, I'm not going to work on it.
Removing the private flag on last comments, I didn't set it consciously.
https://bugzilla.redhat.com/show_bug.cgi?id=767299 has a patch
That's silly. It checks for EMFILE and sleeps a bit (exactly what I thought a proposed "fix" would do). What about ENFILE, ENOMEM, ECONNABORTED and the other cases an accept might fail for process or system limits? It patches places that can't fail with EMFILE at all (recvfrom). The patch obviously is thrown together without much thinking, and I doubt it has a chance of getting upstream. I'm not going to include anything like that. This CVE number (2011-4609) is still in "reserved" state without any discussion track or description. Why am I even wasting my time with this?
I'm guessing it's better to postpone this to the next update, right? At least then we will know what upstream decided to do with this problem.
(In reply to comment #7) > I'm guessing it's better to postpone this to the next update, right? At least > then we will know what upstream decided to do with this problem. I agree. We should not include "silly" patches. :)
also a bug for andreas to cross check against upstream
Setting NEEDINFO accordingly.
What info do you need?
(In reply to comment #11) > What info do you need? If this is fixed upstream now. We are preparing a glibc update for SLE11 SP2 and SP3 and checking which fixes should go in. Would be nice if it could be clarified this week if the fix for this bug can be part of it. Sorry, for needlessly setting NEEDINFO
The SWAMPID for this issue is 54298. This issue was rated as low. Please submit fixed packages until 2013-09-26. Also create a patchinfo file using this link: https://swamp.suse.de/webswamp/wf/54298
redhat patch does not look very sensible, it waits and fails afterwards 2.19 does not have a fix either. I would currently defer and not fix this.