linux-kernel - Re: [PATCH net] octeontx2-pf: Fix use-after-free bugs in otx2_sync

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: <564ad9c5.8bb9.199560a7661.Coremail.duoming@zju.edu.cn>
Date: Wed, 17 Sep 2025 12:59:10 +0800 (GMT+08:00)
From: duoming@....edu.cn
To: "Jakub Kicinski" <kuba@...nel.org>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, pabeni@...hat.com,
	edumazet@...gle.com, davem@...emloft.net, andrew+netdev@...n.ch,
	bbhushan2@...vell.com, hkelam@...vell.com, sbhatta@...vell.com,
	gakula@...vell.com, sgoutham@...vell.com
Subject: Re: [PATCH net] octeontx2-pf: Fix use-after-free bugs in
 otx2_sync_tstamp()

On Tue, 16 Sep 2025 16:36:43 -0700 Jakub Kicinski wrote:
> > Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
> > that the delayed work item is properly canceled before the otx2_ptp is
> > deallocated.
> 
> Please add info about how the bug was discovered and fix tested, same
> as the cnic patch.

Thank you for your suggestions. This bug was initially identified through
static analysis. To reproduce and test it, I simulated the OcteonTX2 PCI
device in QEMU and introduced artificial delays — such as adding calls to
ssleep() within the otx2_sync_tstamp() function — to increase the probability
of triggering the issue.

The otx2_sync_tstamp() function operates as a cyclic work item. 
The cancel_delayed_work_sync() function works by calling 
__cancel_work(work, ... | WORK_CANCEL_DISABLE), which attempts to 
remove the work item from the queue and sets the WORK_CANCEL_DISABLE 
flag to prevent the work item from being executed again. At the same 
time, it uses __flush_work(work, true) to perform a synchronous wait 
for any currently executing instance of the work item to finish running.

I will add info about how the bug was discovered and fix tested in patch v2.

Best regards,
Duoming Zhou