Package: cups
Version: 1.4.7-1
Tags: patch
If cups-polld runs into a network error after connecting to a remote IPP
server while polling, it will wind up in an endless loop using 100% CPU.
This can be quickly tested using the following procedure:
1. Configure cups with BrowsePoll to poll a remote server
2. Use strace on the cups-polld instance for the remote server
3. Use iptables to block responses from the server, e.g.
iptables -I INPUT 1 -p tcp -s 192.2.0.2 --sport ipp -j REJECT
--reject-with tcp-reset
4. Wait for the strace to show that cups-polld is blocking in recvfrom
5. Use iptables to send RST on packets to the server, e.g.
iptables -I OUTPUT 1 -p tcp -d 192.2.0.2 --dport ipp -j REJECT
--reject-with tcp-reset
6. Wait until TCP decides it has waited too long for an ACK and
resends the packet.
7. Observe that the recvfrom now fails with ECONNRESET, and then
strace outputs lines like the following until the process is killed:
recvfrom(6, "", 2048, 0, NULL, NULL) = 0
Note that step 5 may be skipped, in which case you have to wait until
the TCP connection times out in step 6. In the wild, this sort of
situation may occur if the machine is suspended or if the network
connection goes down at the wrong time.
This appears to be the same as
https://bugzilla.redhat.com/show_bug.cgi?id=720921, and the patch
extracted from
http://pkgs.fedoraproject.org/gitweb/?p=cups.git;a=commitdiff;h=a8d53773cf4e1014d4fbb065ab6f0ea480184de9
seems to work. I've attached the actual patch to this message, which
should be importable with quilt import -p1.
--- a/cups/request.c
+++ b/cups/request.c
@@ -395,7 +395,7 @@
{
status = httpUpdate(http);
}
- while (http->state == HTTP_POST_RECV);
+ while (status != HTTP_ERROR && http->state == HTTP_POST_RECV);
DEBUG_printf(("2cupsGetResponse: status=%d", status));
