Answering the Sashiko comments on all three patches here. 1/3: yes, applying it alone leaves the out-of-bounds read reachable. The commit message says so, and all three patches carry Cc: stable for that reason. The three are a set.
2/3: patch 2 does restrict that path on its own, and it is not meant to stand alone. It takes away no working behaviour either: before the series the same path did not save the peer's rkeys, because smc_llc_enqueue() copied only the 44-byte base message and the loop then read past the queue entry rather than the extension. 3/3 copies the tail into qentry->body, and both the add_link and the delete_rkey loop take the rkeys from there, so the complete series saves every rkey the peer sent. 3/3: the tail is copied in smc_llc_enqueue(), next to the 44-byte copy that has always been there, so the extension is no longer read from the shared receive buffer later, from the worker. Its length comes from wc->byte_len rather than from the length the peer declared, so a short message leaves an empty body instead of stale bytes. The other two points, the ownership of the shared receive buffer and the locking in smc_rtoken_delete(), are about code this series does not change. Best regards, Yehyeong Lee
