[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2024022115-vixen-brought-6058@gregkh>
Date: Wed, 21 Feb 2024 11:57:22 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Ajay Kaher <ajay.kaher@...adcom.com>
Cc: stable@...r.kernel.org, pablo@...filter.org, kadlec@...filter.org,
fw@...len.de, davem@...emloft.net, netfilter-devel@...r.kernel.org,
coreteam@...filter.org, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, alexey.makhalov@...adcom.com,
florian.fainelli@...adcom.com, vasavi.sirnapalli@...adcom.com,
Dan Carpenter <dan.carpenter@...aro.org>,
Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH v5.4.y] netfilter: nf_tables: fix pointer math issue in
nft_byteorder_eval()
On Mon, Feb 05, 2024 at 10:14:53AM +0530, Ajay Kaher wrote:
> From: Dan Carpenter <dan.carpenter@...aro.org>
>
> commit c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63 upstream.
>
> The problem is in nft_byteorder_eval() where we are iterating through a
> loop and writing to dst[0], dst[1], dst[2] and so on... On each
> iteration we are writing 8 bytes. But dst[] is an array of u32 so each
> element only has space for 4 bytes. That means that every iteration
> overwrites part of the previous element.
>
> I spotted this bug while reviewing commit caf3ef7468f7 ("netfilter:
> nf_tables: prevent OOB access in nft_byteorder_eval") which is a related
> issue. I think that the reason we have not detected this bug in testing
> is that most of time we only write one element.
>
> Fixes: ce1e7989d989 ("netfilter: nft_byteorder: provide 64bit le/be conversion")
> Signed-off-by: Dan Carpenter <dan.carpenter@...aro.org>
> Signed-off-by: Pablo Neira Ayuso <pablo@...filter.org>
> Signed-off-by: Sasha Levin <sashal@...nel.org>
> [Ajay: Modified to apply on v5.4.y]
> Signed-off-by: Ajay Kaher <ajay.kaher@...adcom.com>
> ---
All now queued up, thanks.
greg k-h
Powered by blists - more mailing lists