CVE-2025-39944
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-04

Last updated on: 2026-04-06

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp() The original code relies on cancel_delayed_work() in otx2_ptp_destroy(), which does not ensure that the delayed work item synctstamp_work has fully completed if it was already running. This leads to use-after-free scenarios where otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_work remains active and attempts to dereference otx2_ptp in otx2_sync_tstamp(). Furthermore, the synctstamp_work is cyclic, the likelihood of triggering the bug is nonnegligible. A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAF This is confirmed by a KASAN report: BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800aa09a18 by task bash/136 ... Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ> ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... 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. 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 within the otx2_sync_tstamp() function to increase the likelihood of triggering the bug.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-04
Last Modified
2026-04-06
Generated
2026-05-07
AI Q&A
2025-10-04
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
marvell octeontx2 *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a use-after-free bug in the Linux kernel's octeontx2-pf driver, specifically in the otx2_sync_tstamp() function. The issue arises because the code uses cancel_delayed_work() to stop a delayed work item, but this function does not guarantee that the work has fully completed if it was already running. As a result, the otx2_ptp structure can be freed while the delayed work is still active and tries to access the freed memory, leading to a use-after-free condition. This is a race condition where one CPU frees the resource while another CPU is still using it. The fix involves replacing cancel_delayed_work() with cancel_delayed_work_sync() to ensure the delayed work is fully canceled before freeing the resource.


How can this vulnerability impact me? :

This vulnerability can lead to use-after-free memory corruption in the Linux kernel, which may cause system instability, crashes, or potentially allow an attacker to execute arbitrary code with kernel privileges. Because the delayed work is cyclic and the race condition is non-negligible, the bug can be triggered in real-world scenarios, potentially compromising system reliability and security.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring for use-after-free bugs related to the otx2_sync_tstamp() function in the Linux kernel, particularly involving the octeontx2-pf driver. Detection may involve checking kernel logs for KASAN (Kernel Address Sanitizer) reports indicating slab-use-after-free errors referencing __run_timer_base and otx2_ptp structures. Specific commands to check kernel logs include: 'dmesg | grep -i kasan' or 'journalctl -k | grep -i kasan'. Additionally, reproducing the issue may require simulating the OcteonTX2 PCI device in QEMU with artificial delays in otx2_sync_tstamp(), but this is more for testing than detection on production systems.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability immediately, update the Linux kernel to a version where the fix is applied. The fix involves replacing cancel_delayed_work() with cancel_delayed_work_sync() in the otx2_ptp_destroy() function to ensure the delayed work item synctstamp_work is fully canceled before deallocating otx2_ptp, preventing use-after-free scenarios. If updating is not immediately possible, avoid unloading or removing the octeontx2-pf driver or the affected PCI device until a patch is applied.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart