CVE-2026-52939

In the Linux kernel, the following vulnerability has been resolved:

net/rds: fix NULL deref in rdsibsendcqehandler() on masked atomic completion

rdsibxmitatomic() always programs a masked atomic opcode (IBWRMASKEDATOMICCMPANDSWP or IBWRMASKEDATOMICFETCHANDADD) for every RDS atomic cmsg. But the completion-side switch in rdsibsendunmapop() only handles the non-masked opcodes, so a masked atomic completion falls through to default and returns rm == NULL while send->sop is left set. rdsibsendcqehandler() then dereferences the NULL rm via rm->mfinalop, oopsing in softirq context. An unprivileged AF_RDS sendmsg() of an atomic cmsg over an active RDS/IB connection triggers it; on hardware that natively accepts masked atomics (mlx4, mlx5) no extra setup is needed.

RDS/IB: rdsibsendunmapop: unexpected opcode 0xd in WR! Oops: general protection fault [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197] RIP: rdsibsendcqehandler+0x25c/0xb10 (net/rds/ibsend.c:282) Call Trace: <IRQ> rdsibsendcqehandler (net/rds/ibsend.c:282) pollscq (net/rds/ibcm.c:274) rdsibtaskletfnsend (net/rds/ibcm.c:294) taskletactioncommon (kernel/softirq.c:943) handlesoftirqs (kernel/softirq.c:573) run_ksoftirqd (kernel/softirq.c:479) </IRQ> Kernel panic - not syncing: Fatal exception in interrupt

Handle the masked atomic opcodes in the same case as the non-masked ones: they map to the same struct rdsmessage.atomic union member, so the existing containerof()/rdsibsendunmapatomic() body is correct for them.