PT-2026-51732 · Linux · Linux
Published
2026-06-24
·
Updated
2026-06-24
·
CVE-2026-52939
None
No severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
In the Linux kernel, the following vulnerability has been resolved:
net/rds: fix NULL deref in rds ib send cqe handler() on masked atomic completion
rds ib xmit atomic() always programs a masked atomic opcode
(IB WR MASKED ATOMIC CMP AND SWP or IB WR MASKED ATOMIC FETCH AND ADD)
for every RDS atomic cmsg. But the completion-side switch in
rds ib send unmap op() only handles the non-masked opcodes, so a masked
atomic completion falls through to default and returns rm == NULL while
send->s op is left set. rds ib send cqe handler() then dereferences the
NULL rm via rm->m final op, 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: rds ib send unmap op: unexpected opcode 0xd in WR!
Oops: general protection fault [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000190-0x0000000000000197]
RIP: rds ib send cqe handler+0x25c/0xb10 (net/rds/ib send.c:282)
Call Trace:
rds ib send cqe handler (net/rds/ib send.c:282)
poll scq (net/rds/ib cm.c:274)
rds ib tasklet fn send (net/rds/ib cm.c:294)
tasklet action common (kernel/softirq.c:943)
handle softirqs (kernel/softirq.c:573)
run ksoftirqd (kernel/softirq.c:479)
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 rds message.atomic union member, so
the existing container of()/rds ib send unmap atomic() body is correct
for them.
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Linux