[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220721070707.GF2316@kadam>
Date: Thu, 21 Jul 2022 10:07:07 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: xiaolinkui <xiaolinkui@...il.com>
Cc: kvalo@...nel.org, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, gustavoars@...nel.org,
quic_jjohnson@...cinc.com, keescook@...omium.org, johan@...nel.org,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, Linkui Xiao <xiaolinkui@...inos.cn>
Subject: Re: [PATCH] wireless: ath6kl: fix out of bound from length.
On Thu, Jul 21, 2022 at 11:21:58AM +0800, xiaolinkui wrote:
> From: Linkui Xiao <xiaolinkui@...inos.cn>
>
> If length from debug_buf.length is 4294967293 (0xfffffffd), the result of
> ALIGN(size, 4) will be 0.
>
> length = ALIGN(length, 4);
>
> In case of length == 4294967293 after four-byte aligned access, length will
> become 0.
>
> ret = ath6kl_diag_read(ar, address, buf, length);
>
> will fail to read.
It looks like "length" is untrustworthy. Generally, I kind of distrust
all endian data by default, but I dug a bit deeper and I don't trust it.
Unfortunately, if "length" is larger than ATH6KL_FWLOG_PAYLOAD_SIZE
(1500) then we are screwed. Can you add a check for that instead?
Please check my work on this because I didn't look *super* carefully.
No need to make any changes to the types, just add the upper bounds
check on ATH6KL_FWLOG_PAYLOAD_SIZE. The type changes didn't fix the bug
on 32 bit systems anyway...
regards,
dan carpenter
Powered by blists - more mailing lists