Linux kernel SMC-R (fallback path, DECLINE message leaking into the application stream): Silent data corruption, which

Impact

Silent data corruption, which is worse than a crash because nothing alerts. When SMC falls back to TCP, an in-flight SMC DECLINE control message could be delivered into the application's data stream - the reporters found Redis receiving raw SMC protocol bytes (0xE2 0xD4 0xC3 0xD9 ...) as if they were payload. On a training cluster the equivalent is protocol bytes landing inside a checkpoint shard or a gradient transfer: the job does not fail, it produces wrong results, and you find out weeks later if at all.

Who can reach it

Remote/network. A peer that triggers SMC fallback at the wrong moment - or ordinary network conditions that cause fallback - injects control bytes into the data stream. No authentication involved.

What to do

Kernel update preventing the decline message from reaching the socket's data path. Until patched, treat any SMC-accelerated flow as unsuitable for data whose integrity you cannot verify end to end, and add application-level checksums to checkpoint and dataset transfers - which is good practice regardless of this bug.

References