CVE-2023-54235
Awaiting Analysis Awaiting Analysis - Queue
BaseFortify

Publication date: 2025-12-30

Last updated on: 2025-12-31

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: PCI/DOE: Fix destroy_work_on_stack() race The following debug object splat was observed in testing: ODEBUG: free active (active state 0) object: 0000000097d23782 object type: work_struct hint: doe_statemachine_work+0x0/0x510 WARNING: CPU: 1 PID: 71 at lib/debugobjects.c:514 debug_print_object+0x7d/0xb0 ... Workqueue: pci 0000:36:00.0 DOE [1 doe_statemachine_work RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? debug_print_object+0x7d/0xb0 ? __pfx_doe_statemachine_work+0x10/0x10 debug_object_free.part.0+0x11b/0x150 doe_statemachine_work+0x45e/0x510 process_one_work+0x1d4/0x3c0 This occurs because destroy_work_on_stack() was called after signaling the completion in the calling thread. This creates a race between destroy_work_on_stack() and the task->work struct going out of scope in pci_doe(). Signal the work complete after destroying the work struct. This is safe because signal_task_complete() is the final thing the work item does and the workqueue code is careful not to access the work struct after.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-30
Last Modified
2025-12-31
Generated
2026-05-07
AI Q&A
2025-12-30
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Currently, no data is known.
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 involves a race condition in the Linux kernel related to the function destroy_work_on_stack(). The issue occurs because destroy_work_on_stack() is called after signaling the completion of a work item, creating a race between destroying the work struct and the work struct going out of scope. This can lead to debug object splats and potential instability. The fix involves signaling the work completion only after the work struct has been safely destroyed.


How can this vulnerability impact me? :

This vulnerability can cause race conditions that may lead to kernel instability or crashes due to improper handling of work structs in the PCI DOE subsystem. It may affect system reliability and could potentially be exploited to cause denial of service or other unintended behavior in systems using the affected Linux kernel code.


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

This vulnerability can be detected by observing debug object splat messages in the kernel logs indicating a race condition with destroy_work_on_stack(). Look for kernel warnings similar to: 'ODEBUG: free active (active state 0) object' and 'WARNING: CPU: ... at lib/debugobjects.c:514 debug_print_object'. You can check kernel logs using commands like 'dmesg | grep debug_print_object' or 'journalctl -k | grep debug_print_object' to identify these messages.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, ensure that the work struct is destroyed before signaling completion. Specifically, modify the code to signal work completion only after destroy_work_on_stack() has been called, as signaling completion before destroying the work struct creates a race condition. Applying the vendor's patch or updating to a kernel version where this fix is included is recommended.


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