ping -s2955 1.2.3.4 or
ping -s1455 1.2.3.4 causes kernel panic
It's my guess that this is due to a magic MTU of 1500 which
the packet just barely exceeds, resulting in only three
bytes of data (one octet) in the last frag.
Here is a sample of what I believe is a "death fragment"
4500 0017 027A 0172 FF01 A7E6 0102 0304 0506 0708 FFFF FF
ping -s32739 127.0.0.1
should reproduce the problem, but the local loopback seems
to assiduously avoid creating this "death fragment".
Possibly by playing with its MTU??
Thankfully this bug does NOT appear to be remotely exploitable.
My kernel happily accepts and replies to packets it dies
trying to origionate itself.
I have second hand confirmation that this problem exists
under netbsd as well, and that freebsd may be immune.
Any confirmation either way would be welcomed.
The openbsd people are aware of the problem, and irc
notwithstanding, are working on it. :)
Fix: 1: chmod a-s /usr/sbin/traceroute /sbin/ping
2: avoid goofing around with home made
packet fraggers