CVE-2026-90319: rapidio: clear mport->net when rio_add_net() fails
In the Linux kernel, the following vulnerability has been resolved:
rapidio: clear mport->net when rioaddnet() fails
rioallocnet() stores the newly allocated rionet in mport->net before rioscanallocnet() registers the device.
If rioaddnet() fails, rioscanallocnet() drops the device reference with putdevice(), which releases the rionet through the device release callback. However, mport->net is left pointing at the freed object.
A later mport unregister path can then dereference the dangling mport->net pointer and may try to free the same rionet again.
Clear mport->net in the rioaddnet() failure path, matching the cleanup done for the destID table allocation failure path.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In the RapidIO driver, clear mport->net when rio_add_net() fails (matching cleanup), so mport->net does not remain pointing at a freed rio_net object.
rapidio (kernel driver) mport->net pointer handling on rio_add_net() failure = Clear mport->net in the rio_add_net() failure path (set to NULL) to prevent double-free/dangling reference
Event History
Frequently Asked Questions
What conditions are required to trigger the stale pointer?
rio_add_net() must fail after rio_alloc_net() has stored the newly allocated rio_net in mport->net. The affected mport must subsequently be unregistered, causing cleanup to dereference the stale pointer.
What could happen during the later unregister operation?
The unregister path may dereference a pointer to an already freed rio_net and may attempt to free that object again. This creates a use-after-free and potential double-free condition in the RapidIO cleanup path.
How can I determine whether a system encountered the vulnerable failure path?
Look for failures from rio_add_net() followed by mport unregistration activity. The description does not provide specific log messages or other indicators for detecting this condition.
What mitigation is available if the fix cannot be applied immediately?
The provided information identifies no workaround. Reducing exposure would require avoiding the sequence in which rio_add_net() fails and the affected mport is later unregistered.