[Bug 533] New: PANIC: divide by zero in xt_connbytes
bugzilla-daemon at bugzilla.netfilter.org
bugzilla-daemon at bugzilla.netfilter.org
Thu Jan 18 12:37:36 CET 2007
https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=533
Summary: PANIC: divide by zero in xt_connbytes
Product: netfilter/iptables
Version: linux-2.6.x
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: ip_tables (kernel)
AssignedTo: laforge at netfilter.org
ReportedBy: xkr47 at outerspace.dyndns.org
xt_connbytes supports matching by average packet size. It does so by
calculating bytes_so_far / packets_so_far. Sometimes it seems that
packets_so_far is 0, which causes a divide by zero and thus the kernel to
panic. The kernel has paniced some 8 times for me already. Most traffic don't
reach my iptables rules using xt_connbytes however so that's why it doesn't
crash all the time..
My & Hidden's (based on irc chat) views on when this can happen:
- packets whose checksum(s) mismatch are not accounted for, yet traverse the
rules
- connections that have seen packets only in one direction have packets=0 for
the other direction and connbytes supports matching also only in the other
direction
If the two views above turn out to be true this leads me to wonder that (unless
the conntrack refuses to track packets with bad checksums), could one crash
computers matching all incoming packets with the "avgpkt" mode of connbytes
simply by sending a SYN packet with bad IP or TCP checksum?
I've attached a patch based on hidden's comments on irc, it simply checks
against packets == 0 and in case it is, the average packet size is set to 0
instead of performing the division (by zero). The value of 0 seemed only
logical as "if no packets have been received for this connection in selected
direction yet, it would be fair to say the average packet size has been 0 so
far"
Hidden said this should maybe be considered for inclusion in the -
stable branch.
--
Configure bugmail: https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the netfilter-buglog
mailing list