CVE-2026-80645
High · 8.1CVSS
8.1
EPSS
0.4%
Published
Aug 28, 2026
CISA due date
—
Cloudanix analysis
A coding mistake in a Linux driver for certain high-speed hardware can let an attacker on the same network crash the computer or take control of it.
- Exploitation
- Adjacent Network
- Attacker needs
- None
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Low
- Patch risk
- Low
What it actually does
Use of an uninitialized or stale 'found' flag inside a list_for_each loop in tsi721_db_dpc allows the loop iterator 'dbell' to exit pointing at invalid memory after the first successful doorbell match, resulting in a subsequent bad dereference.
Why it matters to the business
A local or adjacent attacker can trigger a kernel crash or memory corruption on systems using the tsi721 RapidIO controller, leading to denial of service or potential privilege escalation with high impact on availability and integrity.
How an attack unfolds
An attacker with network-adjacent access sends crafted RapidIO doorbell messages that cause the driver to iterate the doorbell list; because the found flag is not reset each iteration, the stale state causes the iterator to reference freed or invalid memory, dereferencing it on the next operation.
How to fix it
Apply the upstream fix that resets the found variable to false at the start of each list iteration and moves the variable declaration inside the loop; rebuild and deploy an updated Linux kernel containing the patch for the rapidio/tsi721 driver.
How to confirm the fix worked
Confirm the source change in drivers/rapidio/devices/tsi721.c that initializes found=false inside the loop body before the list_for_each iteration; test that multiple doorbell matches no longer leave a stale flag and that the driver no longer dereferences invalid memory under load.
Typical attack path
- Gain network-adjacent position to the target RapidIO fabric
- Send a sequence of doorbell messages that match the first entry then additional entries
- Trigger the tsi721_db_dpc handler while the list state allows the stale found flag
- Force the loop to exit with dbell pointing outside valid memory
- Induce the subsequent dereference to crash or corrupt kernel memory
How to detect it
Review kernel logs for oops/panic entries containing tsi721_db_dpc and list iteration faults; inspect dmesg or journalctl for rapidio driver warnings around doorbell handling after RapidIO traffic is observed.
What your security team should do
- Prioritize kernel updates for any hosts exposing the tsi721 RapidIO driver within the next 30 days given the 32-day publication window and stable EPSS
- Audit systems for presence of the tsi721 driver and disable the RapidIO subsystem if not required
- Monitor kernel oops and panic logs for tsi721_db_dpc-related dereference faults
The record
In the Linux kernel, the following vulnerability has been resolved: rapidio/tsi721: prevent a bad dereference in tsi721_db_dpc() With a list_for_each() loop, if we don't find the item we are looking for in the list, then the loop exits with the iterator, which is "dbell" in this loop, pointing to invalid memory. This code uses the "found" variable to determine if we have found the doorbell we are looking for or not. However, the problem that the "found" variable needs to be set to false at the start of each iteration, otherwise after the first correct doorbell, then everything is marked as found. Reset the "found" to false at the start of the iteration and move the variable inside the loop.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|