diff options
author | Paul Bolle <pebolle@tiscali.nl> | 2019-05-01 23:19:03 +0200 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2019-05-05 09:54:08 -0700 |
commit | 4014dfae3ccaaf3ec19c9ae0691a3f14e7132eae (patch) | |
tree | 01fd0cb1e20939261401cb4da8aa87222c431ee9 /net/sched | |
parent | b4010af981ac8cdf1f7f58eb6b131c482e5dee02 (diff) |
isdn: bas_gigaset: use usb_fill_int_urb() properly
The switch to make bas_gigaset use usb_fill_int_urb() - instead of
filling that urb "by hand" - missed the subtle ordering of the previous
code.
See, before the switch urb->dev was set to a member somewhere deep in a
complicated structure and then supplied to usb_rcvisocpipe() and
usb_sndisocpipe(). After that switch urb->dev wasn't set to anything
specific before being supplied to those two macros. This triggers a
nasty oops:
BUG: unable to handle kernel NULL pointer dereference at 00000000
#PF error: [normal kernel read fault]
*pde = 00000000
Oops: 0000 [#1] SMP
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.1.0-0.rc4.1.local0.fc28.i686 #1
Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET64WW (2.09 ) 12/14/2006
EIP: gigaset_init_bchannel+0x89/0x320 [bas_gigaset]
Code: 75 07 83 8b 84 00 00 00 40 8d 47 74 c7 07 01 00 00 00 89 45 f0 8b 44 b7 68 85 c0 0f 84 6a 02 00 00 8b 48 28 8b 93 88 00 00 00 <8b> 09 8d 54 12 03 c1 e2 0f c1 e1 08 09 ca 8b 8b 8c 00 00 00 80 ca
EAX: f05ec200 EBX: ed404200 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: f065a000 EBP: f30c9f40 ESP: f30c9f20
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010086
CR0: 80050033 CR2: 00000000 CR3: 0ddc7000 CR4: 000006d0
Call Trace:
<SOFTIRQ>
? gigaset_isdn_connD+0xf6/0x140 [gigaset]
gigaset_handle_event+0x173e/0x1b90 [gigaset]
tasklet_action_common.isra.16+0x4e/0xf0
tasklet_action+0x1e/0x20
__do_softirq+0xb2/0x293
? __irqentry_text_end+0x3/0x3
call_on_stack+0x45/0x50
</SOFTIRQ>
? irq_exit+0xb5/0xc0
? do_IRQ+0x78/0xd0
? acpi_idle_enter_s2idle+0x50/0x50
? common_interrupt+0xd4/0xdc
? acpi_idle_enter_s2idle+0x50/0x50
? sched_cpu_activate+0x1b/0xf0
? acpi_fan_resume.cold.7+0x9/0x18
? cpuidle_enter_state+0x152/0x4c0
? cpuidle_enter+0x14/0x20
? call_cpuidle+0x21/0x40
? do_idle+0x1c8/0x200
? cpu_startup_entry+0x25/0x30
? rest_init+0x88/0x8a
? arch_call_rest_init+0xd/0x19
? start_kernel+0x42f/0x448
? i386_start_kernel+0xac/0xb0
? startup_32_smp+0x164/0x168
Modules linked in: ppp_generic slhc capi bas_gigaset gigaset kernelcapi nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables sunrpc ipw2200 iTCO_wdt gpio_ich snd_intel8x0 libipw iTCO_vendor_support snd_ac97_codec lib80211 ppdev ac97_bus snd_seq cfg80211 snd_seq_device pcspkr thinkpad_acpi lpc_ich snd_pcm i2c_i801 snd_timer ledtrig_audio snd soundcore rfkill parport_pc parport pcc_cpufreq acpi_cpufreq i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sdhci_pci sysimgblt cqhci fb_sys_fops drm sdhci mmc_core tg3 ata_generic serio_raw yenta_socket pata_acpi video
CR2: 0000000000000000
---[ end trace 1fe07487b9200c73 ]---
EIP: gigaset_init_bchannel+0x89/0x320 [bas_gigaset]
Code: 75 07 83 8b 84 00 00 00 40 8d 47 74 c7 07 01 00 00 00 89 45 f0 8b 44 b7 68 85 c0 0f 84 6a 02 00 00 8b 48 28 8b 93 88 00 00 00 <8b> 09 8d 54 12 03 c1 e2 0f c1 e1 08 09 ca 8b 8b 8c 00 00 00 80 ca
EAX: f05ec200 EBX: ed404200 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: f065a000 EBP: f30c9f40 ESP: cddcb3bc
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010086
CR0: 80050033 CR2: 00000000 CR3: 0ddc7000 CR4: 000006d0
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: 0xcc00000 from 0xc0400000 (relocation range: 0xc0000000-0xf6ffdfff)
---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
No-one noticed because this Oops is apparently only triggered by setting
up an ISDN data connection on a live ISDN line on a gigaset base (ie,
the PBX that the gigaset driver support). Very few people do that
running present day kernels.
Anyhow, a little code reorganization makes this problem go away, while
avoiding the subtle ordering that was used in the past. So let's do
that.
Fixes: 78c696c19578 ("isdn: gigaset: use usb_fill_int_urb()")
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/sched')
0 files changed, 0 insertions, 0 deletions