CVE-2025-38459
BaseFortify
Publication date: 2025-07-25
Last updated on: 2025-11-03
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linux | linux_kernel | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability in the Linux kernel's ATM subsystem involves an infinite recursive call in the function clip_push(). It occurs when the ioctl ATMARP_MKIP is called more than once. The first call sets clip_push() to a function pointer, but the second call copies this pointer incorrectly, leading to an infinite recursion when the socket is closed. This recursion causes a stack overflow and a kernel crash. The fix prevents the second ioctl call by checking a user_back pointer and uses locking to avoid race conditions.
How can this vulnerability impact me? :
This vulnerability can cause a kernel crash due to infinite recursion and stack overflow when certain ioctl calls are made multiple times. This can lead to denial of service (DoS) on affected systems running the vulnerable Linux kernel, potentially disrupting normal operations and requiring a system reboot.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for kernel crashes or stack guard page hits related to the atm clip_push() function, especially after ioctl(ATMARP_MKIP) calls. Checking kernel logs (e.g., using 'dmesg' or 'journalctl -k') for messages about 'stack guard page was hit' or 'clip_push' recursion can help identify the issue. Specific commands to check kernel logs include: 'dmesg | grep clip_push' or 'journalctl -k | grep clip_push'.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves preventing multiple ioctl(ATMARP_MKIP) calls on the same socket to avoid triggering the infinite recursion. Applying the patch that checks vcc->user_back to prevent the second ioctl call is necessary. Additionally, updating the Linux kernel to a version that includes this fix (post 6.16.0-rc4-syzkaller) is recommended. Using lock_sock() to prevent race conditions as done in the fix is also part of the mitigation.