lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 21 Jan 2022 12:22:05 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     Takashi Iwai <tiwai@...e.de>,
        Luca Coelho <luciano.coelho@...el.com>
Cc:     Oliver Neukum <oneukum@...e.de>, linux-wireless@...r.kernel.org,
        linux-kernel@...r.kernel.org
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ