linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] IB/mad: fix UAF and double-free in RMPP receive reassembly
@ 2026-09-22 15:23 Dairui Zhang
  2026-09-22 15:33 ` sashiko-bot
  2026-09-29 13:29 ` Leon Romanovsky
  0 siblings, 2 replies; 3+ messages in thread
From: Dairui Zhang @ 2026-09-22 15:23 UTC (permalink / raw)
  To: linux-rdma
  Cc: security, Leon Romanovsky, Jason Gunthorpe, Dairui Zhang, stable

mad_rmpp_recv.state is protected by two locks that do not exclude
each other: recv_timeout_handler() (port workqueue) uses agent->lock,
continue_rmpp() (CQ softirq) uses rmpp_recv->lock. Nothing serializes
the check-then-set sequence on the state word:

  T1 (CQ softirq)              T2 (port workqueue)
  continue_rmpp()
    lock(rmpp_recv->lock)
    state == ACTIVE  [passes]
                               recv_timeout_handler()
                                 lock(agent->lock)
                                 state = TIMEOUT
                                 list_del(&rmpp_recv->list)
                                 unlock(agent->lock)
                                 destroy_rmpp_recv()
                                   wait_for_completion()
                                   [blocks on T1's ref]
    state = COMPLETE
    unlock(rmpp_recv->lock)
    complete_rmpp()
      queue cleanup_work (+10s)
    deref()
                               [unblocks]
                               kfree(rmpp_recv)
                               ib_free_recv_mad(done_wc)

  +10s: recv_cleanup_handler() runs lock/list_del/destroy on the
        freed rmpp_recv -> UAF write and double free; nothing can
        cancel that cleanup_work anymore, the entry is already off
        agent->rmpp_list. done_wc is also returned to
        ib_mad_complete_recv() and freed again -> UAF read and
        double free.

Reaching this requires sending MADs to a kernel RMPP agent from the
InfiniBand/RoCE fabric: the per-port sa_query agent accepts subnet
manager responses whose SLID/GID/TID are not authenticated on the
fabric, and legacy user_mad agents registered without
IB_USER_MAD_USER_RMPP start reassembly on any incoming RMPP DATA
MAD with an attacker-chosen TID, no in-flight send required. The
attacker controls segment timing and can run many transactions in
parallel (agent->rmpp_list has no cap), so landing the
microseconds-wide receive critical section on the 40-second timeout
boundary is a matter of patience, not luck.

Unify state transitions under rmpp_recv->lock in
recv_timeout_handler(), keeping list manipulation under agent->lock
(which preserves the agent->lock -> rmpp_recv->lock ordering used
by continue_rmpp()). State check/set in both paths is then
serialized, so the loser of the race always observes the final
state and bails out. recv_cleanup_handler() needs no change: with
transitions serialized, a cleanup_work can only be pending after
COMPLETE, in which case the timeout handler exits early.

The race is as old as the RMPP implementation itself.

Fixes: fa619a77046b ("[PATCH] IB: Add RMPP implementation")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Dairui Zhang <zhangdairui@gmail.com>
---
Earlier version was shared privately with security@kernel.org;
posted publicly at Leon's request with a reworked commit message
(race description as a function ladder, reachability wording).

 drivers/infiniband/core/mad_rmpp.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/core/mad_rmpp.c b/drivers/infiniband/core/mad_rmpp.c
index 17c4c52..f05e9ce 100644
--- a/drivers/infiniband/core/mad_rmpp.c
+++ b/drivers/infiniband/core/mad_rmpp.c
@@ -245,12 +245,15 @@ static void recv_timeout_handler(struct work_struct *work)
 	struct ib_mad_recv_wc *rmpp_wc;
 	unsigned long flags;
 
-	spin_lock_irqsave(&rmpp_recv->agent->lock, flags);
+	spin_lock_irqsave(&rmpp_recv->lock, flags);
 	if (rmpp_recv->state != RMPP_STATE_ACTIVE) {
-		spin_unlock_irqrestore(&rmpp_recv->agent->lock, flags);
+		spin_unlock_irqrestore(&rmpp_recv->lock, flags);
 		return;
 	}
 	rmpp_recv->state = RMPP_STATE_TIMEOUT;
+	spin_unlock_irqrestore(&rmpp_recv->lock, flags);
+
+	spin_lock_irqsave(&rmpp_recv->agent->lock, flags);
 	list_del(&rmpp_recv->list);
 	spin_unlock_irqrestore(&rmpp_recv->agent->lock, flags);
 
-- 
2.53.0


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] IB/mad: fix UAF and double-free in RMPP receive reassembly
  2026-09-22 15:23 [PATCH] IB/mad: fix UAF and double-free in RMPP receive reassembly Dairui Zhang
@ 2026-09-22 15:33 ` sashiko-bot
  2026-09-29 13:29 ` Leon Romanovsky
  1 sibling, 0 replies; 3+ messages in thread
From: sashiko-bot @ 2026-09-22 15:33 UTC (permalink / raw)
  To: Dairui Zhang; +Cc: linux-rdma

> mad_rmpp_recv.state is protected by two locks that do not exclude
> each other: recv_timeout_handler() (port workqueue) uses agent->lock,
> continue_rmpp() (CQ softirq) uses rmpp_recv->lock. Nothing serializes
> the check-then-set sequence on the state word:
> 
>   T1 (CQ softirq)              T2 (port workqueue)
>   continue_rmpp()
>     lock(rmpp_recv->lock)
>     state == ACTIVE  [passes]
>                                recv_timeout_handler()
>                                  lock(agent->lock)
>                                  state = TIMEOUT
>                                  list_del(&rmpp_recv->list)
>                                  unlock(agent->lock)
>                                  destroy_rmpp_recv()
> [ ... ]
> 
> Fixes: fa619a77046b ("[PATCH] IB: Add RMPP implementation")
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Dairui Zhang <zhangdairui@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922152342.1474845-1-zhangdairui@gmail.com?part=1


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] IB/mad: fix UAF and double-free in RMPP receive reassembly
  2026-09-22 15:23 [PATCH] IB/mad: fix UAF and double-free in RMPP receive reassembly Dairui Zhang
  2026-09-22 15:33 ` sashiko-bot
@ 2026-09-29 13:29 ` Leon Romanovsky
  1 sibling, 0 replies; 3+ messages in thread
From: Leon Romanovsky @ 2026-09-29 13:29 UTC (permalink / raw)
  To: linux-rdma, Dairui Zhang; +Cc: security, Jason Gunthorpe, stable


On Tue, 22 Sep 2026 23:23:42 +0800, Dairui Zhang wrote:
> mad_rmpp_recv.state is protected by two locks that do not exclude
> each other: recv_timeout_handler() (port workqueue) uses agent->lock,
> continue_rmpp() (CQ softirq) uses rmpp_recv->lock. Nothing serializes
> the check-then-set sequence on the state word:
> 
>   T1 (CQ softirq)              T2 (port workqueue)
>   continue_rmpp()
>     lock(rmpp_recv->lock)
>     state == ACTIVE  [passes]
>                                recv_timeout_handler()
>                                  lock(agent->lock)
>                                  state = TIMEOUT
>                                  list_del(&rmpp_recv->list)
>                                  unlock(agent->lock)
>                                  destroy_rmpp_recv()
>                                    wait_for_completion()
>                                    [blocks on T1's ref]
>     state = COMPLETE
>     unlock(rmpp_recv->lock)
>     complete_rmpp()
>       queue cleanup_work (+10s)
>     deref()
>                                [unblocks]
>                                kfree(rmpp_recv)
>                                ib_free_recv_mad(done_wc)
> 
> [...]

Applied, thanks!

[1/1] IB/mad: fix UAF and double-free in RMPP receive reassembly
      https://git.kernel.org/rdma/rdma/c/90e9b6357bec75

Best regards,
-- 
Leon Romanovsky <leon@kernel.org>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-09-29 13:29 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-22 15:23 [PATCH] IB/mad: fix UAF and double-free in RMPP receive reassembly Dairui Zhang
2026-09-22 15:33 ` sashiko-bot
2026-09-29 13:29 ` Leon Romanovsky

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).