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

[Bryam Vargas <hexlabsecurity@proton.me>]

Hidayath,

Sorry this sat for two months -- a major earthquake here, then
wrapping up my postgrad program.

> Yes, please send the logs.

Log below, from today's re-run on v7.3-rc6. One note on the label
first: it isn't stable across runs. My Aug 8 mail said
slab-out-of-bounds, which is what the Jul 23 run printed; the Jul 11
run said slab-use-after-free and today's says use-after-free, all on
the same 327520-byte read (5 * len). The second chunk is read from ring
offset 0, so its first 65504 bytes are still inside the RMB and the
remaining 262016 run past it, and KASAN names it after whatever sits
past the RMB. If the commit message names the bug type, take it from
the log you paste.

Repro: two AF_SMC sockets over SMC-D loopback, v7.3-rc6 with KASAN,
rmb_desc->len 65504. The sender puts its producer cursor on the wire
as wrap++ with count 0, six times. Each CDC passes every per-cursor
bound and smc_curs_diff() returns len for each, so bytes_to_rcv
reaches 393024 (6 * len). recv() returns 393024 and the second chunk
is a 327520-byte read:

  BUG: KASAN: use-after-free in _copy_to_iter+0x183/0x1390
  Read of size 327520 at addr ffff88814a0f0020 by task smc_forge_test/1695
  Call Trace:
   _copy_to_iter+0x183/0x1390
   smc_rx_recvmsg+0xbe0/0x27a0 [smc]
   smc_recvmsg+0x1c9/0x3a0 [smc]
   sock_recvmsg+0x14b/0x190
   __sys_recvfrom+0x190/0x2a0
   __x64_sys_recvfrom+0xdb/0x1b0
   do_syscall_64+0xdd/0x4a0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  The buggy address belongs to the physical page:
  head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
  Memory state around the buggy address:
   ffff88814a0fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  >ffff88814a100000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Trimmed: KASAN's own frames, the "?" frames, registers and the page
dump; full log on request. With our v6 cursor series applied (2/3
bounds the receive length) the same run returns 65504 and KASAN stays
quiet, and an unforged transfer is clean. I haven't run it against
your patch. FWIW the forging is a test knob on the sender; on the rx
side the test module only adds a read-only readback of bytes_to_rcv,
which the test polls instead of sleeping, and a clamp toggle that
stays off in this run.

Ibrahim Hashimov raised the same accumulator gap on his "validate peer
CDC cursor" thread in July and accepted the Suggested-by I offered him
for the follow-up I had planned then. Your patch covers that
follow-up, so I'm passing it on; your call:

https://lore.kernel.org/all/20260724072117.73038-1-security@auditcode.ai/

Of the two changes of mine you planned to rebase on, "net/smc:
unregister the connection before draining the rx tasklet" is in
mainline (36cdf5d48ca1), and "net/smc: order the CDC receive path
against buffer publication" is not merged; its last posting is v4:

https://lore.kernel.org/all/20260728-b4-disp-52ee4e7d-v4-1-0dda94b0f397@proton.me/

Thanks,
Bryam