CVE-2026-68419
High · 7.8CVSS
7.8
EPSS
0.1%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's RDMA networking code could let a logged-in user on the same machine trigger crashes or memory problems by misusing certain memory-registration functions.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Improper Input Validation
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
The flaw allows rereg_mr to be invoked on specially-registered MR objects that lack a valid mkey; the driver then emits a CQP command using a zero-initialized mkey, violating the expected invariant for these non-memory regions.
Why it matters to the business
Organizations running RDMA workloads on affected kernels face risk of local denial of service or memory corruption on systems that expose RDMA interfaces to untrusted local processes; the low EPSS and absence from KEV indicate limited observed exploitation so far, but the high CVSS local vector still warrants prompt patching in high-security or high-availability environments.
How an attack unfolds
An attacker with local access and permission to open RDMA devices creates a QP/CQ/SRQ (triggering the special ABI-marked MR registration), then directly calls rereg_mr on that object; the driver skips the normal checks and submits a CQP operation with mkey=0, resulting in undefined device behavior or kernel memory corruption.
How to fix it
Upgrade to a Linux kernel containing the fix that adds an explicit check to reject rereg_mr on these ABI-marked non-memory regions; apply the patch or newer mainline/stable release that resolves the issue in the irdma driver.
How to confirm the fix worked
Confirm the running kernel version includes the commit titled 'RDMA/irdma: Prevent rereg_mr for non-mem regions'; test that rereg_mr on specially-registered MR objects now returns an error instead of emitting a CQP command.
Typical attack path
- Obtain local shell on a system with RDMA/irdma driver loaded
- Open an RDMA device and trigger creation of a QP/CQ/SRQ to allocate a special ABI-marked MR
- Invoke the rereg_mr user-space API on the resulting MR handle
- Driver emits CQP command containing mkey=0
- Hardware or firmware processes the invalid command, leading to crash or corruption
How to detect it
Inspect kernel logs for RDMA/irdma error messages or CQP command failures around the time of suspected activity; look for unexpected calls to rereg_mr from user-space processes holding RDMA file descriptors.
What your security team should do
- Prioritize kernel updates on any hosts exposing RDMA devices to local users
- Review and restrict local access to /dev/infiniband/* devices where possible
- Monitor for kernel oops or RDMA device resets on systems running the vulnerable driver
The record
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent rereg_mr for non-mem regions When a QP/CQ/SRQ is created, a two step process is used where the buffer is allocated in userspace and explicitly registered with the normal reg_mr mechanism prior to creating the actual QP/CQ/SRQ object. These special registrations are indicated via an ABI field so the driver knows that they do not have a valid mkey and to skip the actual CQP command submission. Since these are real MR objects from the core's perspective, it is possible for a user application to invoke rereg_mr on them and cause a real CQP op to be emitted with the zero-initialized mkey value of 0. Fix this by preventing rereg_mr on these special regions.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|