lkml.org 
[lkml]   [2019]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe()
From
Date


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

\
 
 \ /
  Last update: 2019-05-15 03:21    [W:0.044 / U:26.964 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site