linux-kernel - Re: [PATCH v2] wifi: mac80211: Avoid address calculations via out of bounds array indexing

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]

Message-ID: <20240531132431.GH123401@kernel.org>
Date: Fri, 31 May 2024 14:24:31 +0100
From: Simon Horman <horms@...nel.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: Kenton Groombridge <concord@...too.org>, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
	linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v2] wifi: mac80211: Avoid address calculations via out of
 bounds array indexing

On Thu, May 23, 2024 at 11:35:37AM +0200, Johannes Berg wrote:
> On Fri, 2024-05-17 at 21:45 +0100, Simon Horman wrote:
> > 
> > FWWIW, it seems unfortunate to me that the __counted_by field (n_channels)
> > is set some distance away from the allocation of the flex-array (channels)
> > whose bounds it checks. It seems it would be pretty easy for a bug in the
> > code being updated here to result in an overrun.
> > 
> 
> In a way, this is a more general problem, this allocates the max we know
> we might need, but then filter it down. It'd have to iterate twice to
> actually allocate the "correct" size, but then you could still have bugs
> by having different filter conditions in the two loops ...

Yes, I agree this problem is more general than this patch or the code it
updates.

> Don't see any good solutions to this kind of code?

I was hoping you might :)