From: Ibrahim Hashimov <security@auditcode.ai>
To: dust.li@linux.alibaba.com
Cc: alibuda@linux.alibaba.com, wenjia@linux.ibm.com,
hexlabsecurity@proton.me, tonylu@linux.alibaba.com,
guwen@linux.alibaba.com, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-s390@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] net/smc: validate peer CDC cursor against RMBE size before accepting it
Date: Wed, 22 Jul 2026 12:29:29 +0200 [thread overview]
Message-ID: <20260722102929.38218-1-security@auditcode.ai> (raw)
In-Reply-To: <amA9XGOWH3z4Z1fu@linux.alibaba.com>
> I believe Bryam already sent a similar patch to the mailist and I have
> already reviewed it.
> https://lore.kernel.org/netdev/20260705-b4-disp-28a1bbca-v4-1-be089b98acc6@proton.me/
Thanks Dust -- yes, that fixes the same bug, so please drop mine. (I sent
a v2 earlier today, before I saw your note, in reply to a sashiko review;
please disregard it as a competing patch.)
One thing worth checking on Bryam's series, though: bounding only the cursor
count (clamping temp.count to rmb_desc->len) still leaves the advance
unbounded. smc_curs_diff() on a wrap increment returns
(size - old.count) + new.count, so a peer that sends prod (wrap=W, count=0)
then prod (wrap=W+1, count=size) makes diff_prod ~= 2*size even though both
counts are in range. smc_cdc_msg_recv_action() then atomic_add()s that into
bytes_to_rcv without clamping (despite the "0 <= bytes_to_rcv <=
rmb_desc->len" comment) -- which is exactly what smc_rx_recvmsg()'s second
copy chunk trusts.
A sashiko review of my patch flagged the same gap; I bounded the advance
too, with:
if (smc_curs_diff(size, &old, &temp) > size)
return;
Might be worth folding into Bryam's version. Happy to send it as a
follow-up if that helps.
Thanks,
Ibrahim
prev parent reply other threads:[~2026-07-22 10:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 17:07 [PATCH net] net/smc: validate peer CDC cursor against RMBE size before accepting it Ibrahim Hashimov
2026-07-21 17:08 ` sashiko-bot
2026-07-22 3:47 ` Dust Li
2026-07-22 10:29 ` Ibrahim Hashimov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260722102929.38218-1-security@auditcode.ai \
--to=security@auditcode.ai \
--cc=alibuda@linux.alibaba.com \
--cc=dust.li@linux.alibaba.com \
--cc=guwen@linux.alibaba.com \
--cc=hexlabsecurity@proton.me \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tonylu@linux.alibaba.com \
--cc=wenjia@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.