[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241104160713.GE2118587@kernel.org>
Date: Mon, 4 Nov 2024 16:07:13 +0000
From: Simon Horman <horms@...nel.org>
To: Tuo Li <islituo@...il.com>
Cc: ayush.sawal@...lsio.com, andrew+netdev@...n.ch, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
almasrymina@...gle.com, dtatulea@...dia.com,
jacob.e.keller@...el.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, baijiaju1990@...il.com
Subject: Re: [PATCH] chcr_ktls: fix a possible null-pointer dereference in
chcr_ktls_dev_add()
On Thu, Oct 31, 2024 at 12:23:52AM +1100, Tuo Li wrote:
> There is a possible null-pointer dereference related to the wait-completion
> synchronization mechanism in the function chcr_ktls_dev_add().
>
> Consider the following execution scenario:
>
> chcr_ktls_cpl_act_open_rpl() //641
> u_ctx = adap->uld[CXGB4_ULD_KTLS].handle; //686
> if (u_ctx) { //687
> complete(&tx_info->completion); //704
>
> The variable u_ctx is checked by an if statement at Line 687, which means
> it can be NULL. Then, complete() is called at Line 704, which will wake
> up wait_for_completion_xxx().
>
> Consider the wait_for_completion_timeout() in chcr_ktls_dev_add():
>
> chcr_ktls_dev_add() //412
> u_ctx = adap->uld[CXGB4_ULD_KTLS].handle; //432
> wait_for_completion_timeout(&tx_info->completion, 30 * HZ); //551
> xa_erase(&u_ctx->tid_list, tx_info->tid); //580
>
> The variable u_ctx is dereferenced without being rechecked at Line 580
> after the wait_for_completion_timeout(), which can introduce a null-pointer
> dereference. Besides, the variable u_ctx is also checked at Line 442 in
> chcr_ktls_dev_add(), which indicates that u_ctx is likely to be NULL in
> some execution contexts.
>
> To fix this possible null-pointer dereference, a NULL check is put ahead of
> the call to xa_erase().
>
> This potential bug was discovered using an experimental static analysis
> tool developed by our team. The tool deduces complete() and
> wait_for_completion() pairs using alias analysis. It then applies data
> flow analysis to detect null-pointer dereferences across synchronization
> points.
>
> Fixes: 65e302a9bd57 ("cxgb4/ch_ktls: Clear resources when pf4 device is removed")
> Signed-off-by: Tuo Li <islituo@...il.com>
Hi Tuo Li,
I do see that the checking of u_ctx is inconsistent,
but it is not clear to me that is because one part is too defensive
or, OTOH, there is a bug as you suggest. And I think that we need
more analysis to determine which case it is.
Also, if it is the case that there is a bug as you suggest, after a quick
search, I think it also exists in at least one other place in this file.
...
Powered by blists - more mailing lists