A partner reported that frames with priority tags only (VID=0 in the frame), could cause a panic on some drivers. The backtrace would look like this: Pid: 0, comm: swapper Not tainted 2.6.32-197.el6 RIP: 0010:[<ffffffff814c6b46>] [<ffffffff814c6b46>] vlan_hwaccel_do_receive+0x7 6/0x110 RSP: 0018:ffff880028203c30 EFLAGS: 00010283 RAX: ffff10015867e7b0 RBX: ffff88012e69c8c0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88012e69c8c0 RDI: ffff88012e69c8c0 RBP: ffff880028203c50 R08: 0000000000000001 R09: 0000000000000008 R10: 0000000000000001 R11: 0000000000000000 R12: ffff88013047e6e0 R13: ffff88013047e020 R14: ffff88012c893010 R15: ffffc900127dd028 FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 000000364a4abd60 CR3: 000000012b417000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffffffff81a00000, task ffffffff81a8d020) Stack: ffff880028203d60 ffff88012e69c8c0 ffff880129efb258 ffff8801337a9800 <0> ffff880028203cb0 ffffffff8142b558 0101880028203c90 0000000000000000 <0> ffffffff00000000 ffff88002820f560 0000000028203c90 ffff88012e69c8c0 Call Trace: <IRQ> [<ffffffff8142b558>] __netif_receive_skb+0x4b8/0x6e0 [<ffffffff8142d5d8>] netif_receive_skb+0x58/0x60 [<ffffffff8142d6e0>] napi_skb_finish+0x50/0x70 [<ffffffff814c7244>] vlan_gro_receive+0x84/0xa0 [<ffffffffa030dd0b>] igb_poll+0x88b/0xe70 [igb] [<ffffffff810de607>] ? cpu_quiet_msk+0x77/0x130 [<ffffffff8142fe83>] net_rx_action+0x103/0x2f0 [<ffffffff81072101>] __do_softirq+0xc1/0x1d0 [<ffffffff810d9410>] ? handle_IRQ_event+0x60/0x170 [<ffffffff8100c20c>] call_softirq+0x1c/0x30 [<ffffffff8100de45>] do_softirq+0x65/0xa0 [<ffffffff81071ee5>] irq_exit+0x85/0x90 [<ffffffff814f4245>] do_IRQ+0x75/0xf0 [<ffffffff8100ba13>] ret_from_intr+0x0/0x11 The partner provided a patch to demonstrate the fix, but it was a bit more complex than what we really needed and had a bug. Andy worked to create something a bit smaller and am pleased with the outcome. This code is modeled after the code that is currently upstream in vlan_do_receive. If skb->dev is not a valid VLAN interface, then we can stop processing and return control to __netif_receive_skb. We also set skb->pkt_type = PACKET_OTHERHOST so the frame is dropped in the stack quickly. Andy has tested this patch and confirmed that the panic is prevented and everything else works as expected. Sending frames with only a priority tag results in the frames being dropped (if a device with VID 0 is not created on the host), and he also did a packet capture and noted that priority tagged frames are properly displayed with tcpdump/wireshark. Acknowledgements: Red Hat would like to thank Gideon Naim for reporting this issue.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:1465 https://rhn.redhat.com/errata/RHSA-2011-1465.html
Statement: This issue did not affect the Linux kernels as shipped with Red Hat Enterprise Linux 4, 5, and Red Hat Enterprise MRG. It affects the Linux kernel as shipped with Red Hat Enterprise Linux 6 due to incorrect backporting of upstream patches. A future kernel update in Red Hat Enterprise Linux 6 may address this issue.
Created kernel tracking bugs for this issue Affects: fedora-all [bug 782692]