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 --- 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