Created attachment 2243 [details] Fix for dns issue. This can be replicated on squid 3.1.6,using the domain name http://big.nbgold.net/ (this domain is just something I threw in our DNS config to test, it doesn't go anywhere useful, and responds with >512 bytes of data). Assertion is: 2010/08/19 13:57:22.013| assertion failed: comm_epoll.cc:142: "fd >= 0" dns_internal.cc will get a TC flag from the server because the response would be >512, and will try to query over TCP instead of UDP. Squid starts the TCP connection, and then erroneously thinks that it is sending an ipv6 dns query, and will fall over. This is the backtrace: #0 0x009ea206 in raise () from /lib/libc.so.6 #1 0x009ebbd1 in abort () from /lib/libc.so.6 #2 0x001824bc in xassert (msg=0x2df6ff "fd >= 0", file=0x2dc676 "comm_epoll.cc", line=142) at debug.cc:556 #3 0x00180123 in commSetSelect (fd=-1, type=1, handler=0x1949b0 <idnsRead>, client_data=0x0, timeout=0) at comm_epoll.cc:142 #4 0x001924bf in idnsSendQuery (q=0x9d96820) at dns_internal.cc:837 #5 0x001936bf in idnsGrokReply (buf=0x376b00 "D-\203\200", sz=512) at dns_internal.cc:981 #6 0x00194bac in idnsRead (fd=7, data=0x0) at dns_internal.cc:1187 #7 0x00180344 in comm_select (msec=290) at comm_epoll.cc:307 #8 0x002500ed in CommSelectEngine::checkEvents (this=0xbfdbfe64, timeout=290) at comm.cc:2686 #9 0x0019ae02 in EventLoop::checkEngine (this=0xbfdbfe30, engine=0xbfdbfe64, primary=true) at EventLoop.cc:50 #10 0x0019af9c in EventLoop::runOnce (this=0xbfdbfe30) at EventLoop.cc:124 #11 0x0019b0aa in EventLoop::run (this=0xbfdbfe30) at EventLoop.cc:94 #12 0x001ee711 in SquidMain (argc=3, argv=0xbfdbff44) at main.cc:1407 #13 0x001eee55 in main (argc=1717532517, argv=0x656c69) at main.cc:1163 in #4 0x001924bf in idnsSendQuery (q=0x9d96820) at dns_internal.cc:837, y = 0, x = 0, DnsSocketB = -1. This patch seems to fix the problem, we are testing it internally here:
Patch looks right. Thank you. This one is quite serious. How fast can this be confirmed not to introduce any other problems?
Its passed our tests so far, will be putting it on a major site overnight, so 24 hours or so and I'll be confident that it doesn't cause other problems. May also be the cause of 3009, I've made a note there.
I haven't seen any problems since applying this patch, I reckon it's good to go.
Thanks applied.
*** Bug 3009 has been marked as a duplicate of this bug. ***
*** Bug 3030 has been marked as a duplicate of this bug. ***
Would we consider this as a security issue, since its user who does not have "admin" access to the squid server causing it to crash?
It's a very noticeable bug. Squid versions having this bug will randomly crash in normal usage and do not need any malicious users to trigger the issue just noral users trying to browse some of the bigger wwebsites. So no I would not consider it being a securitu issue, only a major stability issue.
This is reported in CVE-2010-2951 and on redhat's bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=626927 As I recall, this only affected squid 3.1.5.1 and 3.1.6, not any later releases, and it was only affecting fedora for a short period of time.