Linux kernel (net/rds): When pinning user pages for a zerocopy RDS send fails, the pages are released but the

Impact

When pinning user pages for a zerocopy RDS send fails, the pages are released but the scatter-list count is left non-zero, so the message purge path walks the stale entries and frees the same pages a second time. A tenant that makes iov_iter_get_pages2() fail on purpose gets a double free of page structures - a strong heap-corruption primitive that can be aimed at memory belonging to other tenants.

Who can reach it

Local and unprivileged: socket(AF_RDS, SOCK_SEQPACKET, 0) - autoloaded via the net-pf-21 alias with no capability check - then sendmsg() with MSG_ZEROCOPY over an iovec crafted so page pinning fails partway (unmapped or unpinnable pages). No RDMA hardware, device node, or capability is needed; the failure is entirely under the tenant's control, which makes it far more attractive than a timing race.

What to do

Boot a kernel carrying the fix commits (resets op_nents on the zerocopy pin failure path). Interim: blacklist the rds module family (install rds /bin/false) or deny socket family 21 in tenant seccomp profiles.

References