* BUG: while bridging Ethernet and wireless device:
@ 2010-12-16 12:11 Tomas Winkler
[not found] ` <AANLkTikYvBspVmAZ0DCMXJ-3WxkotwX+n8NpTtM+97_i-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-12-29 15:04 ` Johannes Berg
0 siblings, 2 replies; 15+ messages in thread
From: Tomas Winkler @ 2010-12-16 12:11 UTC (permalink / raw)
To: linux-netdev, linux-wireless
Will be happy if someone can give me some more insight. (kernel 2.6.37-rc5)
Thanks
Tomas
Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here
]------------
Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at
include/linux/skbuff.h:1178!
Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file:
/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.122712]
Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>]
EFLAGS: 00010283 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at
br_multicast_rcv+0xc95/0xe1c [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX:
f5626318 ECX: 00000000 EDX: 00000000
Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI:
f5626180 EBP: f60b5ca0 ESP: f60b5bd8
Dec 15 14:36:41 User-PC kernel: [175576.123737] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.124181] ec556500 f6d06800
f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
Dec 15 14:36:41 User-PC kernel: [175576.124181] f572c200 ef463440
f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
Dec 15 14:36:41 User-PC kernel: [175576.124181] ffffffff ec55652c
00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01087d8>] ?
sched_clock+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0138264>] ?
enqueue_entity+0x174/0x440
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e451>] ?
sched_clock_cpu+0x131/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c013e47d>] ?
select_task_rq_fair+0x2ad/0x730
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0524fc1>] ?
nf_iterate+0x71/0x90
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4914>] ?
br_handle_frame_finish+0x184/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ?
br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e46e9>] ?
br_handle_frame+0x189/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ?
br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4560>] ?
br_handle_frame+0x0/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff026>] ?
__netif_receive_skb+0x1b6/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04f7a30>] ?
skb_copy_bits+0x110/0x210
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0503a7f>] ?
netif_receive_skb+0x6f/0x80
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cb74c>] ?
ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cc836>] ?
ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff1f0>] ?
__netif_receive_skb+0x380/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e242>] ?
sched_clock_local+0xb2/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c012b688>] ?
default_spin_lock_flags+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ?
_raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cd621>] ?
ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82ce154>] ?
ieee80211_rx+0x2a4/0x830 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f815a8d6>] ?
iwl_update_stats+0xa6/0x2a0 [iwlcore]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8499212>] ?
iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ?
_raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8483697>] ?
iwl_rx_handle+0xe7/0x350 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8486ab7>] ?
iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01aece1>] ?
__rcu_process_callbacks+0x201/0x2d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150d05>] ?
tasklet_action+0xc5/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150a07>] ?
__do_softirq+0x97/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d910c>] ?
nmi_stack_correct+0x2f/0x34
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150970>] ?
__do_softirq+0x0/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] <IRQ>
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01508f5>] ?
irq_exit+0x65/0x70
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05df062>] ? do_IRQ+0x52/0xc0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01036b0>] ?
common_interrupt+0x30/0x38
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c03a1fc2>] ?
intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>] ?
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] ?
cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>] ?
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.124181] Code: ff ff ff be ea
ff ff ff 8b 82 b0 00 00 00 e9 fb f5 ff ff 89 c8 e8 4c dc ff ff 85 c0
89 c6 0f 84 9b f5 ff ff 66 90 e9 be fe ff ff <0f> 0b eb fe c7 47 20 01
00 00 00 8b 43 04 89 c2 81 e2 ff ff ff
Dec 15 14:36:41 User-PC kernel: [175576.124181] EIP: [<f83edd65>]
br_multicast_rcv+0xc95/0xe1c [bridge] SS:ESP 0068:f60b5bd8
Dec 15 14:36:41 User-PC kernel: [175576.124181] BUG: scheduling while
atomic: kworker/0:0/0/0x10000100
Dec 15 14:36:41 User-PC kernel: [175576.124181] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.124181] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.124181]
Dec 15 14:36:41 User-PC kernel: [175576.124181] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.124181] EIP: 0060:[<c03a1fc2>]
EFLAGS: 00000202 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.124181] EIP is at intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.124181] EAX: 00000000 EBX:
00001494 ECX: 00000000 EDX: 00001494
Dec 15 14:36:41 User-PC kernel: [175576.124181] ESI: 00000000 EDI:
00000004 EBP: f60b1f50 ESP: f60b1f28
Dec 15 14:36:41 User-PC kernel: [175576.124181] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.124181] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.124181] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.124181] 0000000b 00000000
77359400 00000001 00000010 00000002 00000001 f6d0a95c
Dec 15 14:36:41 User-PC kernel: [175576.124181] f6d0aa1c c0817f04
f60b1f60 c04daebb 00000001 00000001 f60b1f84 c0101dea
Dec 15 14:36:41 User-PC kernel: [175576.124181] c07d0ef4 f60b1f7c
e487e262 f2eb6781 85a608d2 00000000 00000000 f60b1fb0
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>] ?
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] ?
cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>] ?
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.124181] Code: f6 89 e0 25 00
e0 ff ff 8b 40 08 a8 08 75 08 b1 01 8b 45 e8 0f 01 c9 e8 cd fc dc ff
29 d8 19 f2 e8 04 d6 da ff 89 c6 89 d3 fb 90 <8d> 74 26 00 85 3d 78 41
7e c0 75 0d 8d 55 f0 b8 05 00 00 00 e8
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>]
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>]
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.487562] BUG: scheduling while
atomic: kworker/0:0/0/0x10000100
Dec 15 14:36:41 User-PC kernel: [175576.497058] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.522221] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.550740]
Dec 15 14:36:41 User-PC kernel: [175576.557947] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.565201] EIP: 0060:[<c03a1fc2>]
EFLAGS: 00000202 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.572280] EIP is at intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.579125] EAX: 00000000 EBX:
00001494 ECX: 00000000 EDX: 00001494
Dec 15 14:36:41 User-PC kernel: [175576.585850] ESI: 00000000 EDI:
00000004 EBP: f60b1f50 ESP: f60b1f28
Dec 15 14:36:41 User-PC kernel: [175576.592460] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.599021] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.605632] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.612158] 0000000b 00000000
77359400 00000001 00000010 00000002 00000001 f6d0a95c
Dec 15 14:36:41 User-PC kernel: [175576.618953] f6d0aa1c c0817f04
f60b1f60 c04daebb 00000001 00000001 f60b1f84 c0101dea
Dec 15 14:36:41 User-PC kernel: [175576.625818] c07d0ef4 f60b1f7c
e487e262 f2eb6781 85a608d2 00000000 00000000 f60b1fb0
Dec 15 14:36:41 User-PC kernel: [175576.632737] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.639461] [<c04daebb>] ?
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.646168] [<c0101dea>] ?
cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.652826] [<c05d2702>] ?
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.659441] Code: f6 89 e0 25 00
e0 ff ff 8b 40 08 a8 08 75 08 b1 01 8b 45 e8 0f 01 c9 e8 cd fc dc ff
29 d8 19 f2 e8 04 d6 da ff 89 c6 89 d3 fb 90 <8d> 74 26 00 85 3d 78 41
7e c0 75 0d 8d 55 f0 b8 05 00 00 00 e8
Dec 15 14:36:41 User-PC kernel: [175576.673805] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.680668] [<c04daebb>]
cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.687612] [<c0101dea>] cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.694516] [<c05d2702>]
start_secondary+0x1e8/0x1ee
Dec 15 14:36:41 User-PC kernel: [175576.711906] BUG: scheduling while
atomic: kworker/0:0/0/0x10000100
Dec 15 14:36:41 User-PC kernel: [175576.716280] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.734197] Modules linked in:
oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn
snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev
snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper
snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device
cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt
uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid
video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.753330]
Dec 15 14:36:41 User-PC kernel: [175576.757845] Pid: 0, comm:
kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.762389] EIP: 0060:[<c03a1fc2>]
EFLAGS: 00000202 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.766809] EIP is at intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.771119] EAX: 00000000 EBX:
00001494 ECX: 00000000 EDX: 00001494
Dec 15 14:36:41 User-PC kernel: [175576.775348] ESI: 00000000 EDI:
00000004 EBP: f60b1f50 ESP: f60b1f28
Dec 15 14:36:41 User-PC kernel: [175576.780037] DS: 007b ES: 007b FS:
00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.784159] Process kworker/0:0
(pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.788286] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.792375] 0000000b 00000000
77359400 00000001 00000010 00000002 00000001 f6d0a95c
^ permalink raw reply [flat|nested] 15+ messages in thread[parent not found: <AANLkTikYvBspVmAZ0DCMXJ-3WxkotwX+n8NpTtM+97_i-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: BUG: while bridging Ethernet and wireless device:
2010-12-16 12:11 BUG: while bridging Ethernet and wireless device: Tomas Winkler
[not found] ` <AANLkTikYvBspVmAZ0DCMXJ-3WxkotwX+n8NpTtM+97_i-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2010-12-29 15:04 ` Johannes Berg
2010-12-29 16:12 ` Tomas Winkler
1 sibling, 1 reply; 15+ messages in thread
From: Johannes Berg @ 2010-12-29 15:04 UTC (permalink / raw)
To: Tomas Winkler
Cc: linux-netdev, linux-wireless,
YOSHIFUJI Hideaki / 吉藤英明
On Thu, 2010-12-16 at 14:11 +0200, Tomas Winkler wrote:
> Will be happy if someone can give me some more insight. (kernel 2.6.37-rc5)
Tomas looked into it a bit more and told me that it happens on IPv6
packets. To recap, he gets
kernel BUG at include/linux/skbuff.h:1178!
with
EIP: [<f83edd65>] br_multicast_rcv+0xc95/0xe1c [bridge]
Also remember that the packets are almost fully nonlinear, when they get
here they likely have almost no data in the skb header.
I then looked at br_multicast_ipv6_rcv(), and it looks fishy:
Up to:
skb2 = skb_clone(skb, GFP_ATOMIC);
everything's fine, since ipv6_skip_exthdr() will use
skb_header_pointer(). At this point, offset is the result of
ipv6_skip_exthdr(). Remember that skb_clone() is not skb_copy().
Then, however, we do
__skb_pull(skb2, offset);
At this point, however, I don't see anything that guarantees that all
"offset" bytes are part of the headroom -- and indeed I think this is
where it crashes.
If it didn't crash, because this many bytes were part of the header,
continuing further into the function, however, we could still crash:
if (!pskb_may_pull(skb2, sizeof(*icmp6h)))
goto out;
now makes sure that we can read the ICMPv6 header. Later, however, we do
case ICMPV6_MGM_REPORT:
{
struct mld_msg *mld = (struct mld_msg *)icmp6h;
BR_INPUT_SKB_CB(skb2)->mrouters_only = 1;
err = br_ip6_multicast_add_group(br, port, &mld->mld_mca);
which seems just as unsafe since "mld_mca" need not be part of the
header of the SKB. Similarly in another branch of this.
Additionally, I'm not convinced that there even is guaranteed to be
enough space in the SKB at all for the entire "struct mld_msg".
And finally, the error path in this function is confusing. Below patch
should be fine since unlike IPv4 (where this was copied maybe?) this
code unconditionally clones the SKB.
johannes
---
net/bridge/br_multicast.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- wireless-testing.orig/net/bridge/br_multicast.c 2010-12-29 15:45:03.000000000 +0100
+++ wireless-testing/net/bridge/br_multicast.c 2010-12-29 16:03:03.000000000 +0100
@@ -1430,7 +1430,7 @@ static int br_multicast_ipv6_rcv(struct
struct net_bridge_port *port,
struct sk_buff *skb)
{
- struct sk_buff *skb2 = skb;
+ struct sk_buff *skb2;
struct ipv6hdr *ip6h;
struct icmp6hdr *icmp6h;
u8 nexthdr;
@@ -1535,9 +1535,7 @@ static int br_multicast_ipv6_rcv(struct
}
out:
- __skb_push(skb2, offset);
- if (skb2 != skb)
- kfree_skb(skb2);
+ kfree_skb(skb2);
return err;
}
#endif
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: BUG: while bridging Ethernet and wireless device:
2010-12-29 15:04 ` Johannes Berg
@ 2010-12-29 16:12 ` Tomas Winkler
2010-12-30 11:32 ` [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs Tomas Winkler
0 siblings, 1 reply; 15+ messages in thread
From: Tomas Winkler @ 2010-12-29 16:12 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-netdev, linux-wireless,
YOSHIFUJI Hideaki / 吉藤英明
2010/12/29 Johannes Berg <johannes@sipsolutions.net>:
> On Thu, 2010-12-16 at 14:11 +0200, Tomas Winkler wrote:
>> Will be happy if someone can give me some more insight. (kernel 2.6.37-rc5)
>
> Tomas looked into it a bit more and told me that it happens on IPv6
> packets. To recap, he gets
>
> kernel BUG at include/linux/skbuff.h:1178!
> with
> EIP: [<f83edd65>] br_multicast_rcv+0xc95/0xe1c [bridge]
>
> Also remember that the packets are almost fully nonlinear, when they get
> here they likely have almost no data in the skb header.
>
> I then looked at br_multicast_ipv6_rcv(), and it looks fishy:
>
> Up to:
> skb2 = skb_clone(skb, GFP_ATOMIC);
>
> everything's fine, since ipv6_skip_exthdr() will use
> skb_header_pointer(). At this point, offset is the result of
> ipv6_skip_exthdr(). Remember that skb_clone() is not skb_copy().
So far I can confirm that switching to sbk_copy fixes the crash.
Thanks
Tomas
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs
2010-12-29 16:12 ` Tomas Winkler
@ 2010-12-30 11:32 ` Tomas Winkler
2010-12-30 18:46 ` Stephen Hemminger
0 siblings, 1 reply; 15+ messages in thread
From: Tomas Winkler @ 2010-12-30 11:32 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-wireless, Tomas Winkler, Johannes Berg
use pskb_may_pull to access header correctly for paged skbs
the pskb_may_pull ideom is used ipv6 heder parsing
but omitted int the bridge code
this fixes bug https://bugzilla.kernel.org/show_bug.cgi?id=25202
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: authenticated
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: associated (aid 2)
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 RADIUS: starting accounting session 4D0608A3-00000005
Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here ]------------
Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in: oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.122712]
Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm: kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>] EFLAGS: 00010283 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX: f5626318 ECX: 00000000 EDX: 00000000
Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI: f5626180 EBP: f60b5ca0 ESP: f60b5bd8
Dec 15 14:36:41 User-PC kernel: [175576.123737] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0 (pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.124181] ec556500 f6d06800 f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
Dec 15 14:36:41 User-PC kernel: [175576.124181] f572c200 ef463440 f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
Dec 15 14:36:41 User-PC kernel: [175576.124181] ffffffff ec55652c 00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01087d8>] ? sched_clock+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0138264>] ? enqueue_entity+0x174/0x440
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e451>] ? sched_clock_cpu+0x131/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c013e47d>] ? select_task_rq_fair+0x2ad/0x730
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0524fc1>] ? nf_iterate+0x71/0x90
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4914>] ? br_handle_frame_finish+0x184/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e46e9>] ? br_handle_frame+0x189/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4560>] ? br_handle_frame+0x0/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff026>] ? __netif_receive_skb+0x1b6/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04f7a30>] ? skb_copy_bits+0x110/0x210
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0503a7f>] ? netif_receive_skb+0x6f/0x80
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cb74c>] ? ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cc836>] ? ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff1f0>] ? __netif_receive_skb+0x380/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e242>] ? sched_clock_local+0xb2/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c012b688>] ? default_spin_lock_flags+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cd621>] ? ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82ce154>] ? ieee80211_rx+0x2a4/0x830 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f815a8d6>] ? iwl_update_stats+0xa6/0x2a0 [iwlcore]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8499212>] ? iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8483697>] ? iwl_rx_handle+0xe7/0x350 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8486ab7>] ? iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01aece1>] ? __rcu_process_callbacks+0x201/0x2d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150d05>] ? tasklet_action+0xc5/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150a07>] ? __do_softirq+0x97/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d910c>] ? nmi_stack_correct+0x2f/0x34
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150970>] ? __do_softirq+0x0/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181] <IRQ>
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01508f5>] ? irq_exit+0x65/0x70
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05df062>] ? do_IRQ+0x52/0xc0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01036b0>] ? common_interrupt+0x30/0x38
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c03a1fc2>] ? intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>] ? cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] ? cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>] ? start_secondary+0x1e8/0x1ee
Cc:YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
net/bridge/br_multicast.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index f19e347..074c478 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1464,6 +1464,10 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
return 0;
+ if (!pskb_may_pull(skb,
+ (skb_network_header(skb) + offset + 1 - skb->data)))
+ return 0;
+
/* Okay, we found ICMPv6 header */
skb2 = skb_clone(skb, GFP_ATOMIC);
if (!skb2)
--
1.7.3.4
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs
2010-12-30 11:32 ` [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs Tomas Winkler
@ 2010-12-30 18:46 ` Stephen Hemminger
2010-12-30 18:52 ` Johannes Berg
0 siblings, 1 reply; 15+ messages in thread
From: Stephen Hemminger @ 2010-12-30 18:46 UTC (permalink / raw)
To: Tomas Winkler; +Cc: davem, netdev, linux-wireless, Johannes Berg
On Thu, 30 Dec 2010 13:32:33 +0200
Tomas Winkler <tomas.winkler@intel.com> wrote:
> use pskb_may_pull to access header correctly for paged skbs
>
> the pskb_may_pull ideom is used ipv6 heder parsing
> but omitted int the bridge code
>
> this fixes bug https://bugzilla.kernel.org/show_bug.cgi?id=25202
>
> Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: authenticated
> Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: associated (aid 2)
> Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 RADIUS: starting accounting session 4D0608A3-00000005
> Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here ]------------
> Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
> Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
> Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
> Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in: oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
> Dec 15 14:36:41 User-PC kernel: [175576.122712]
> Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm: kworker/0:0 Tainted: G W 2.6.37-rc5-wl+ #3 1015PE/1016P
> Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>] EFLAGS: 00010283 CPU: 1
> Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX: f5626318 ECX: 00000000 EDX: 00000000
> Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI: f5626180 EBP: f60b5ca0 ESP: f60b5bd8
> Dec 15 14:36:41 User-PC kernel: [175576.123737] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0 (pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
> Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
> Dec 15 14:36:41 User-PC kernel: [175576.124181] ec556500 f6d06800 f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
> Dec 15 14:36:41 User-PC kernel: [175576.124181] f572c200 ef463440 f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
> Dec 15 14:36:41 User-PC kernel: [175576.124181] ffffffff ec55652c 00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
> Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01087d8>] ? sched_clock+0x8/0x10
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0138264>] ? enqueue_entity+0x174/0x440
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e451>] ? sched_clock_cpu+0x131/0x190
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c013e47d>] ? select_task_rq_fair+0x2ad/0x730
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0524fc1>] ? nf_iterate+0x71/0x90
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4914>] ? br_handle_frame_finish+0x184/0x220 [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e46e9>] ? br_handle_frame+0x189/0x230 [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f83e4560>] ? br_handle_frame+0x0/0x230 [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff026>] ? __netif_receive_skb+0x1b6/0x5b0
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04f7a30>] ? skb_copy_bits+0x110/0x210
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0503a7f>] ? netif_receive_skb+0x6f/0x80
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cb74c>] ? ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cc836>] ? ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04ff1f0>] ? __netif_receive_skb+0x380/0x5b0
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c016e242>] ? sched_clock_local+0xb2/0x190
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c012b688>] ? default_spin_lock_flags+0x8/0x10
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82cd621>] ? ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f82ce154>] ? ieee80211_rx+0x2a4/0x830 [mac80211]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f815a8d6>] ? iwl_update_stats+0xa6/0x2a0 [iwlcore]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8499212>] ? iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8483697>] ? iwl_rx_handle+0xe7/0x350 [iwlagn]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<f8486ab7>] ? iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01aece1>] ? __rcu_process_callbacks+0x201/0x2d0
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150d05>] ? tasklet_action+0xc5/0x100
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150a07>] ? __do_softirq+0x97/0x1d0
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d910c>] ? nmi_stack_correct+0x2f/0x34
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0150970>] ? __do_softirq+0x0/0x1d0
> Dec 15 14:36:41 User-PC kernel: [175576.124181] <IRQ>
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01508f5>] ? irq_exit+0x65/0x70
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05df062>] ? do_IRQ+0x52/0xc0
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c01036b0>] ? common_interrupt+0x30/0x38
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c03a1fc2>] ? intel_idle+0xc2/0x160
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c04daebb>] ? cpuidle_idle_call+0x6b/0x100
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c0101dea>] ? cpu_idle+0x8a/0xf0
> Dec 15 14:36:41 User-PC kernel: [175576.124181] [<c05d2702>] ? start_secondary+0x1e8/0x1ee
>
> Cc:YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> ---
> net/bridge/br_multicast.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index f19e347..074c478 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1464,6 +1464,10 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
> if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
> return 0;
>
> + if (!pskb_may_pull(skb,
> + (skb_network_header(skb) + offset + 1 - skb->data)))
> + return 0;
> +
> /* Okay, we found ICMPv6 header */
> skb2 = skb_clone(skb, GFP_ATOMIC);
> if (!skb2)
This doesn't look correct. The calculation of the offset doesn't look correct.
Just following the skb_clone(), the skb_pull value is "offset".
Also, the other checks return -EINVAL for incorrectly formed packet.
--- a/net/bridge/br_multicast.c 2010-12-30 10:29:58.579510488 -0800
+++ b/net/bridge/br_multicast.c 2010-12-30 10:43:27.273386691 -0800
@@ -1464,6 +1464,9 @@ static int br_multicast_ipv6_rcv(struct
if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
return 0;
+ if (!pskb_may_pull(skb, offset))
+ return -EINVAL;
+
/* Okay, we found ICMPv6 header */
skb2 = skb_clone(skb, GFP_ATOMIC);
if (!skb2)
--
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs
2010-12-30 18:46 ` Stephen Hemminger
@ 2010-12-30 18:52 ` Johannes Berg
[not found] ` <1293735134.21956.1.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
0 siblings, 1 reply; 15+ messages in thread
From: Johannes Berg @ 2010-12-30 18:52 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Tomas Winkler, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
On Thu, 2010-12-30 at 10:46 -0800, Stephen Hemminger wrote:
> This doesn't look correct. The calculation of the offset doesn't look correct.
> Just following the skb_clone(), the skb_pull value is "offset".
> Also, the other checks return -EINVAL for incorrectly formed packet.
>
> --- a/net/bridge/br_multicast.c 2010-12-30 10:29:58.579510488 -0800
> +++ b/net/bridge/br_multicast.c 2010-12-30 10:43:27.273386691 -0800
> @@ -1464,6 +1464,9 @@ static int br_multicast_ipv6_rcv(struct
> if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
> return 0;
>
> + if (!pskb_may_pull(skb, offset))
> + return -EINVAL;
> +
> /* Okay, we found ICMPv6 header */
> skb2 = skb_clone(skb, GFP_ATOMIC);
> if (!skb2)
Wouldn't that make more sense after the clone anyway? But if you look at
my email, you'll find that there's potentially, and conditionally, more
stuff that will be read from the skb's header, which hasn't necessarily
been pulled in, so I think this still won't fix all the issues.
Seeing how this only affects some ICMPv6 packets, maybe we should just
use skb_copy() instead?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs
@ 2010-12-30 23:06 Stephen Hemminger
[not found] ` <9mk4bme8o97ir27xi8a9fbsd.1293750376929-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
2010-12-31 20:45 ` David Miller
0 siblings, 2 replies; 15+ messages in thread
From: Stephen Hemminger @ 2010-12-30 23:06 UTC (permalink / raw)
To: Winkler, Tomas, Stephen Hemminger, Johannes Berg
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Although copy is slower for large packets, this is a non performance path. The code in question is for bridged multicast Ipv6 ICMP packets. This case is so uncritical it could be done in BASIC and no one could possibly care!
"Winkler, Tomas" <tomas.winkler@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
>> Sent: Thursday, December 30, 2010 9:06 PM
>> To: Johannes Berg
>> Cc: Winkler, Tomas; davem@davemloft.net; netdev@vger.kernel.org; linux-
>> wireless@vger.kernel.org
>> Subject: Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged
>> skbs
>>
>> On Thu, 30 Dec 2010 19:52:14 +0100
>> Johannes Berg <johannes@sipsolutions.net> wrote:
>>
>> > On Thu, 2010-12-30 at 10:46 -0800, Stephen Hemminger wrote:
>> >
>> > > This doesn't look correct. The calculation of the offset doesn't look
>> correct.
>> > > Just following the skb_clone(), the skb_pull value is "offset".
>> > > Also, the other checks return -EINVAL for incorrectly formed packet.
>> > >
>> > > --- a/net/bridge/br_multicast.c 2010-12-30 10:29:58.579510488 -0800
>> > > +++ b/net/bridge/br_multicast.c 2010-12-30 10:43:27.273386691 -0800
>> > > @@ -1464,6 +1464,9 @@ static int br_multicast_ipv6_rcv(struct
>> > > if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
>> > > return 0;
>> > >
>> > > + if (!pskb_may_pull(skb, offset))
>> > > + return -EINVAL;
>> > > +
>> > > /* Okay, we found ICMPv6 header */
>> > > skb2 = skb_clone(skb, GFP_ATOMIC);
>> > > if (!skb2)
>> >
>> > Wouldn't that make more sense after the clone anyway? But if you look at
>> > my email, you'll find that there's potentially, and conditionally, more
>> > stuff that will be read from the skb's header, which hasn't necessarily
>> > been pulled in, so I think this still won't fix all the issues.
>> >
>> > Seeing how this only affects some ICMPv6 packets, maybe we should just
>> > use skb_copy() instead?
>>
>> It comes out cleaner, and the check can be simplified.
>>
>> --- a/net/bridge/br_multicast.c 2010-12-30 10:47:12.031733855 -0800
>> +++ b/net/bridge/br_multicast.c 2010-12-30 11:00:12.135801266 -0800
>> @@ -1465,19 +1465,19 @@ static int br_multicast_ipv6_rcv(struct
>> return 0;
>>
>> /* Okay, we found ICMPv6 header */
>> - skb2 = skb_clone(skb, GFP_ATOMIC);
>> + skb2 = skb_copy(skb, GFP_ATOMIC);
>> if (!skb2)
>> return -ENOMEM;
>>
>> + err = -EINVAL;
>> + if (skb2->len < offset + sizeof(*icmp6h))
>> + goto out;
>> +
>> len -= offset - skb_network_offset(skb2);
>>
>> __skb_pull(skb2, offset);
>> skb_reset_transport_header(skb2);
>>
>> - err = -EINVAL;
>> - if (!pskb_may_pull(skb2, sizeof(*icmp6h)))
>> - goto out;
>> -
>> icmp6h = icmp6_hdr(skb2);
>>
>> switch (icmp6h->icmp6_type) {
>>
>>
>Sorry for dump question but isn't there performance penalty on using skb_copy vs. skb_clone?
>
>Anyhow Below is a code snippet from ip6_input.c so you probably would want to fix it all over.
>BTW offset and the pointer arithmetic really gives the same number +1, I'm not surly why the original author would thought it be safer than just using offset.
>
> offset = ipv6_skip_exthdr(skb, sizeof(*hdr),
> &nexthdr);
> if (offset < 0)
> goto out;
>
> if (nexthdr != IPPROTO_ICMPV6)
> goto out;
>
> if (!pskb_may_pull(skb, (skb_network_header(skb) +
> offset + 1 - skb->data)))
> goto out;
>
> icmp6 = (struct icmp6hdr *)(skb_network_header(skb) + offset);
>
>
>
>Thanks
>Tomas
>
>
>---------------------------------------------------------------------
>Intel Israel (74) Limited
>
>This e-mail and any attachments may contain confidential material for
>the sole use of the intended recipient(s). Any review or distribution
>by others is strictly prohibited. If you are not the intended
>recipient, please contact the sender and delete all copies.
>
^ permalink raw reply [flat|nested] 15+ messages in thread[parent not found: <9mk4bme8o97ir27xi8a9fbsd.1293750376929-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>]
* RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs
[not found] ` <9mk4bme8o97ir27xi8a9fbsd.1293750376929-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
@ 2010-12-30 23:29 ` Winkler, Tomas
[not found] ` <6F5C1D715B2DA5498A628E6B9C124F04019BF36ABD-KS4eWWg9cz+vNW/NfzhIbrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
0 siblings, 1 reply; 15+ messages in thread
From: Winkler, Tomas @ 2010-12-30 23:29 UTC (permalink / raw)
To: Stephen Hemminger, Stephen Hemminger, Johannes Berg
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen.hemminger@vyatta.com]
> Sent: Friday, December 31, 2010 1:06 AM
> To: Winkler, Tomas; Stephen Hemminger; Johannes Berg
> Cc: davem@davemloft.net; netdev@vger.kernel.org ; linux-
> wireless@vger.kernel.org
> Subject: RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged
> skbs
>
> Although copy is slower for large packets, this is a non performance path.
> The code in question is for bridged multicast Ipv6 ICMP packets. This case
> is so uncritical it could be done in BASIC and no one could possibly care!
>
Fair enough, although you got few of those when you connect to win7 client.
Anyhow my fix would work if the second pull would be
if (!pskb_may_pull(skb2, sizeof(struct mld_msg))) instead of (!pskb_may_pull(skb2, sizeof(*icmp6h)))
Second I think just that non multicast places shouldn't be fixed contrary to my previous suggestion as the
skb_network_header(skb) + offset + 1 - skb->data will give you correct offset to pull up if the network header is not on skb->data.
Thanks
Tomas
> "Winkler, Tomas" <tomas.winkler@intel.com> wrote:
>
> >
> >
> >> -----Original Message-----
> >> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> >> Sent: Thursday, December 30, 2010 9:06 PM
> >> To: Johannes Berg
> >> Cc: Winkler, Tomas; davem@davemloft.net; netdev@vger.kernel.org; linux-
> >> wireless@vger.kernel.org
> >> Subject: Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged
> >> skbs
> >>
> >> On Thu, 30 Dec 2010 19:52:14 +0100
> >> Johannes Berg <johannes@sipsolutions.net> wrote:
> >>
> >> > On Thu, 2010-12-30 at 10:46 -0800, Stephen Hemminger wrote:
> >> >
> >> > > This doesn't look correct. The calculation of the offset doesn't look
> >> correct.
> >> > > Just following the skb_clone(), the skb_pull value is "offset".
> >> > > Also, the other checks return -EINVAL for incorrectly formed packet.
> >> > >
> >> > > --- a/net/bridge/br_multicast.c 2010-12-30 10:29:58.579510488 -0800
> >> > > +++ b/net/bridge/br_multicast.c 2010-12-30 10:43:27.273386691 -0800
> >> > > @@ -1464,6 +1464,9 @@ static int br_multicast_ipv6_rcv(struct
> >> > > if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
> >> > > return 0;
> >> > >
> >> > > + if (!pskb_may_pull(skb, offset))
> >> > > + return -EINVAL;
> >> > > +
> >> > > /* Okay, we found ICMPv6 header */
> >> > > skb2 = skb_clone(skb, GFP_ATOMIC);
> >> > > if (!skb2)
> >> >
> >> > Wouldn't that make more sense after the clone anyway? But if you look
> at
> >> > my email, you'll find that there's potentially, and conditionally, more
> >> > stuff that will be read from the skb's header, which hasn't necessarily
> >> > been pulled in, so I think this still won't fix all the issues.
> >> >
> >> > Seeing how this only affects some ICMPv6 packets, maybe we should just
> >> > use skb_copy() instead?
> >>
> >> It comes out cleaner, and the check can be simplified.
> >>
> >> --- a/net/bridge/br_multicast.c 2010-12-30 10:47:12.031733855 -0800
> >> +++ b/net/bridge/br_multicast.c 2010-12-30 11:00:12.135801266 -0800
> >> @@ -1465,19 +1465,19 @@ static int br_multicast_ipv6_rcv(struct
> >> return 0;
> >>
> >> /* Okay, we found ICMPv6 header */
> >> - skb2 = skb_clone(skb, GFP_ATOMIC);
> >> + skb2 = skb_copy(skb, GFP_ATOMIC);
> >> if (!skb2)
> >> return -ENOMEM;
> >>
> >> + err = -EINVAL;
> >> + if (skb2->len < offset + sizeof(*icmp6h))
> >> + goto out;
> >> +
> >> len -= offset - skb_network_offset(skb2);
> >>
> >> __skb_pull(skb2, offset);
> >> skb_reset_transport_header(skb2);
> >>
> >> - err = -EINVAL;
> >> - if (!pskb_may_pull(skb2, sizeof(*icmp6h)))
> >> - goto out;
> >> -
> >> icmp6h = icmp6_hdr(skb2);
> >>
> >> switch (icmp6h->icmp6_type) {
> >>
> >>
> >Sorry for dump question but isn't there performance penalty on using
> skb_copy vs. skb_clone?
> >
> >Anyhow Below is a code snippet from ip6_input.c so you probably would want
> to fix it all over.
> >BTW offset and the pointer arithmetic really gives the same number +1, I'm
> not surly why the original author would thought it be safer than just using
> offset.
> >
> > offset = ipv6_skip_exthdr(skb,
> sizeof(*hdr),
> > &nexthdr);
> > if (offset < 0)
> > goto out;
> >
> > if (nexthdr != IPPROTO_ICMPV6)
> > goto out;
> >
> > if (!pskb_may_pull(skb,
> (skb_network_header(skb) +
> > offset + 1 - skb-
> >data)))
> > goto out;
> >
> > icmp6 = (struct icmp6hdr
> *)(skb_network_header(skb) + offset);
> >
> >
> >
> >Thanks
> >Tomas
> >
> >
> >---------------------------------------------------------------------
> >Intel Israel (74) Limited
> >
> >This e-mail and any attachments may contain confidential material for
> >the sole use of the intended recipient(s). Any review or distribution
> >by others is strictly prohibited. If you are not the intended
> >recipient, please contact the sender and delete all copies.
> >
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs
2010-12-30 23:06 Stephen Hemminger
[not found] ` <9mk4bme8o97ir27xi8a9fbsd.1293750376929-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
@ 2010-12-31 20:45 ` David Miller
2010-12-31 21:16 ` Winkler, Tomas
1 sibling, 1 reply; 15+ messages in thread
From: David Miller @ 2010-12-31 20:45 UTC (permalink / raw)
To: stephen.hemminger
Cc: tomas.winkler, shemminger, johannes, netdev, linux-wireless
From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Thu, 30 Dec 2010 15:06:16 -0800
> Although copy is slower for large packets, this is a non performance
> path. The code in question is for bridged multicast Ipv6 ICMP
> packets. This case is so uncritical it could be done in BASIC and no
> one could possibly care!
I still think we should be judicious and keep using skb_clone() here.
Simply combine the two pskb_may_pull() calls into one on "skb2" after
the clone and before the blind __skb_pull() call. Then add a error
path "out:" called "out_nopush:" for the error path to goto.
Also, I think the "+ 1" in the ipv6 stack code comes from the fact that
the parsing loop can "peek" into the next header's byte to see the type.
And I really don't think it's relevant here.
Also, all of these "x_header + ... + 1 - skb->data" factors are
irrelevent and shouldn't be used. Just pass "offset + sizeof(*icmp6h)"
to pskb_may_pull().
^ permalink raw reply [flat|nested] 15+ messages in thread* RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs
2010-12-31 20:45 ` David Miller
@ 2010-12-31 21:16 ` Winkler, Tomas
0 siblings, 0 replies; 15+ messages in thread
From: Winkler, Tomas @ 2010-12-31 21:16 UTC (permalink / raw)
To: David Miller, stephen.hemminger@vyatta.com
Cc: shemminger@vyatta.com, johannes@sipsolutions.net,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, December 31, 2010 10:46 PM
> To: stephen.hemminger@vyatta.com
> Cc: Winkler, Tomas; shemminger@vyatta.com; johannes@sipsolutions.net;
> netdev@vger.kernel.org; linux-wireless@vger.kernel.org
> Subject: Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged
> skbs
>
> From: Stephen Hemminger <stephen.hemminger@vyatta.com>
> Date: Thu, 30 Dec 2010 15:06:16 -0800
>
> > Although copy is slower for large packets, this is a non performance
> > path. The code in question is for bridged multicast Ipv6 ICMP
> > packets. This case is so uncritical it could be done in BASIC and no
> > one could possibly care!
>
> I still think we should be judicious and keep using skb_clone() here.
>
> Simply combine the two pskb_may_pull() calls into one on "skb2" after
> the clone and before the blind __skb_pull() call. Then add a error
> path "out:" called "out_nopush:" for the error path to goto.
>
> Also, I think the "+ 1" in the ipv6 stack code comes from the fact that
> the parsing loop can "peek" into the next header's byte to see the type.
> And I really don't think it's relevant here.
>
> Also, all of these "x_header + ... + 1 - skb->data" factors are
> irrelevent and shouldn't be used. Just pass "offset + sizeof(*icmp6h)"
> to pskb_may_pull().
Sounds reasonable but maybe we shall pass offset + sizeof(struct mld_msg) as *icmp6h is casted to this struct mld_mca is accessed.
struct mld_msg {
struct icmp6hdr mld_hdr;
struct in6_addr mld_mca;
};
Thanks
Tomas
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2010-12-31 21:16 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-16 12:11 BUG: while bridging Ethernet and wireless device: Tomas Winkler
[not found] ` <AANLkTikYvBspVmAZ0DCMXJ-3WxkotwX+n8NpTtM+97_i-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-12-16 12:16 ` Johannes Berg
[not found] ` <1292501797.3612.12.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2010-12-19 9:07 ` Tomas Winkler
2010-12-29 15:04 ` Johannes Berg
2010-12-29 16:12 ` Tomas Winkler
2010-12-30 11:32 ` [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs Tomas Winkler
2010-12-30 18:46 ` Stephen Hemminger
2010-12-30 18:52 ` Johannes Berg
[not found] ` <1293735134.21956.1.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2010-12-30 19:06 ` Stephen Hemminger
2010-12-30 21:00 ` Winkler, Tomas
-- strict thread matches above, loose matches on Subject: below --
2010-12-30 23:06 Stephen Hemminger
[not found] ` <9mk4bme8o97ir27xi8a9fbsd.1293750376929-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
2010-12-30 23:29 ` Winkler, Tomas
[not found] ` <6F5C1D715B2DA5498A628E6B9C124F04019BF36ABD-KS4eWWg9cz+vNW/NfzhIbrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2010-12-31 10:18 ` Johannes Berg
2010-12-31 20:45 ` David Miller
2010-12-31 21:16 ` Winkler, Tomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).