Bug 688698 - (CVE-2011-1159) CVE-2011-1159 acpid: blocked writes can lead to acpid daemon hang
CVE-2011-1159 acpid: blocked writes can lead to acpid daemon hang
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 701340
  Show dependency treegraph
Reported: 2011-03-17 14:33 EDT by Vincent Danen
Modified: 2015-08-19 05:08 EDT (History)
4 users (show)

See Also:
Fixed In Version: acpid 2.0.9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
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 Vincent Danen 2011-03-17 14:33:12 EDT
It was reported [1] that acpid opened the UNIX socket that informs unprivileged processes about acpi evens in blocking mode.  If an unprivileged process were to stop reading data from the socket, then after some time the socket queue fills up which would then lead to a hang of the privileged acpid daemon.  The daemon will hang until the socket peer process read some portion of the queued data or the peer process exits or is killed.

The reporter's solution is to open the socket in non-blocking mode:

--- a/acpid.c
+++ b/acpid.c
@@ -307,6 +307,7 @@
                        fcntl(cli_fd, F_SETFD, FD_CLOEXEC);
+                       fcntl(cli_fd, F_SETFL, O_NONBLOCK);
                        snprintf(buf, sizeof(buf)-1, "%d[%d:%d]",
                                creds.pid, creds.uid, creds.gid);
                        acpid_add_client(cli_fd, buf);

I can't tell if this was reported upstream or not; there are no recent bugs in the SourceForge bug tracker [2].

[1] http://www.openwall.com/lists/oss-security/2011/01/19/4
[2] http://sourceforge.net/tracker/?group_id=33140&atid=407341
Comment 1 Vincent Danen 2011-03-17 14:38:26 EDT
I've filed a bug for this because it has a CVE assigned, but I don't understand the problem.  If the problem is that acpid hangs if there are no unprivileged processes listening (as described) to the socket to keep the queue empty, then acpid would hang a lot.  Using lsof, I don't see anything but acpid opening /var/run/acpid.socket:

# lsof -U|grep acpi
acpid      1489      root    3u  unix 0xffff880137479a00      0t0  10297 socket
acpid      1489      root    8u  unix 0xffff880137479d40      0t0  10300 /var/run/acpid.socket
acpid      1489      root    9u  unix 0xffff8800bd6f5a00      0t0 138801 /var/run/acpid.socket

There is an exploit attached to the original report to demonstrate it, but by the sounds of things it requires 6-10hrs to trigger (on a laptop).  I'll give this a try with my Fedora 14-based laptop, but am I missing something here?  If the problem is as described, shouldn't acpid be hanging all the time, or is there something unprivileged that periodically polls the file?
Comment 2 Vincent Danen 2011-03-17 15:27:51 EDT
Ran the reproducer on my laptop, and it indeed stops counting when it hits 209 messages in the queue.  But acpid remains at 0% CPU usage.  I'm not sure what messages these are because acpi_listen isn't printing anything.  It's possible that acpid has "hung" and isn't writing anything to the socket until the backlog is cleared, but there is no extra CPU or memory usage as a result.  If I stop and restart acpid, while this reproducer is running, the count jumps way up and it's receiving way more than 209 messages (currently at 2,000,000 and counting).  But acpid is still at 0% CPU and 0% memory.

I honestly don't see what the problem here is.  Perhaps Jiri or someone else has some idea?  I'm also not sure what the reproducer is supposed to do other than tell you how many messages are in the queue.

Interestingly, nothing appears to me when running acpi_listen unprivileged until I also use it as root.  Once I do that, then the unprivileged acpi_listen starts to print acpi events.  When I quit the privileged acpi_listen, I still see new events on the unprivileged one.  The counter shown by the reproducer also doesn't reset (after unplugging and re-plugging in the power adapter, with a restarted acpid, I have been sitting at 36 messages in the queue, despite acpi_listen also listening (unprivileged).

Unless someone knows something, or can spot something, that I can't see, I would say this is a non-issue.  I'll keep this running for a bit to see if anything interesting happens later on perhaps.
Comment 6 Ted Felix 2011-04-29 18:40:28 EDT
I was able to reproduce a similar situation by writing a test program to simulate acpid, then connecting to it with the exploit.  So I believe the issue is valid.  Regardless, the suggested fix is harmless and makes sense.  I've made the fix in acpid 2.0.9 which can be found here:

Comment 7 Vincent Danen 2011-05-02 12:22:55 EDT
Thanks for that information, Ted.  We'll set this aside for something more urgent and fix it in the future (I don't believe this is severe enough to warrant an update on its own).  The feedback is appreciated.
Comment 8 Vincent Danen 2011-05-02 12:26:34 EDT
Created acpid tracking bugs for this issue

Affects: fedora-all [bug 701340]
Comment 9 Vincent Danen 2011-05-02 12:27:57 EDT

The Red Hat Security Response Team has rated this issue as having low security impact, a future update may address this flaw.

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