From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Dongliang Mu <dzm91@hust.edu.cn>, Kalle Valo <kvalo@kernel.org>,
Sujith Manoharan <c_manoha@qca.qualcomm.com>,
"John W. Linville" <linville@tuxdriver.com>
Cc: hust-os-kernel-patches@googlegroups.com,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ath9k: fix null-ptr-deref in ath_chanctx_event
Date: Fri, 01 Sep 2023 13:16:00 +0200 [thread overview]
Message-ID: <87il8uta8f.fsf@toke.dk> (raw)
In-Reply-To: <317b9482-d750-9093-e891-21f73feeac0c@hust.edu.cn>
Dongliang Mu <dzm91@hust.edu.cn> writes:
> On 2023/9/1 18:41, 'Toke Høiland-Jørgensen' via HUST OS Kernel
> Contribution wrote:
>> Dongliang Mu <dzm91@hust.edu.cn> writes:
>>
>>> Smatch reports:
>>>
>>> ath_chanctx_event() error: we previously assumed 'vif' could be null
>>>
>>> The function ath_chanctx_event can be called with vif argument as NULL.
>>> If vif is NULL, ath_dbg can trigger a null pointer dereference.
>>>
>>> Fix this by adding a null pointer check.
>>>
>>> Fixes: 878066e745b5 ("ath9k: Add more debug statements for channel context")
>>> Signed-off-by: Dongliang Mu <dzm91@hust.edu.cn>
>>> ---
>>> drivers/net/wireless/ath/ath9k/channel.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath9k/channel.c b/drivers/net/wireless/ath/ath9k/channel.c
>>> index 571062f2e82a..e343c8962d14 100644
>>> --- a/drivers/net/wireless/ath/ath9k/channel.c
>>> +++ b/drivers/net/wireless/ath/ath9k/channel.c
>>> @@ -576,7 +576,9 @@ void ath_chanctx_event(struct ath_softc *sc, struct ieee80211_vif *vif,
>>> if (sc->sched.state != ATH_CHANCTX_STATE_WAIT_FOR_BEACON)
>>> break;
>>>
>>> - ath_dbg(common, CHAN_CTX, "Preparing beacon for vif: %pM\n", vif->addr);
>>> + if (vif)
>>> + ath_dbg(common, CHAN_CTX,
>>> + "Preparing beacon for vif: %pM\n", vif->addr);
>> Please don't send patches for static checker errors without actually
>> checking if there is a valid bug. Which there isn't in this case.
>
> Before sending this patch, I searched in the code, there are many call
> sites of ath_chanctx_event with argument vif as NULL.
>
> Functions calling this function: ath_chanctx_event
>
> File Function Line
> 0 beacon.c ath9k_beacon_tasklet 459 ath_chanctx_event(sc, vif,
> ATH_CHANCTX_EVENT_BEACON_PREPARE);
But only this one has ATH_CHANCTX_EVENT_BEACON_PREPARE as an argument,
which is required to hit the code path you are changing.
> 1 channel.c ath_chanctx_check_active 321 ath_chanctx_event(sc, NULL,
> 2 channel.c ath_chanctx_beacon_sent_ev 781 ath_chanctx_event(sc, NULL, ev);
> 3 channel.c ath_chanctx_beacon_recv_ev 787 ath_chanctx_event(sc, NULL, ev);
> 4 channel.c ath_chanctx_timer 1054 ath_chanctx_event(sc, NULL,
> ATH_CHANCTX_EVENT_TSF_TIMER);
> 5 channel.c ath_chanctx_set_next 1321 ath_chanctx_event(sc, NULL,
> ATH_CHANCTX_EVENT_SWITCH);
> 6 channel.c ath9k_p2p_ps_timer 1566 ath_chanctx_event(sc, NULL,
> ATH_CHANCTX_EVENT_TSF_TIMER);
> 7 main.c ath9k_sta_state 1671 ath_chanctx_event(sc, vif,
> 8 main.c ath9k_remove_chanctx 2577 ath_chanctx_event(sc, NULL,
> ATH_CHANCTX_EVENT_UNASSIGN);
> 9 xmit.c ath_tx_edma_tasklet 2749 ath_chanctx_event(sc, NULL,
>
> This NULL parameters would cause some abnormal behaviors.
>
>> Specifically, that branch of the switch statement dereferences the avp
>> pointer, which will be NULL if 'vif' is. Meaning we will have crashed
>> way before reaching this statement if vif is indeed NULL.
> Yeah, you are right. However, no matter where or which variable causing
> the null-ptr-def crash, the crash is there.
There is no crash, see above.
-Toke
next prev parent reply other threads:[~2023-09-01 11:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-01 8:07 [PATCH] ath9k: fix null-ptr-deref in ath_chanctx_event Dongliang Mu
2023-09-01 10:41 ` Toke Høiland-Jørgensen
2023-09-01 10:59 ` Dongliang Mu
2023-09-01 11:16 ` Toke Høiland-Jørgensen [this message]
2023-09-01 11:21 ` Dongliang Mu
2023-09-01 12:24 ` Toke Høiland-Jørgensen
2023-09-07 11:02 ` Dan Carpenter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87il8uta8f.fsf@toke.dk \
--to=toke@toke.dk \
--cc=c_manoha@qca.qualcomm.com \
--cc=dzm91@hust.edu.cn \
--cc=hust-os-kernel-patches@googlegroups.com \
--cc=kvalo@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox