ip_rcv_finish() NULL pointer kernel panic
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Medium
|
Dan Streetman | ||
Trusty |
Invalid
|
Medium
|
Unassigned | ||
Xenial |
Fix Released
|
Medium
|
Dan Streetman | ||
Yakkety |
Fix Released
|
Medium
|
Dan Streetman | ||
Zesty |
Fix Released
|
Medium
|
Dan Streetman |
Bug Description
[Impact]
When using iptables rules affecting bridge traffic, and if affected traffic is flowing through bridge while br_netfilter module is loaded or unloaded, a kernel panic may occur.
[Test Case]
It's difficult to reproduce because of a very small race condition window during br_netfilter load/unload when the module is receiving traffic but has not yet registered its hooks (or, has unregistered its hooks but still has traffic it's processing). A system must be set up using a bridge, and iptable netfilter rules must be set up to process the bridge traffic. Then the system should be rebooted until the problem occurs, or the br_netfilter module should be loaded/unloaded until the problem occurs.
[Regression Potential]
Changing how the br_netfilter module switches its fake dst for a real dst may, if done incorrectly, result in more kernel panics if other code tries to process the br_netfilter module's fake dst.
[Other Info]
The br_netfilter module processes packets traveling through its bridge, and while processing each skb it places a special fake dst onto the skb. When the skb leaves the bridge, it removes the fake dst and places a real dst onto it. However, it uses a hook to do this, and when the br_netfilter module is unloading it unregisters that hook. Any skbs that are currently being processed in the bridge by the br_netfilter module, but that leave the bridge after the hook is unregistered (or, during br_netfilter module load, before the hook is registered) will still have the fake dst; when other code then tries to process that dst, it causes a kernel panic because the dst is invalid.
Recent upstream discussion:
https:/
Upstream patch:
https:/
upstream commit is a13b2082ece9524
example panic report:
[ 214.518262] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 214.612199] IP: [< (null)>] (null)
[ 214.672744] PGD 0 [ 214.696887] Oops: 0010 [#1] SMP [ 214.735697] Modules linked in: br_netfilter(+) tun 8021q bridge stp llc bonding iTCO_wdt iTCO_vendor_support tpm_tis tpm kvm_intel kvm irqbypass sb_edac edac_core ixgbe mdio ipmi_si ipmi_msghandler lpc_ich mfd_core mousedev evdev igb dca procmemro(O) nokeyctl(O) noptrace(O)
[ 215.029240] CPU: 34 PID: 0 Comm: swapper/34 Tainted: G O 4.4.39 #1
[ 215.116720] Hardware name: Cisco Systems Inc UCSC-C220-
[ 215.241644] task: ffff882038fb4380 ti: ffff8810392b0000 task.ti: ffff8810392b0000
[ 215.331207] RIP: 0010:[<
[ 215.420877] RSP: 0018:ffff88103f
[ 215.484436] RAX: ffff881011631000 RBX: ffff881011067100 RCX: 0000000000000000
[ 215.569836] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff881011067100
[ 215.655234] RBP: ffff88103fec38a8 R08: 0000000000000008 R09: ffff8810116300a0
[ 215.740629] R10: 0000000000000000 R11: 0000000000000000 R12: ffff881018917dce
[ 215.826030] R13: ffffffff81c9be00 R14: ffffffff81c9be00 R15: ffff881011630078
[ 215.911432] FS: 000000000000000
[ 216.008274] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 216.077032] CR2: 0000000000000000 CR3: 0000001011b9d000 CR4: 00000000001406e0
[ 216.162430] Stack:
[ 216.186461] ffffffff8157d7f9 ffff881011067100 ffff881018917dce ffff881011630000
[ 216.275407] ffffffff81c9be00 ffff88103fec3918 ffffffff8157e0db 0000000000000000
[ 216.364352] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 216.453301] Call Trace:
[ 216.482536] <IRQ> [ 216.505533] [<ffffffff8157d
[ 216.575442] [<ffffffff8157e
[ 216.634842] [<ffffffff81540
[ 216.712965] [<ffffffff81541
[ 216.783801] [<ffffffff81541
[ 216.861921] [<ffffffff81541
[ 216.930686] [<ffffffffa02f6
[ 217.016091] [<ffffffff81187
[ 217.084849] [<ffffffffa0584
[ 217.178568] [<ffffffffa0584
[ 217.266052] [<ffffffffa02f6
[ 217.351450] [<ffffffffa0584
[ 217.437891] [<ffffffff81572
[ 217.499367] [<ffffffff81572
[ 217.562928] [<ffffffffa02f6
[ 217.641048] [<ffffffffa02f6
[ 217.726446] [<ffffffff81540
[ 217.804566] [<ffffffff815a7
[ 217.876445] [<ffffffff815b7
[ 217.948322] [<ffffffff81541
[ 218.019161] [<ffffffff81541
[ 218.097281] [<ffffffff81542
[ 218.166051] [<ffffffffa00a8
[ 218.246255] [<ffffffffa00a9
[ 218.318131] [<ffffffff81541
[ 218.384813] [<ffffffff8109c
[ 218.463973] [<ffffffff8105c
[ 218.529608] [<ffffffff8105c
[ 218.589007] [<ffffffff816dd
[ 218.646323] [<ffffffff816db
Changed in linux (Ubuntu): | |
assignee: | nobody → Dan Streetman (ddstreet) |
importance: | Undecided → Medium |
status: | New → In Progress |
tags: | added: sts |
Changed in linux (Ubuntu Yakkety): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Vivid): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Trusty): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Yakkety): | |
status: | New → Confirmed |
Changed in linux (Ubuntu Xenial): | |
status: | New → Confirmed |
Changed in linux (Ubuntu Vivid): | |
status: | New → Confirmed |
Changed in linux (Ubuntu Trusty): | |
status: | New → Confirmed |
no longer affects: | linux (Ubuntu Vivid) |
description: | updated |
Changed in linux (Ubuntu Zesty): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Xenial): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Yakkety): | |
status: | In Progress → Fix Committed |
I verified the Trusty kernel isn't affected, this only applies to Xenial and later.