CVE-2025-68258
BaseFortify
Publication date: 2025-12-16
Last updated on: 2025-12-18
Assigner: kernel.org
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| comedi | multiq3 | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-UNKNOWN |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability occurs in the Linux kernel's multiq3 driver, specifically in the multiq3_attach() function. It happens when crafted configuration options specify an excessively large number of channels for the encoder subdevice. This causes multiple calls to multiq3_encoder_reset() to run for an extended time, leading to task timeouts and blocking affected devices. The issue arises because the number of encoder chips and channels is not properly limited, allowing the system to hang during device attachment.
How can this vulnerability impact me? :
The vulnerability can cause tasks to become blocked for minutes, leading to system hangs or delays when opening or configuring devices using the multiq3 driver. This can degrade system performance and availability, potentially affecting any applications or services relying on these devices. However, it is noted that this issue is unlikely to be very dangerous for real-life devices.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for tasks blocked for extended periods due to the multiq3 driver, especially during open() or COMEDI_DEVCONFIG ioctl operations. Look for processes stuck in the comedi_open() function or related calls. You can use commands like 'ps -eo pid,comm,state,etimes | grep D' to find processes in uninterruptible sleep (D state) for a long time, or 'dmesg' to check for kernel logs indicating task timeouts related to multiq3_attach(). Additionally, monitoring for blocked tasks with messages similar to 'task syz.2.19:6067 blocked for more than 143 seconds' can help identify the issue.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation involves sanitizing the configuration inputs to the multiq3 driver, specifically limiting the number of encoder chips to a maximum of 4 chips, each with 2 channels, to prevent the task timeout issue. Avoid passing excessively large values to the s->n_chan parameter via it->options[2] in multiq3_attach(). If possible, update the Linux kernel to a version where this vulnerability is resolved to ensure proper input validation and prevent the blocking behavior.