Re: [PATCH] rtlwifi: Fix null-pointer dereferences in error handling code of rtl_pci_probe()

From: Larry Finger
Date: Wed May 29 2019 - 11:51:54 EST

On 5/29/19 5:30 AM, Jia-Ju Bai wrote:

On 2019/5/28 21:00, Larry Finger wrote:
On 5/28/19 6:55 AM, Kalle Valo wrote:
Jia-Ju Bai <baijiaju1990@xxxxxxxxx> wrote:

*BUG 1:
In rtl_pci_probe(), when rtlpriv->cfg->ops->init_sw_vars() fails,
rtl_deinit_core() in the error handling code is executed.
rtl_deinit_core() calls rtl_free_entries_from_scan_list(), which uses
rtlpriv->scan_list.list in list_for_each_entry_safe(), but it has been
initialized. Thus a null-pointer dereference occurs.
The reason is that rtlpriv->scan_list.list is initialized by
INIT_LIST_HEAD() in rtl_init_core(), which has not been called.

To fix this bug, rtl_deinit_core() should not be called when
rtlpriv->cfg->ops->init_sw_vars() fails.

*BUG 2:
In rtl_pci_probe(), rtl_init_core() can fail when rtl_regd_init() in
this function fails, and rtlpriv->scan_list.list has not been
initialized by INIT_LIST_HEAD(). Then, rtl_deinit_core() in the error
handling code of rtl_pci_probe() is executed. Finally, a null-pointer
dereference occurs due to the same reason of the above bug.

To fix this bug, the initialization of lists in rtl_init_core() are
performed before the call to rtl_regd_init().

These bugs are found by a runtime fuzzing tool named FIZZER written by

Signed-off-by: Jia-Ju Bai <baijiaju1990@xxxxxxxxx>

Ping & Larry, is this ok to take?


Not at the moment. In reviewing the code, I was unable to see how this situation could develop, and his backtrace did not mention any rtlwifi code. For that reason, I asked him to add printk stat4ements to show the last part of rtl_pci that executed correctly. In, he promised to do that, but I have not seen the result.

Hi Larry,

This patch is not related to the message you mentioned.
That message is about an occasional crash that I reported.
That crash occurred when request_irq() in rtl_pci_intr_mode_legacy() in rtl_pci_intr_mode_decide() fails.
I have added printk statements and try to reproduce and debug that crash, but that crash does not always occur, and I still do not know the root cause of that crash.

The null-pointer dereferences fixed by this patch are different from that crash, and they always occur when the related functions fail.
So please review these null-pointer dereferences, thanks :)

Best wishes,
Jia-Ju Bai

Sorry if I got confused. Kalle has dropped this patch, thus you will need to submit a new version.