Steps to reproduce skb_over_panic kernel panic (fakelb/6lowpan)
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.

Fix available!

Alexander Aring created two patches that fix this problem.

Details can be found here:


Steps to reproduce "skb_over_panic" kernel panic when sending a simple UDP packet over a 6lowpan interface (using fakelb).

Verified with the following kernels:

  • Linux version 4.9.0-0.bpo.2-amd64 ( (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.9.13-1~bpo8+1 (2017-02-27) (x86_64)
  • Linux version 4.10.4-1-ARCH (builduser@tobias) (gcc version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Sat Mar 18 19:39:18 CET 2017 (x86_64)
  • Linux version 4.10.5-1-ARCH (builduser@tobias) (gcc version 6.3.1 20170306 (GCC) ) #1 SMP PREEMPT Wed Mar 22 14:42:03 CET 2017 (x86_64)

Note: Could not reproduce it with 32-bit architectures!

Works fine on Debian with the following kernel:

  • Linux version 4.9.0-0.bpo.2-686 ( (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.9.13-1~bpo8+1 (2017-02-27) (i686)

Works fine on a Raspberry Pi 3, running Arch Linux ARM (32&64bit), with any of the following kernels:

Setup WPAN network with two interfaces

As root run (root permissions are needed for loading/removing the fakelb module):


This script will try to remove the fakelb module, load it with two lbs (wpan0 and wpan1), and create two namespaces for each lb (again wpan0 and wpan1), adding a lowpan link (lowpan0 and lowpan1) with the IP addresses b:1::1 and b:1::2 .

Ping interfaces (optional)

./test_ping b:1::1 (or b:1::2)

Trigger skb_over_panic with a ping

ip netns exec wpan0 ping6 -s 39 b:1::2


ip netns exec wpan1 ping6 -s 39 b:1::1

Send UDP packet to trigger skb_over_panic

This command should be run by a user with permissions to manage namespaces, but the actual sending of the UDP packets does not require any special privileges:

ip netns exec wpan0 runuser -l user -c "python ./"

or simply:

ip netns exec wpan0 "python ./"

Kernel dump screenshot:

Kernel Dump

Odd note (MAC CTRL packets)

I can't explain this but, when SSHing real hardware and making it fail with the above setup, connectivity is lost on all machines connected to the same hub. Looking deeper into the matter, a tcpdump revealed the generation of MAC CTRL packets looking like this:

[no.]	[time]	[source]	Spanning-tree-(for-bridges)_01	MAC CTRL	60	Pause: pause_time: 65535 quanta