Bug 1939614 (CVE-2021-3468) - CVE-2021-3468 avahi: Local DoS by event-busy-loop from writing long lines to /run/avahi-daemon/socket
Summary: CVE-2021-3468 avahi: Local DoS by event-busy-loop from writing long lines to ...
Alias: CVE-2021-3468
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1944092 1946903 1946904 1946906 1939615 1944091 1946905
Blocks: 1939616 1943584
TreeView+ depends on / blocked
Reported: 2021-03-16 17:12 UTC by Pedro Sampaio
Modified: 2021-10-28 12:24 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in avahi. The event used to signal the termination of the client connection on the avahi Unix socket is not correctly handled in the client_work function, allowing a local attacker to trigger an infinite loop. The highest threat from this vulnerability is to the availability of the avahi service, which becomes unresponsive after this flaw is triggered.
Clone Of:
Last Closed: 2021-10-28 12:24:27 UTC

Attachments (Terms of Use)

Description Pedro Sampaio 2021-03-16 17:12:40 UTC
A flaw was found in avahi deamon. Denial of service can be triggered by writing long lines to /run/avahi-daemon/socket resulting in an unresponsive busy-loop of the daemon.



Comment 1 Pedro Sampaio 2021-03-16 17:13:10 UTC
Created avahi tracking bugs for this issue:

Affects: fedora-all [bug 1939615]

Comment 3 Riccardo Schirone 2021-03-26 10:07:10 UTC
The Avahi Unix socket is handled through a poll-like API, where an handler is called whenever one of the registered events triggers on one of the monitored file descriptors. Whenever the poll-like API returns, Avahi iterates over all monitored file descriptors and only calls the handler for the first file descriptor where an event has occurred. Then it calls poll again.

The server structure is initially configured to respond only to AVAHI_WATCH_IN event, so whenever a new connection is started on the Avahi socket, a new client structure is initialized and the client socket is added to the set of file descriptors monitored as well.

The problems seem to be several:
1) the client_work() function always expect a newline in the buffer and it won't process the data further until one is found;
2) there is no check to ensure that whenever the input buffer is full and a newline is not found, the connection shall be interrupted;
3) event AVAHI_WATCH_HUP, returned when the other end of the connection is terminated, is not handled in client_work() function;
4) event AVAHI_WATCH_IN is disabled when the input buffer becomes full.

Normally if a client closes the connection while avahi still expects input (thus the event AVAHI_WATCH_IN is handled), the read syscall would return an error and the client socket would be closed correctly.

However, if a client first fill the input buffer and then it terminates the connection, the AVAHI_WATCH_IN event would be disabled and the client_work() function would be called with only the event AVAHI_WATCH_HUP to handle.  client_work() function does not handle this event and it keeps the socket file descriptor open, thus the event keeps being returned by the kernel and client_work() functions is called again and again without changing anything, thus entering an infinite loop.

Comment 5 Riccardo Schirone 2021-03-26 11:16:38 UTC
Proposed patch upstream:

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