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
| ||
|
Date: Wed, 18 Aug 2021 02:05:45 -0700 From: Kees Cook <keescook@...omium.org> To: Johannes Berg <johannes@...solutions.net> Cc: linux-kernel@...r.kernel.org, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, linux-wireless@...r.kernel.org, netdev@...r.kernel.org, "Gustavo A. R. Silva" <gustavoars@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Andrew Morton <akpm@...ux-foundation.org>, dri-devel@...ts.freedesktop.org, linux-staging@...ts.linux.dev, linux-block@...r.kernel.org, linux-kbuild@...r.kernel.org, clang-built-linux@...glegroups.com, Rasmus Villemoes <linux@...musvillemoes.dk>, linux-hardening@...r.kernel.org Subject: Re: [PATCH v2 44/63] mac80211: Use memset_after() to clear tx status On Wed, Aug 18, 2021 at 10:06:51AM +0200, Johannes Berg wrote: > On Wed, 2021-08-18 at 09:08 +0200, Johannes Berg wrote: > > On Tue, 2021-08-17 at 23:05 -0700, Kees Cook wrote: > > > > > > @@ -275,12 +275,11 @@ static void carl9170_tx_release(struct kref *ref) > > > if (WARN_ON_ONCE(!ar)) > > > return; > > > > > > > > > > > > > > > - BUILD_BUG_ON( > > > - offsetof(struct ieee80211_tx_info, status.ack_signal) != 20); > > > - > > > - memset(&txinfo->status.ack_signal, 0, > > > - sizeof(struct ieee80211_tx_info) - > > > - offsetof(struct ieee80211_tx_info, status.ack_signal)); > > > + /* > > > + * Should this call ieee80211_tx_info_clear_status() instead of clearing > > > + * manually? txinfo->status.rates do not seem to be used here. > > > + */ > > > > Since you insist, I went digging :) > > > > It should not, carl9170_tx_fill_rateinfo() has filled the rate > > information before we get to this point. Ah-ha! Thanks for checking. I'll update the comment to explain the rationale here. > Otherwise, looks fine, FWIW. Thanks! > Are you going to apply all of these together somewhere? I (we) can't, > since memset_after() doesn't exist yet. Right, given the dependencies, I am expecting to just carry the whole series, since the vast majority of it has no binary changes, etc. I'm hoping to get it into -next soon, but we're uncomfortably close to the merge window. :P -- Kees Cook
Powered by blists - more mailing lists