Re: [PATCH net-next] net/smc: abort the connection when the peer overruns the RMB

[Bryam Vargas <hexlabsecurity@proton.me>]

Hidayath,

> I have a standalone net-next patch that aborts the connection when
> bytes_to_rcv + diff_prod exceeds rmb_desc->len.  The check sits before
> the atomic_add(), so the accumulator is never written with an out-of-range
> value

That covers the follow-up I said I would send, and the placement is better than
what I described: I had said a check after the atomic_add, which only notices
the counter is already out of range. Yours doesn't let it get there. Consider my
follow-up withdrawn -- I am not sending a competing patch.

If it is useful for the Fixes decision: I ran the wrap++/count==0 vector on the
real SMC-D path under KASAN while working on the cursor series. With only the
per-cursor bound applied, bytes_to_rcv reaches 6*len and smc_rx_recvmsg() trips
slab-out-of-bounds on a read of 5*len; each CDC advances exactly len, so
diff == len and an advance-bound does not fire -- it's the accumulation that
overruns, which is what your check catches. Logs on request if you want them in
the commit message.

Two heads-up on collisions, since both are in flight this week rather than
merged:

smc_cdc_msg_recv_action() is also touched by "net/smc: order the CDC receive
path against buffer publication" (v4, 20260728-b4-disp-52ee4e7d-v4-1-0dda94b0f397@proton.me),
which hoists sndbuf_desc to the top of the function and gates the tx-trigger on
it. Your hunk sits just above that gate, so whichever lands second will want a
look rather than a blind rebase. I'd rather flag it now than after a conflict.

And you mentioned running the abort_work cancel for both transports in v2 --
that edits smc_conn_free()'s SMC-D branch, which "net/smc: unregister the
connection before draining the rx tasklet"
(20260808-b4-disp-22f119e6-v2-1-61647601a6f3@proton.me) also rewrites: it drops
the !list_empty guard around smc_ism_unset_conn(), moves the drain ahead of the
detach, and clears conn->sndbuf_desc before freeing it. Same branch, same week.

On the shared bitfield -- agreed it needs a layout change rather than something
folded into a fix, and it's yours; I'd noted it and left it alone for the
same reason.

Thanks,
Bryam