CVE-2026-92505
NoneCVSS
—
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A small bug in the Linux kernel's handling of certain AMD memory-management debug files could cause unexpected crashes if someone with deep system access uses them incorrectly.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Theoretical
- Impact
- Other
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The vulnerability causes undefined behavior when the for_each_pci_segment() loop in the devid_write debugfs handler completes without a match, leaving the pci_seg pointer referencing the list head instead of a valid structure, after which pci_seg->id is accessed.
Why it matters to the business
Low-probability kernel instability or crashes on AMD IOMMU-enabled Linux systems when debugfs interfaces are used; no known active exploitation or ransomware use reduces urgency but still requires patching to maintain system reliability.
How an attack unfolds
An attacker with local write access to the AMD IOMMU debugfs entry supplies a device ID that fails to match any PCI segment; the loop exits without a valid pointer, resulting in an invalid memory dereference that triggers undefined behavior.
How to fix it
Apply the upstream kernel fix that moves the success path inside the loop and returns -EINVAL after the loop when no matching segment is found; rebuild and deploy the patched kernel image.
How to confirm the fix worked
Inspect the iommu/amd debugfs source to confirm the loop now returns success inside the iteration and explicitly returns -EINVAL on exit; test by writing both matching and non-matching device IDs and verifying expected error codes without crashes.
Typical attack path
- Obtain local privileged access to the target system
- Navigate to the iommu/amd debugfs directory
- Write a non-matching segment identifier to the devid_write file
- Trigger the loop completion path that dereferences the invalid pointer
How to detect it
Review kernel logs and dmesg for oops or undefined-behavior traces referencing iommu/amd and devid_write; correlate with audit logs showing writes to the corresponding debugfs file.
What your security team should do
- Prioritize kernel updates for all AMD IOMMU hosts within standard change windows
- Disable or restrict debugfs mounts on production systems where feasible
- Include iommu/amd debugfs paths in kernel oops monitoring rules
The record
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix undefined behavior in devid_write debugfs function When for_each_pci_segment() loop completes without finding a matching segment, the pci_seg pointer is not NULL but points to an invalid memory location (the list head). Accessing pci_seg->id after the loop causes undefined behavior. Fix this by handling the successful case inside the loop and returning -EINVAL after the loop if no matching segment is found.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|