From nobody Mon May 25 04:34:01 2026 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 27C10397E75 for ; Mon, 18 May 2026 21:23:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779139424; cv=none; b=f61JpyUfeGp8nBpGuJ63n4hFVlkMIt9agZFhr6FH+OSmVHJzGdMiNl76fXwvY37fksinIDInh8+DfR7XQG2l0xGwvxIZZKl9syIzi3Befc47ikfEJuaGlQTFCA3DHsVr2URKwYn1bB3PoFjsdCdIILNIE/RTk6oj27OakToG2lo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779139424; c=relaxed/simple; bh=r0lg9YRX6xORkZ7Admw+989oxdaqLorvb/Z1s0NxaLc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=pxGgUXqVxkkVsJHQSQ2srbT6ac8UJIKlrXFaTU6fCGcNdfqN82PanJaeMOkO3TbSKNdkDpmY52Sri7iDQ6IC3ArmCSNeZmTs6d9uFU6BtSEA91cBwc2AAhRaGnRGG+7aTUfVAKKg4nDIDYqbcr1Ml4u1wBBSAAGmHhat5fDmt7Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BgK8aTPt; arc=none smtp.client-ip=209.85.160.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BgK8aTPt" Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-50e5bea4045so21708591cf.3 for ; Mon, 18 May 2026 14:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779139422; x=1779744222; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=8dlxczQKkS431AlI89XxhX7yrGqU4XUXJdF6JkeyGzM=; b=BgK8aTPto0OtHACqJ95bQkVyQWpwPpSF+dXIfnSK1UWMG9iZHvOH1PfyDBPrxG7vlU jSeTqOBngpNZ8KfOQGR/RJv0vzrOHO6v1CSBtTuTukG5h5wQOg1Vupoxt7QHkNIvUKSy z+c9BIM1i/6pDk1SOi8IBvmc4/Kr7deyPiuAmW0RDwBcUVB4PF1vD3YZJjCvZ/kLZHUK YlhHFpz7EXRO00c7q47ILbgOXm5A4fvtNDPeJPPETJRoUpEMsR4SuBZH6R0JAAnVac8J /EzG62SwVdBFlRmbwTFHByuLbTwjZLeUUC1Dac8qCzRFl0tqw/H6nZ9/9Kb+MoCeUazz gbGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779139422; x=1779744222; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8dlxczQKkS431AlI89XxhX7yrGqU4XUXJdF6JkeyGzM=; b=YMvf8i74N0Gj+9nb3KEz7L1Zh49V8OocacZEpQvgcAlH4cEtL9rE+xej1nvWk6QqMT JmmBEgTX2YWxhppbTDxMg5XSfUh+ZxhgESKnvgoleoH/WCfyKFFUmXTjsUpZvLh4gbYz U/59J2SXgio8kTeplZoScMcB/p5tBC5SwZucuuuHSDR9lbCo9p58OTaz56QRnI/VqnPA eomwtezOLq1HK+LLLqUFOOxjYmLWwyIB0tFVe2EFoq1DSUcKvctkmLe1ZBHcanXG34cV c21xz+KxC3Hhj0/YVHvKTfHq6QGyx80D7/57mkVSSI6n/all5O8rF4uBjiNW6Msk66wM 9SWw== X-Forwarded-Encrypted: i=1; AFNElJ9ukrfFdb775OCHGmGa5mnjqkUyQjl/emQs2I0m/gT/1zJi0NLldiVI+rjhJTBawIZ/4nPYG0ZfUeg2IUk=@vger.kernel.org X-Gm-Message-State: AOJu0YwDCoUSd8d2AdLq3eaa/4LfmEW21QG6B3OGUQhKAiuBo0qLCO3Y HTwCuTZJwmtFABwBU6cKS1p/9vBTkjVYzpTd3YyLOqI2yKcz5nvQVtqH X-Gm-Gg: Acq92OFFbuOpNzRiVnKfbCsCjg+DYSm5J2NHgQgnJFVDJ4TnisACJdkIqYvq/rbwp0t ZNUXzwqjMDyQHEgVaUNaS1aiUW/KFeKcGrE+m3mfsse+xEX0F4dT5ORddkIfpMICvKgmdCXbPzj +lDRYTIj8DoeIUE5GoN4U+rAU0RGTnLVvslWRlg+y1LjDGaiO+TUaXXoC96LjI12+BALsXkz49d cbFnwNsCWGApgGGqXBAzhiG6EnvbGI+JilvqC44phXePz3PTdd/P2Yok4zJ0qtyZ3OpdHExPO2D dgJbrLFgiEV2dU1H0cEPZ11DLGdn3OxwAIikWBMGtxhbaPGJifNuAIC464RNZf+u32gBUwq7E/z QLI6SAqrRf2dxPF72A4e/JEz8jEU+g8HUl1F7fkfp+GDmWPLHsgP2fK0bThvDjpZkalNc4DOJ56 nZWzjmaVGY9ZNzdL050kK80JhrGNyYyNTSrFG7aJyfPPsrj45GLDt4PHzy8Wlp5seJVekXFfhwf 4R6qsnIKpJSvog78HMh X-Received: by 2002:a05:622a:5c0d:b0:50d:72e4:6df9 with SMTP id d75a77b69052e-5165a240d60mr229260081cf.50.1779139421988; Mon, 18 May 2026 14:23:41 -0700 (PDT) Received: from server0 (c-68-48-65-54.hsd1.mi.comcast.net. [68.48.65.54]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5164df7bfa7sm138911031cf.21.2026.05.18.14.23.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 May 2026 14:23:41 -0700 (PDT) From: Michael Bommarito To: Jason Gunthorpe , Leon Romanovsky Cc: linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Vlad Dumitrescu , Or Har-Toov , Bob Pearson , Sean Hefty , Kees Cook Subject: [PATCH] IB/mad: cap RMPP reassembly window size to bound find_seg_location walk Date: Mon, 18 May 2026 17:23:36 -0400 Message-ID: <20260518212336.337104-1-michael.bommarito@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A peer on the same InfiniBand subnet or RoCEv2 L2 (or any UDP/4791- reachable peer for internet-exposed RoCEv2 ports) can pin a target port's IB MAD kworker for milliseconds per low-bandwidth RMPP burst by sending an RMPP management transaction with descending segment numbers. QP1 GMP traffic is unauthenticated by IBTA spec, so no credentials are required. The bug sits on the IB management path (QP1 GMP RMPP reassembly), not the RDMA data plane, so RDMA verbs throughput is unaffected; deployments that raise recv_queue_size to tune management-plane throughput are quadratically more exposed, because per-burst cost grows O(F^2) with the configured window. drivers/infiniband/core/mad_rmpp.c::find_seg_location() walks rmpp_recv->rmpp_wc->rmpp_list in reverse on every inbound RMPP DATA segment to locate the insertion point keyed by segment number. The walk is O(N) per insert under spin_lock_irqsave(&rmpp_recv->lock) in kworker context, so F adversarially-reordered segments aggregate to O(F^2). window_size() returns max(recv_queue.max_active >> 3, 1): the IB MAD core default recv_queue_size of 512 yields window=3D64 (per-burst cost in the microsecond range), but tuned production configs with recv_queue_size=3D8192 push window to 1024 and let a single low-bandwidth burst pin the per-port MAD kworker for several milliseconds. Cap the effective window at IB_MAD_RMPP_MAX_WINDOW =3D 64 in window_size() so admins tuning recv_queue_size for higher RX throughput do not enlarge the walker attack surface. Real RMPP transactions in the wild (SA queries, perf-counter reads) are well served by a window of 64, which is also the IB MAD core default. A structural follow-up would convert rmpp_recv->rmpp_wc->rmpp_list to an rb_tree keyed by seg_num and lift the cap; that mirrors tcp_data_queue_ofo post- CVE-2018-5390. For now the cap suffices. Fixes: fa619a77046b ("[PATCH] IB: Add RMPP implementation") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Michael Bommarito --- I reproduced this under x86_64 QEMU/KVM (4 vCPUs) on v7.1-rc2 with CONFIG_RDMA_RXE + CONFIG_INFINIBAND_USER_MAD, a veth pair carrying two rdma_rxe links, and raw RoCEv2/UDP/4791 packet injection with descending seg_num while holding seg #1. Without the cap, F=3D1024 burst produces 1022 paired continue_rmpp invocations whose per-call walker duration grows from ~1 us (early, near-empty list) to ~5 us (late, ~1000-deep list), a 4x per-call amplification as the queue deepens, with aggregate walker time per burst >=3D 1.5 ms (lower bound, ftrace 1 us granularity). With the cap, the same F=3D1024 burst drops to ~0.28 ms aggregate (5.4x reduction); F=3D32 in-window legitimate RMPP still completes normally (30 walker calls, avg 1.5 us, max 3 us). tools/testing/selftests/drivers/net/rdma/ carries no RMPP-specific selftest in v7.1-rc2 (rdma_rxe self-tests do not exercise QP1 GMP RMPP reassembly), so no in-tree selftest delta to report. drivers/infiniband/core/mad_rmpp.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/core/mad_rmpp.c b/drivers/infiniband/core/m= ad_rmpp.c index 17c4c52a19e4c..4d55b133c689c 100644 --- a/drivers/infiniband/core/mad_rmpp.c +++ b/drivers/infiniband/core/mad_rmpp.c @@ -391,9 +391,25 @@ static inline struct ib_mad_recv_buf *get_next_seg(str= uct list_head *rmpp_list, return container_of(seg->list.next, struct ib_mad_recv_buf, list); } =20 +/* + * Cap the per-RMPP-transaction in-flight window. find_seg_location() + * walks the rmpp_recv list reverse to find each insertion point, so the + * aggregate cost across an attacker-paced reordered window is O(N^2) + * under spin_lock_irqsave(&rmpp_recv->lock) in kworker context. The + * default recv_queue_size of 512 yields window=3D64, which keeps that + * cost in the noise; tuned configurations (recv_queue_size up to 8192) + * push window to 1024 and the per-port kworker measurably stalls under + * a low-bandwidth burst from any unauthenticated peer on QP1 GMP. Cap + * window at IB_MAD_RMPP_MAX_WINDOW so the bug class is structurally + * defused regardless of recv_queue_size tuning. + */ +#define IB_MAD_RMPP_MAX_WINDOW 64 + static inline int window_size(struct ib_mad_agent_private *agent) { - return max(agent->qp_info->recv_queue.max_active >> 3, 1); + int wsize =3D agent->qp_info->recv_queue.max_active >> 3; + + return clamp(wsize, 1, IB_MAD_RMPP_MAX_WINDOW); } =20 static struct ib_mad_recv_buf *find_seg_location(struct list_head *rmpp_li= st, --=20 2.53.0