* [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe()
@ 2019-05-14 13:07 Jia-Ju Bai
2019-05-15 1:08 ` Larry Finger
0 siblings, 1 reply; 3+ messages in thread
From: Jia-Ju Bai @ 2019-05-14 13:07 UTC (permalink / raw)
To: pkshih, Kalle Valo, David Miller
Cc: Linux Kernel Mailing List, linux-wireless, netdev
In rtl_pci_probe(), when request_irq() in rtl_pci_intr_mode_legacy() in
rtl_pci_intr_mode_decide() fails, a crash occurs.
The crash information is as follows:
[ 108.271155] kasan: CONFIG_KASAN_INLINE enabled
[ 108.271163] kasan: GPF could be caused by NULL-ptr deref or user
memory access
......
[ 108.271193] RIP: 0010:cfg80211_get_drvinfo+0xce/0x3b0 [cfg80211]
......
[ 108.271235] Call Trace:
[ 108.271245] ethtool_get_drvinfo+0x110/0x640
[ 108.271255] ? cfg80211_get_chan_state+0x7e0/0x7e0 [cfg80211]
[ 108.271261] ? ethtool_get_settings+0x340/0x340
[ 108.271268] ? __read_once_size_nocheck.constprop.7+0x20/0x20
[ 108.271279] ? kasan_check_write+0x14/0x20
[ 108.271284] dev_ethtool+0x272d/0x4c20
[ 108.271290] ? unwind_get_return_address+0x66/0xb0
[ 108.271299] ? __save_stack_trace+0x92/0x100
[ 108.271307] ? ethtool_get_rxnfc+0x3f0/0x3f0
[ 108.271316] ? save_stack+0xa3/0xd0
[ 108.271323] ? save_stack+0x43/0xd0
[ 108.271331] ? ftrace_graph_ret_addr+0x2d/0x170
[ 108.271338] ? ftrace_graph_ret_addr+0x2d/0x170
[ 108.271346] ? ftrace_graph_ret_addr+0x2d/0x170
[ 108.271354] ? update_stack_state+0x3b2/0x670
[ 108.271361] ? update_stack_state+0x3b2/0x670
[ 108.271370] ? __read_once_size_nocheck.constprop.7+0x20/0x20
[ 108.271379] ? unwind_next_frame.part.5+0x19f/0xa60
[ 108.271388] ? bpf_prog_kallsyms_find+0x3e/0x270
[ 108.271396] ? is_bpf_text_address+0x1a/0x30
[ 108.271408] ? kernel_text_address+0x11d/0x130
[ 108.271416] ? __kernel_text_address+0x12/0x40
[ 108.271423] ? unwind_get_return_address+0x66/0xb0
[ 108.271431] ? __save_stack_trace+0x92/0x100
[ 108.271440] ? save_stack+0xa3/0xd0
[ 108.271448] ? udp_ioctl+0x35/0xe0
[ 108.271457] ? inet_ioctl+0x100/0x320
[ 108.271466] ? inet_stream_connect+0xb0/0xb0
[ 108.271475] ? alloc_file+0x60/0x480
[ 108.271483] ? alloc_file_pseudo+0x19d/0x270
[ 108.271495] ? sock_alloc_file+0x51/0x170
[ 108.271502] ? __sys_socket+0x12c/0x1f0
[ 108.271510] ? __x64_sys_socket+0x78/0xb0
[ 108.271520] ? do_syscall_64+0xb1/0x2e0
[ 108.271529] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 108.271538] ? kasan_check_read+0x11/0x20
[ 108.271548] ? mutex_lock+0x8f/0xe0
[ 108.271557] ? __mutex_lock_slowpath+0x20/0x20
[ 108.271568] dev_ioctl+0x1fb/0xae0
[ 108.271576] ? dev_ioctl+0x1fb/0xae0
[ 108.271586] ? _copy_from_user+0x71/0xd0
[ 108.271594] sock_do_ioctl+0x1e2/0x2f0
[ 108.271602] ? kmem_cache_alloc+0xf9/0x250
[ 108.271611] ? ___sys_recvmsg+0x5a0/0x5a0
[ 108.271621] ? apparmor_file_alloc_security+0x128/0x7e0
[ 108.271630] ? kasan_unpoison_shadow+0x35/0x50
[ 108.271638] ? kasan_kmalloc+0xad/0xe0
[ 108.271652] ? apparmor_file_alloc_security+0x128/0x7e0
[ 108.271662] ? apparmor_file_alloc_security+0x269/0x7e0
[ 108.271670] sock_ioctl+0x361/0x590
[ 108.271678] ? sock_ioctl+0x361/0x590
[ 108.271686] ? routing_ioctl+0x470/0x470
[ 108.271695] ? kasan_check_write+0x14/0x20
[ 108.271703] ? __mutex_init+0xba/0x130
[ 108.271713] ? percpu_counter_add_batch+0xc7/0x120
[ 108.271722] ? alloc_empty_file+0xae/0x150
[ 108.271729] ? routing_ioctl+0x470/0x470
[ 108.271738] do_vfs_ioctl+0x1ae/0xfe0
[ 108.271745] ? do_vfs_ioctl+0x1ae/0xfe0
[ 108.271754] ? alloc_file_pseudo+0x1ad/0x270
[ 108.271762] ? ioctl_preallocate+0x1e0/0x1e0
[ 108.271770] ? alloc_file+0x480/0x480
[ 108.271778] ? kasan_check_read+0x11/0x20
[ 108.271786] ? __fget+0x24d/0x320
[ 108.271794] ? iterate_fd+0x180/0x180
[ 108.271802] ? fd_install+0x52/0x60
[ 108.271812] ? security_file_ioctl+0x8c/0xb0
[ 108.271820] ksys_ioctl+0x99/0xb0
[ 108.271829] __x64_sys_ioctl+0x78/0xb0
[ 108.271839] do_syscall_64+0xb1/0x2e0
[ 108.271857] ? prepare_exit_to_usermode+0xc8/0x160
[ 108.271871] entry_SYSCALL_64_after_hwframe+0x44/0xa9
......
I checked the driver source code, but cannot find the reason, so I only
report the crash...
Can somebody give an explanation about this crash?
This crash is triggered by a runtime fuzzing tool named FIZZER written
by us.
Best wishes,
Jia-Ju Bai
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe()
2019-05-14 13:07 [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe() Jia-Ju Bai
@ 2019-05-15 1:08 ` Larry Finger
2019-05-15 1:20 ` Jia-Ju Bai
0 siblings, 1 reply; 3+ messages in thread
From: Larry Finger @ 2019-05-15 1:08 UTC (permalink / raw)
To: Jia-Ju Bai, pkshih, Kalle Valo, David Miller
Cc: Linux Kernel Mailing List, linux-wireless, netdev
On 5/14/19 8:07 AM, Jia-Ju Bai wrote:
> In rtl_pci_probe(), when request_irq() in rtl_pci_intr_mode_legacy() in
> rtl_pci_intr_mode_decide() fails, a crash occurs.
> The crash information is as follows:
>
> [ 108.271155] kasan: CONFIG_KASAN_INLINE enabled
> [ 108.271163] kasan: GPF could be caused by NULL-ptr deref or user memory access
> ......
> [ 108.271193] RIP: 0010:cfg80211_get_drvinfo+0xce/0x3b0 [cfg80211]
> ......
> [ 108.271235] Call Trace:
> [ 108.271245] ethtool_get_drvinfo+0x110/0x640
> [ 108.271255] ? cfg80211_get_chan_state+0x7e0/0x7e0 [cfg80211]
> [ 108.271261] ? ethtool_get_settings+0x340/0x340
> [ 108.271268] ? __read_once_size_nocheck.constprop.7+0x20/0x20
> [ 108.271279] ? kasan_check_write+0x14/0x20
> [ 108.271284] dev_ethtool+0x272d/0x4c20
> [ 108.271290] ? unwind_get_return_address+0x66/0xb0
> [ 108.271299] ? __save_stack_trace+0x92/0x100
> [ 108.271307] ? ethtool_get_rxnfc+0x3f0/0x3f0
> [ 108.271316] ? save_stack+0xa3/0xd0
> [ 108.271323] ? save_stack+0x43/0xd0
> [ 108.271331] ? ftrace_graph_ret_addr+0x2d/0x170
> [ 108.271338] ? ftrace_graph_ret_addr+0x2d/0x170
> [ 108.271346] ? ftrace_graph_ret_addr+0x2d/0x170
> [ 108.271354] ? update_stack_state+0x3b2/0x670
> [ 108.271361] ? update_stack_state+0x3b2/0x670
> [ 108.271370] ? __read_once_size_nocheck.constprop.7+0x20/0x20
> [ 108.271379] ? unwind_next_frame.part.5+0x19f/0xa60
> [ 108.271388] ? bpf_prog_kallsyms_find+0x3e/0x270
> [ 108.271396] ? is_bpf_text_address+0x1a/0x30
> [ 108.271408] ? kernel_text_address+0x11d/0x130
> [ 108.271416] ? __kernel_text_address+0x12/0x40
> [ 108.271423] ? unwind_get_return_address+0x66/0xb0
> [ 108.271431] ? __save_stack_trace+0x92/0x100
> [ 108.271440] ? save_stack+0xa3/0xd0
> [ 108.271448] ? udp_ioctl+0x35/0xe0
> [ 108.271457] ? inet_ioctl+0x100/0x320
> [ 108.271466] ? inet_stream_connect+0xb0/0xb0
> [ 108.271475] ? alloc_file+0x60/0x480
> [ 108.271483] ? alloc_file_pseudo+0x19d/0x270
> [ 108.271495] ? sock_alloc_file+0x51/0x170
> [ 108.271502] ? __sys_socket+0x12c/0x1f0
> [ 108.271510] ? __x64_sys_socket+0x78/0xb0
> [ 108.271520] ? do_syscall_64+0xb1/0x2e0
> [ 108.271529] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 108.271538] ? kasan_check_read+0x11/0x20
> [ 108.271548] ? mutex_lock+0x8f/0xe0
> [ 108.271557] ? __mutex_lock_slowpath+0x20/0x20
> [ 108.271568] dev_ioctl+0x1fb/0xae0
> [ 108.271576] ? dev_ioctl+0x1fb/0xae0
> [ 108.271586] ? _copy_from_user+0x71/0xd0
> [ 108.271594] sock_do_ioctl+0x1e2/0x2f0
> [ 108.271602] ? kmem_cache_alloc+0xf9/0x250
> [ 108.271611] ? ___sys_recvmsg+0x5a0/0x5a0
> [ 108.271621] ? apparmor_file_alloc_security+0x128/0x7e0
> [ 108.271630] ? kasan_unpoison_shadow+0x35/0x50
> [ 108.271638] ? kasan_kmalloc+0xad/0xe0
> [ 108.271652] ? apparmor_file_alloc_security+0x128/0x7e0
> [ 108.271662] ? apparmor_file_alloc_security+0x269/0x7e0
> [ 108.271670] sock_ioctl+0x361/0x590
> [ 108.271678] ? sock_ioctl+0x361/0x590
> [ 108.271686] ? routing_ioctl+0x470/0x470
> [ 108.271695] ? kasan_check_write+0x14/0x20
> [ 108.271703] ? __mutex_init+0xba/0x130
> [ 108.271713] ? percpu_counter_add_batch+0xc7/0x120
> [ 108.271722] ? alloc_empty_file+0xae/0x150
> [ 108.271729] ? routing_ioctl+0x470/0x470
> [ 108.271738] do_vfs_ioctl+0x1ae/0xfe0
> [ 108.271745] ? do_vfs_ioctl+0x1ae/0xfe0
> [ 108.271754] ? alloc_file_pseudo+0x1ad/0x270
> [ 108.271762] ? ioctl_preallocate+0x1e0/0x1e0
> [ 108.271770] ? alloc_file+0x480/0x480
> [ 108.271778] ? kasan_check_read+0x11/0x20
> [ 108.271786] ? __fget+0x24d/0x320
> [ 108.271794] ? iterate_fd+0x180/0x180
> [ 108.271802] ? fd_install+0x52/0x60
> [ 108.271812] ? security_file_ioctl+0x8c/0xb0
> [ 108.271820] ksys_ioctl+0x99/0xb0
> [ 108.271829] __x64_sys_ioctl+0x78/0xb0
> [ 108.271839] do_syscall_64+0xb1/0x2e0
> [ 108.271857] ? prepare_exit_to_usermode+0xc8/0x160
> [ 108.271871] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> ......
>
> I checked the driver source code, but cannot find the reason, so I only report
> the crash...
> Can somebody give an explanation about this crash?
>
> This crash is triggered by a runtime fuzzing tool named FIZZER written by us.
Your backtrace does not include any references to rtlwifi routines, and I have
no idea what FIZZER does, thus it is not possible for me to debug this. If the
error situation that you state happens, the code should end up at label "fail3"
in routine rtl_pci_probe(). Insert printk statements after every line of the
following, and report the last good point before the error. It is certainly
possible that something is being torn down that was never erected. The
likelihood of failure of both MSI and legacy interrupts is not very likely, and
we probably have never hit those conditions.
fail3:
pci_set_drvdata(pdev, NULL);
rtl_deinit_core(hw);
fail2:
if (rtlpriv->io.pci_mem_start != 0)
pci_iounmap(pdev, (void __iomem *)rtlpriv->io.pci_mem_start);
pci_release_regions(pdev);
complete(&rtlpriv->firmware_loading_complete);
fail1:
if (hw)
ieee80211_free_hw(hw);
pci_disable_device(pdev);
return err;
Larry
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe()
2019-05-15 1:08 ` Larry Finger
@ 2019-05-15 1:20 ` Jia-Ju Bai
0 siblings, 0 replies; 3+ messages in thread
From: Jia-Ju Bai @ 2019-05-15 1:20 UTC (permalink / raw)
To: Larry Finger, pkshih, Kalle Valo, David Miller
Cc: Linux Kernel Mailing List, linux-wireless, netdev
On 2019/5/15 9:08, Larry Finger wrote:
> On 5/14/19 8:07 AM, Jia-Ju Bai wrote:
>> In rtl_pci_probe(), when request_irq() in rtl_pci_intr_mode_legacy()
>> in rtl_pci_intr_mode_decide() fails, a crash occurs.
>> The crash information is as follows:
>>
>> [ 108.271155] kasan: CONFIG_KASAN_INLINE enabled
>> [ 108.271163] kasan: GPF could be caused by NULL-ptr deref or user
>> memory access
>> ......
>> [ 108.271193] RIP: 0010:cfg80211_get_drvinfo+0xce/0x3b0 [cfg80211]
>> ......
>> [ 108.271235] Call Trace:
>> [ 108.271245] ethtool_get_drvinfo+0x110/0x640
>> [ 108.271255] ? cfg80211_get_chan_state+0x7e0/0x7e0 [cfg80211]
>> [ 108.271261] ? ethtool_get_settings+0x340/0x340
>> [ 108.271268] ? __read_once_size_nocheck.constprop.7+0x20/0x20
>> [ 108.271279] ? kasan_check_write+0x14/0x20
>> [ 108.271284] dev_ethtool+0x272d/0x4c20
>> [ 108.271290] ? unwind_get_return_address+0x66/0xb0
>> [ 108.271299] ? __save_stack_trace+0x92/0x100
>> [ 108.271307] ? ethtool_get_rxnfc+0x3f0/0x3f0
>> [ 108.271316] ? save_stack+0xa3/0xd0
>> [ 108.271323] ? save_stack+0x43/0xd0
>> [ 108.271331] ? ftrace_graph_ret_addr+0x2d/0x170
>> [ 108.271338] ? ftrace_graph_ret_addr+0x2d/0x170
>> [ 108.271346] ? ftrace_graph_ret_addr+0x2d/0x170
>> [ 108.271354] ? update_stack_state+0x3b2/0x670
>> [ 108.271361] ? update_stack_state+0x3b2/0x670
>> [ 108.271370] ? __read_once_size_nocheck.constprop.7+0x20/0x20
>> [ 108.271379] ? unwind_next_frame.part.5+0x19f/0xa60
>> [ 108.271388] ? bpf_prog_kallsyms_find+0x3e/0x270
>> [ 108.271396] ? is_bpf_text_address+0x1a/0x30
>> [ 108.271408] ? kernel_text_address+0x11d/0x130
>> [ 108.271416] ? __kernel_text_address+0x12/0x40
>> [ 108.271423] ? unwind_get_return_address+0x66/0xb0
>> [ 108.271431] ? __save_stack_trace+0x92/0x100
>> [ 108.271440] ? save_stack+0xa3/0xd0
>> [ 108.271448] ? udp_ioctl+0x35/0xe0
>> [ 108.271457] ? inet_ioctl+0x100/0x320
>> [ 108.271466] ? inet_stream_connect+0xb0/0xb0
>> [ 108.271475] ? alloc_file+0x60/0x480
>> [ 108.271483] ? alloc_file_pseudo+0x19d/0x270
>> [ 108.271495] ? sock_alloc_file+0x51/0x170
>> [ 108.271502] ? __sys_socket+0x12c/0x1f0
>> [ 108.271510] ? __x64_sys_socket+0x78/0xb0
>> [ 108.271520] ? do_syscall_64+0xb1/0x2e0
>> [ 108.271529] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> [ 108.271538] ? kasan_check_read+0x11/0x20
>> [ 108.271548] ? mutex_lock+0x8f/0xe0
>> [ 108.271557] ? __mutex_lock_slowpath+0x20/0x20
>> [ 108.271568] dev_ioctl+0x1fb/0xae0
>> [ 108.271576] ? dev_ioctl+0x1fb/0xae0
>> [ 108.271586] ? _copy_from_user+0x71/0xd0
>> [ 108.271594] sock_do_ioctl+0x1e2/0x2f0
>> [ 108.271602] ? kmem_cache_alloc+0xf9/0x250
>> [ 108.271611] ? ___sys_recvmsg+0x5a0/0x5a0
>> [ 108.271621] ? apparmor_file_alloc_security+0x128/0x7e0
>> [ 108.271630] ? kasan_unpoison_shadow+0x35/0x50
>> [ 108.271638] ? kasan_kmalloc+0xad/0xe0
>> [ 108.271652] ? apparmor_file_alloc_security+0x128/0x7e0
>> [ 108.271662] ? apparmor_file_alloc_security+0x269/0x7e0
>> [ 108.271670] sock_ioctl+0x361/0x590
>> [ 108.271678] ? sock_ioctl+0x361/0x590
>> [ 108.271686] ? routing_ioctl+0x470/0x470
>> [ 108.271695] ? kasan_check_write+0x14/0x20
>> [ 108.271703] ? __mutex_init+0xba/0x130
>> [ 108.271713] ? percpu_counter_add_batch+0xc7/0x120
>> [ 108.271722] ? alloc_empty_file+0xae/0x150
>> [ 108.271729] ? routing_ioctl+0x470/0x470
>> [ 108.271738] do_vfs_ioctl+0x1ae/0xfe0
>> [ 108.271745] ? do_vfs_ioctl+0x1ae/0xfe0
>> [ 108.271754] ? alloc_file_pseudo+0x1ad/0x270
>> [ 108.271762] ? ioctl_preallocate+0x1e0/0x1e0
>> [ 108.271770] ? alloc_file+0x480/0x480
>> [ 108.271778] ? kasan_check_read+0x11/0x20
>> [ 108.271786] ? __fget+0x24d/0x320
>> [ 108.271794] ? iterate_fd+0x180/0x180
>> [ 108.271802] ? fd_install+0x52/0x60
>> [ 108.271812] ? security_file_ioctl+0x8c/0xb0
>> [ 108.271820] ksys_ioctl+0x99/0xb0
>> [ 108.271829] __x64_sys_ioctl+0x78/0xb0
>> [ 108.271839] do_syscall_64+0xb1/0x2e0
>> [ 108.271857] ? prepare_exit_to_usermode+0xc8/0x160
>> [ 108.271871] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> ......
>>
>> I checked the driver source code, but cannot find the reason, so I
>> only report the crash...
>> Can somebody give an explanation about this crash?
>>
>> This crash is triggered by a runtime fuzzing tool named FIZZER
>> written by us.
>
> Your backtrace does not include any references to rtlwifi routines,
> and I have no idea what FIZZER does, thus it is not possible for me to
> debug this. If the error situation that you state happens, the code
> should end up at label "fail3" in routine rtl_pci_probe(). Insert
> printk statements after every line of the following, and report the
> last good point before the error. It is certainly possible that
> something is being torn down that was never erected. The likelihood of
> failure of both MSI and legacy interrupts is not very likely, and we
> probably have never hit those conditions.
>
> fail3:
> pci_set_drvdata(pdev, NULL);
> rtl_deinit_core(hw);
>
> fail2:
> if (rtlpriv->io.pci_mem_start != 0)
> pci_iounmap(pdev, (void __iomem
> *)rtlpriv->io.pci_mem_start);
>
> pci_release_regions(pdev);
> complete(&rtlpriv->firmware_loading_complete);
>
> fail1:
> if (hw)
> ieee80211_free_hw(hw);
> pci_disable_device(pdev);
>
> return err;
Thanks for the advice :)
I will insert some printk statements to debug this problem.
Best wishes,
Jia-Ju Bai
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-05-15 1:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-14 13:07 [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe() Jia-Ju Bai
2019-05-15 1:08 ` Larry Finger
2019-05-15 1:20 ` Jia-Ju Bai
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).