Re: [PATCH net v5 1/3] net/smc: bound the wire-controlled producer cursor to the RMB

[Bryam Vargas <hexlabsecurity@proton.me>]

On Tue, 28 Jul 2026 15:50:02 +0200, Paolo Abeni wrote:
> Sashiko gemini suspects the above may cause a Null ptr dereference:
>
> https://sashiko.dev/#/patchset/20260723-b4-disp-0d07164f-v5-0-6a9e235dbc4e%40proton.me

The window is real, but this patch doesn't open it: the same load is already
on that path.

smc_cdc_msg_recv_action() dereferences conn->rmb_desc->len unconditionally
at smc_cdc.c:376, and nothing between the conversion call at :339 and that
line can return early, so every CDC that reaches the conversion reaches the
existing dereference as well. The patch moves the load about 37 lines up
inside the same function; it doesn't add an execution that touches
conn->rmb_desc. On SMC-D the existing one comes first anyway --
smcd_cdc_rx_tsklet() reads rmb_desc->cpu_addr at :452 before it calls
smc_cdc_msg_recv() at all. Line numbers are against net/main at
e095f249e220.

What the bot is pointing at is a separate defect. smc_conn_create() puts the
connection in the link group's token tree before smc_buf_create() allocates
the RMB, so a CDC arriving in that window finds a connection whose buffer is
still unset -- with or without this series. That one is fixed by [PATCH net
v4] "net/smc: order the CDC receive path against buffer publication", which
publishes the buffers with smp_store_release() once the receive state is
initialised and makes the CDC entry points bail while they are unset:

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

Thanks,
Bryam