Linux: Use After Free
CVE-2025-39944 is a high-severity use after free vulnerability in Linux, with a CVSS 3.1 base score of 7.8 out of 10. It can be exploited with local access to the system by an attacker with a low-privileged account, without any action from a user. The record lists versions 2786879aebf363806a13d41e8d5f99202ddd23d9, d2cfefa14ce8137b17f99683f968bebf134b6a48, ff27e23b311fed4d25e3852e27ba693416d4c7b3 as the first without the flaw, so updating Linux to one of those releases or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 0.15% chance of exploitation within 30 days, which is low compared with other CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update Linux to 2786879aebf363806a13d41e8d5f99202ddd23d9 or d2cfefa14ce8137b17f99683f968bebf134b6a48 or ff27e23b311fed4d25e3852e27ba693416d4c7b3 or 5ca20bb7b4bde72110c3ae78423cbfdd0157aa36, whichever matches your release line, or a later version.
- Update Linux Kernel to 6.1.154 or 6.6.108 or 6.12.49 or 6.16.9, whichever matches your release line, or a later version.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Linux | Linux | 2958d17a898416c6193431676f6130b68a2cb9fc up to, but not including, 2786879aebf363806a13d41e8d5f99202ddd23d9; 2958d17a898416c6193431676f6130b68a2cb9fc up to, but not including, d2cfefa14ce8137b17f99683f968bebf134b6a48; 2958d17a898416c6193431676f6130b68a2cb9fc up to, but not including, ff27e23b311fed4d25e3852e27ba693416d4c7b3; 2958d17a898416c6193431676f6130b68a2cb9fc up to, but not including, 5ca20bb7b4bde72110c3ae78423cbfdd0157aa36; 2958d17a898416c6193431676f6130b68a2cb9fc up to, but not including, f8b4687151021db61841af983f1cb7be6915d4ef; 6.1 | 2786879aebf363806a13d41e8d5f99202ddd23d9, d2cfefa14ce8137b17f99683f968bebf134b6a48, ff27e23b311fed4d25e3852e27ba693416d4c7b3, 5ca20bb7b4bde72110c3ae78423cbfdd0157aa36, f8b4687151021db61841af983f1cb7be6915d4ef |
| Linux | Linux Kernel | 6.1 up to, but not including, 6.1.154; 6.2 up to, but not including, 6.6.108; 6.7 up to, but not including, 6.12.49; 6.13 up to, but not including, 6.16.9; 6.17 | 6.1.154, 6.6.108, 6.12.49, 6.16.9 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- LocalThe attacker needs local access or must trick a user into running something.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- LowA basic user account is enough.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by NVD.
| Scoring system | Score | Severity | Scored by |
|---|---|---|---|
| CVSS 3.1 | 7.8 | High | CNA |
| CVSS 3.1 | 7.8 | High | NVD |
Official 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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory belongs to the code that operates on the new pointer.
How developers prevent this class of flaw
- Choose a language that provides automatic memory management.
- When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
- git.kernel.org/stable/c/2786879aebf363806a13d41e8d5f99202ddd23d9
- git.kernel.org/stable/c/5ca20bb7b4bde72110c3ae78423cbfdd0157aa36
- git.kernel.org/stable/c/d2cfefa14ce8137b17f99683f968bebf134b6a48
- git.kernel.org/stable/c/f8b4687151021db61841af983f1cb7be6915d4ef
- git.kernel.org/stable/c/ff27e23b311fed4d25e3852e27ba693416d4c7b3
Recent Use After Free vulnerabilities
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
- 7.8 High severity
Spotted an error? Tell us.