[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#654876: "divide error" while receiving from iwlagn 5300, leading to kernel panic



On Mon, 09 Jan 2012 at 00:53:26 +0000, Simon McVittie wrote:
> Via netconsole, I can bring you the attached logs (three separate bug/panic
> sequences).

>From the crash dump, I think this may be to do with IGMP. It started
around the time I added a Playstation 3 (which I believe uses multicast for
UPnP media sharing) to my network, although correlation doesn't imply
causation... I haven't been able to reproduce the crash with wired-only
networking, though, which seems strange if it's independent of the device.

The instruction pointer in the crash dump is in igmp_start_timer(), which
performs a modulus operation. If max_delay is 0 I believe that will cause
a divide error.

In igmp_heard_query() there are several cases, depending on the version of
IGMP in use.

If ih->code is 0 (IGMP v1), max_delay is set nonzero.

If it's IGMP v2, max_delay could conceivably be nonzero if there's an
overflow or something? It's calculated from data in the network packet.

If it's IGMP v3 and v2 queries have been seen, max_delay could, again,
conceivably be nozero?

In the v3 case, max_delay is explicitly clamped at 1 after a similar
calculation, suggesting that this should be done in the other cases too.

At the end of the function (in all cases except v3), igmp_mod_timer() is
called with max_delay; perhaps clamping it at 1 there, or even in
igmp_start_timer(), would fix this?

Does this make sense? If so, I can can create a simple patch and try it out
for a while.

    S



Reply to: