ZcopyReaper (CVE-2026-43502): Linux kernel RDS zero-copy LPE, fixed in 7.1-rc3, disclosed amid batch of ~21 kernel LPEs
CVE-2026-43502 (ZcopyReaper) is a Linux kernel local privilege escalation in the net/rds zero-copy send path, introduced in v4.17 and fixed by commit 44b550d88b26 (mainline 7.1-rc3) with backports to Ubuntu and Debian; NebuSec also released public exploits…
Researchers disclosed CVE-2026-43502, dubbed ZcopyReaper, a Linux kernel local privilege escalation in the net/rds (Reliable Datagram Sockets) zero-copy send path, first reported to oss-security on 2026-09-08 by Yuan Tan. The flaw is a lifetime-management error in rds_message_purge() that mishandles zero-copy sends before socket attachment, corrupting kernel memory and enabling local privilege escalation to root without requiring capabilities or unprivileged user namespaces; disabling unprivileged user namespaces does not mitigate it. The bug was introduced in Linux v4.17 and fixed by commit 44b550d88b26, first appearing in mainline v7.1-rc3, with backports to Ubuntu 7.0.0, 6.8.0, and 5.15.0 kernels and multiple Debian branches. NebuSec demonstrated the exploit on openSUSE running kernel 6.4.0-150600.23.100; vulnerable systems require CONFIG_INET, CONFIG_AIO, CONFIG_RDS, and CONFIG_RDS_TCP. The disclosure headlines a batch of roughly 21 Linux kernel LPE CVEs (about 20 additional flaws beyond ZcopyReaper) published in the 2026 Q3 window, tracked in the kernel.org security vulnerabilities git repository; the original post did not include CVE ids for the other 20 flaws, though NebuSec released public exploits for those 20 additional kernel vulnerabilities in its CyberMeowfia repository. Interim mitigations include blocking rds.ko and rds_tcp.ko module loading, and oss-security commenters noted that locking kernel module loading after boot has repeatedly proven effective. No report indicates whether any of the flaws are exploited in the wild.
- CVE-2026-43502 (ZcopyReaper) is a local privilege escalation in the Linux kernel net/rds zero-copy send path, caused by a lifetime-management error in rds_message_purge() that mishandles zero-copy sends before socket attachment
- Introduced in Linux v4.17; fixed by commit 44b550d88b26, first in mainline v7.1-rc3, with backports to Ubuntu 7.0.0, 6.8.0, and 5.15.0 kernels and multiple Debian branches
- Exploit requires no capabilities or unprivileged user namespaces; disabling unprivileged user namespaces does not mitigate the flaw
- Vulnerable systems need CONFIG_INET, CONFIG_AIO, CONFIG_RDS, and CONFIG_RDS_TCP enabled
- Yuan Tan reported the flaw to oss-security on 2026-09-08; NebuSec demonstrated privilege escalation on openSUSE kernel 6.4.0-150600.23.100
- NebuSec released public exploits for 20 additional Linux kernel vulnerabilities in its CyberMeowfia repository, part of a batch of roughly 21 kernel LPE CVEs published in the 2026 Q3 window (fixes tracked in the kernel.org security…
- Interim mitigation: block loading of rds.ko and rds_tcp.ko; oss-security commenters noted locking kernel module loading after boot has repeatedly proven effective
- No report indicates exploitation in the wild
Coverage timelineoldest first · each row is one article
- · 8d agoLinux kernel LPEs: ZcopyReaper (CVE-2026-43502) and 20 more
oss-security· 65
Researchers disclosed CVE-2026-43502 (ZcopyReaper), a Linux kernel local privilege escalation in the RDS zerocopy send path, fixed in v7.1-rc3.
Vulnerabilities in this storyAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-43502 | In the Linux kernel, the following vulnerability has been resolved: In the Linux kernel, the following vulnerability has been resolved: net/rds: handle zerocopy send cleanup before the message is queued A zerocopy send can fail after user pages have been pinned but before the message is attached to the sending socket. The purge path currently infers zerocopy state from rm->m_rs, so an unqueued message can be cleaned up as if it owned normal payload pages. However, zerocopy ownership is really determined by the presence of op_mmp_znotifier, regardless of whether the message has reached the socket queue. Capture op_mmp_znotifier up front in rds_message_purge() and use it as the cleanup discriminator. If the message is already associated with a socket, keep the existing completion path. Otherwise, drop the pinned page accounting directly and release the notifier before putting the payload pages. This keeps early send failure cleanup consistent with the zerocopy lifetime rules without changing the normal queued completion path. NVD description · AI analysis pending | 7.8 | <1% |
| — |