In message <H8GMHy.BnE@tac.nyc.ny.us>Christos Zoulas writes
>In article <Pine.NEB.4.44.0301091019210.4462-100000@haiku.jarai.net>,
>Brian Chase <vaxzilla@jarai.org> wrote:
>>The CERT site lists the status of NetBSD's drivers with respect to this
>>vulnerablity as "unknown".  Does anyone know whether our ethernet
>>drivers suffer from the the listed vulnerability?
>>
>>  http://www.kb.cert.org/vuls/id/412115
>>
>>The above url details the problem.
>
>For most modern chips this is a non-issue because they do automatic
>padding (now what they pad with, god knows; I hope it is zeros)...
>For the most popular vintage chips (eg. lance) we pad zeros manually.
>There are others that might be broken (3c501).

I suspect the real issue here is that Linux kernels, when generating
ICM errors, always returned some minimum number of bytes of original
IP data --- in some cases, more bytes than the incoming datagram which
triggered the ICMP message. The resulting datagram was larger than
ETHERMIN, in which case padding isn't the problem per se: the
prior contents of physical memory of the linux skb (quite possibly
sensitive data) ended up in the outbound ICMP message.
We don't do _that_ (or didn't, when I looked last year).

If theres concern, we could add a sysctl'able option to make
ether_output() explicitly pad runts with zeros, out to ETHERMIN.