2022-01-22 00:49:51

by Johannes Berg

[permalink] [raw]
Subject: Re: [PATCH] iwlwifi: mvm: Fix potential NULL dereference for sta

On Fri, 2022-01-21 at 12:14 +0100, Takashi Iwai wrote:
> The recent fix for NULL sta in iwl_mvm_get_tx_rate() may still hit a
> potential NULL dereference, as iwl_mvm_sta_from_mac80211() is called
> unconditionally (although this doesn't seem happening, practically
> seen, thanks to the compiler optimization).
>

No objection to the patch, but I think the description isn't quite
right?

static inline struct iwl_mvm_sta *
iwl_mvm_sta_from_mac80211(struct ieee80211_sta *sta)
{
return (void *)sta->drv_priv;
}

looks like a dereference, but I _think_

struct ieee80211_sta {
[...]

/* must be last */
u8 drv_priv[] __aligned(sizeof(void *));
};


means it's just an address calculation, i.e. the same as if we had

return (void *)((u8 *)sta + offsetof(typeof(*sta), drv_priv));

no?

I guess technically it's still UB doing calculations on a NULL pointer,
but practically that's going to work.

Anyway, no objections :)

johannes


2022-01-22 00:51:39

by Takashi Iwai

[permalink] [raw]
Subject: Re: [PATCH] iwlwifi: mvm: Fix potential NULL dereference for sta

On Fri, 21 Jan 2022 12:22:05 +0100,
Johannes Berg wrote:
>
> On Fri, 2022-01-21 at 12:14 +0100, Takashi Iwai wrote:
> > The recent fix for NULL sta in iwl_mvm_get_tx_rate() may still hit a
> > potential NULL dereference, as iwl_mvm_sta_from_mac80211() is called
> > unconditionally (although this doesn't seem happening, practically
> > seen, thanks to the compiler optimization).
> >
>
> No objection to the patch, but I think the description isn't quite
> right?
>
> static inline struct iwl_mvm_sta *
> iwl_mvm_sta_from_mac80211(struct ieee80211_sta *sta)
> {
> return (void *)sta->drv_priv;
> }
>
> looks like a dereference, but I _think_
>
> struct ieee80211_sta {
> [...]
>
> /* must be last */
> u8 drv_priv[] __aligned(sizeof(void *));
> };
>
>
> means it's just an address calculation, i.e. the same as if we had
>
> return (void *)((u8 *)sta + offsetof(typeof(*sta), drv_priv));
>
> no?

Yeah, indeed, that won't access the member.

> I guess technically it's still UB doing calculations on a NULL pointer,
> but practically that's going to work.
>
> Anyway, no objections :)

OK, I'll submit v2 with rephrasing for avoid confusion.


Takashi