From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-98.freemail.mail.aliyun.com (out30-98.freemail.mail.aliyun.com [115.124.30.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D63A19D8BC; Fri, 19 Jun 2026 03:31:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.98 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781839884; cv=none; b=kCJbrLA2iiriyUwYs3W9hyVQOHdjmvZ82kGXUfKBM4iCFKwu/eWzAvYjjLU27j6Wyup7Cuo/vL+kUSzzkvLOUdiVM2MUiIkwgIngRMY9b6sMCC25oyxyn0hC/tp1CyuBxkdvlkNw0gxuvH2kaXPw2FIWcTv1yXnwTbLmLQSYJx0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781839884; c=relaxed/simple; bh=JzPjOPNYTxb3CLKqeBrTg6gSkEKoAKEwNbvjO9EzUyg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=abDVfaZZIdMFPcDM6zEH4JZ4FC8W5DZr82CJipM+6A7auNlcKNWCdGBiMpVXYBLtoHS78dvvoc/0VkUyGeU3x+Cju8eTdDnzoB4QigEpxNyX6iwVaec2EeoZ9Inf1WFClcwbpciDblEuh1PHYJ55KeywZyleJj7E3NWCVvCA+zo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=khGY8gE4; arc=none smtp.client-ip=115.124.30.98 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="khGY8gE4" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1781839880; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=JzPjOPNYTxb3CLKqeBrTg6gSkEKoAKEwNbvjO9EzUyg=; b=khGY8gE4Nwby2jCpUMCww9DYAhXehD3eCMjN63720EsKnTMcR2ughCC4rW7GsGpCuxIB6/tPFQDrtxGH6gQ2gsFH2XHSteUiEsiHPjmhnFsRN9SGC7Wlecok6ExiyWuUnN7Wj7bdKBTXpF1Ni6nGoAhtZvNXX+Q+YBJ2jQPcGHE= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R551e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=dust.li@linux.alibaba.com;NM=1;PH=DS;RN=18;SR=0;TI=SMTPD_---0X58XT8v_1781839879; Received: from localhost(mailfrom:dust.li@linux.alibaba.com fp:SMTPD_---0X58XT8v_1781839879 cluster:ay36) by smtp.aliyun-inc.com; Fri, 19 Jun 2026 11:31:19 +0800 Date: Fri, 19 Jun 2026 11:31:18 +0800 From: Dust Li To: Bryam Vargas Cc: Wenjia Zhang , "D . Wythe" , Sidraya Jayagond , Eric Dumazet , "David S . Miller" , Mahanta Jambigi , Wen Gu , Simon Horman , Ursula Braun , Stefan Raspl , Tony Lu , Paolo Abeni , Jakub Kicinski , netdev@vger.kernel.org, linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 2/3] net/smc: bound the receive length to the RMB in smc_rx_recvmsg() Message-ID: Reply-To: dust.li@linux.alibaba.com References: <20260614-b4-disp-edd64be9-v3-0-551fa514257e@proton.me> <20260614-b4-disp-edd64be9-v3-2-551fa514257e@proton.me> <20260618221106.236699-1-hexlabsecurity@proton.me> Precedence: bulk X-Mailing-List: linux-rdma@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260618221106.236699-1-hexlabsecurity@proton.me> On 2026-06-18 22:11:12, Bryam Vargas wrote: >On Fri, 19 Jun 2026 00:03:17 +0800, Dust Li wrote: >> Once we validate the CDC message at the input boundary (as in the >> previous patch), bytes_to_rcv can never exceed rmb_desc->len, so >> this check becomes unreachable. So I don't think this patch is needed. > >This one I'd actually like to keep, and let me walk through why -- I don't think the >boundary check closes it. > >bytes_to_rcv isn't set to a cursor count, it's a running accumulator: >smc_cdc_msg_recv_action does atomic_add(diff_prod, &bytes_to_rcv), where >diff_prod = smc_curs_diff(rmb_desc->len, old, new). So bounding each cursor's count at >the boundary doesn't bound the sum of the deltas. > >The differing-wrap branch of smc_curs_diff returns (len - old.count) + new.count, >which is up to 2*len-1 even when both cursors pass count <= len. With len=16, a prod >going (0,0) -> (1,15) gives diff=31, so bytes_to_rcv is already 31 > len after one >message; alternating wrap 0<->1 at count=15 keeps adding ~len and eventually wraps the >atomic_t negative. I have an A/B for this -- happy to send it along. Glad to see you A/B test, I think we can decide after we see the real issue. > >So to make this truly unreachable from the boundary check, we'd need to bound >prod - cons <= len there, not just the absolute count. The consumer-side clamp is two >lines and race-free against the tasklet, so my preference would be to keep it as a >backstop -- but if you'd rather fold it into a stronger boundary check instead, I'm >open to that. Another thing I'd worry about is if this really happens, should we also abort the connection like what we did in patch #1 ? Best regards, Dust