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] [day] [month] [year] [list]
Message-ID: <20250916072836.239631ef@kernel.org>
Date: Tue, 16 Sep 2025 07:28:36 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Duoming Zhou <duoming@....edu.cn>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, pabeni@...hat.com,
 edumazet@...gle.com, davem@...emloft.net, andrew+netdev@...n.ch
Subject: Re: [PATCH v2 net] cnic: Fix use-after-free bugs in
 cnic_delete_task

On Tue, 16 Sep 2025 21:08:18 +0800 Duoming Zhou wrote:
> The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),
> which does not guarantee that the delayed work item 'delete_task' has
> fully completed if it was already running. Additionally, the delayed work
> item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only
> blocks and waits for work items that were already queued to the
> workqueue prior to its invocation. Any work items submitted after
> flush_workqueue() is called are not included in the set of tasks that the
> flush operation awaits. This means that after the cyclic work items have
> finished executing, a delayed work item may still exist in the workqueue.
> This leads to use-after-free scenarios where the cnic_dev is deallocated
> by cnic_free_dev(), while delete_task remains active and attempt to
> dereference cnic_dev in cnic_delete_task().
> 
> A typical race condition is illustrated below:
> 
> CPU 0 (cleanup)              | CPU 1 (delayed work callback)
> cnic_netdev_event()          |
>   cnic_stop_hw()             | cnic_delete_task()
>     cnic_cm_stop_bnx2x_hw()  | ...
>       cancel_delayed_work()  | /* the queue_delayed_work()
>       flush_workqueue()      |    executes after flush_workqueue()*/
>                              | queue_delayed_work()
>   cnic_free_dev(dev)//free   | cnic_delete_task() //new instance
>                              |   dev = cp->dev; //use
> 
> Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
> that the cyclic delayed work item is properly canceled and any executing
> delayed work has finished before the cnic_dev is deallocated.

Once again, you must include how you discovered and tested the patch
in the commit message.

> Fixes: fdf24086f475 ("cnic: Defer iscsi connection cleanup")
> Signed-off-by: Duoming Zhou <duoming@....edu.cn>
> ---
> Changes in v2:
>   - Make commit messages more clearer.
> 
>  drivers/net/ethernet/broadcom/cnic.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/cnic.c b/drivers/net/ethernet/broadcom/cnic.c
> index a9040c42d2ff..73dd7c25d89e 100644
> --- a/drivers/net/ethernet/broadcom/cnic.c
> +++ b/drivers/net/ethernet/broadcom/cnic.c
> @@ -4230,7 +4230,7 @@ static void cnic_cm_stop_bnx2x_hw(struct cnic_dev *dev)
>  
>  	cnic_bnx2x_delete_wait(dev, 0);
>  
> -	cancel_delayed_work(&cp->delete_task);
> +	cancel_delayed_work_sync(&cp->delete_task);
>  	flush_workqueue(cnic_wq);

You should delete the flush, it was supposed to prevent the issue
you're now resolving with the _sync().

>  	if (atomic_read(&cp->iscsi_conn) != 0)


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ