Linux kernel (net/rds): A zerocopy RDS send that fails after pinning user pages but before the message reaches the

Impact

A zerocopy RDS send that fails after pinning user pages but before the message reaches the socket queue is cleaned up as if it owned ordinary payload pages, because the purge path infers zerocopy ownership from the socket pointer rather than from the notifier. The pinned-page accounting and the page references are then handled wrongly - the tenant controls when the failure happens, so it controls which pages are mis-released.

Who can reach it

Local and unprivileged: an AF_RDS socket (family 21 autoloads on socket() with no capability check) doing a MSG_ZEROCOPY sendmsg that fails early - before the message is attached to the socket. No RDMA device or privileged access is required, and the failure timing is attacker-chosen rather than racy.

What to do

Boot a kernel carrying the fix commits (uses op_mmp_znotifier as the cleanup discriminator in rds_message_purge). Interim: blacklist rds/rds_rdma/rds_tcp or deny socket family 21 to tenants.

References