The proof of concept (PoC) itself relies on /tmp/ having mount 'exec' permissions. On systems with a separate /tmp/ and mounted with 'noexec' this would fail. T

The proof of concept (PoC) itself relies on /tmp/ having mount 'exec' permissions. On systems with a separate /tmp/ and mounted with 'noexec' this would fail. This latter is one of a series of hardening steps that are useful in making executing untrusted code more difficult (but not impossible). Fix is introduced in commit 7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6. On the wider point of kernel corruption it isn't absolutely clear if the PoC relies on specific attributes of the target kernel builds or a suitable .config, and if so which, or very specific kernel versions between v4.1-rc1 and v5.19-rc7. Article talks specifically about "Ubuntu 22.04" and shows kernel 5.15.0-27-generic in the poc.gif but the github README.md says 5.15.0-39-generic. No mention if this affects the -lowlatency kernels. Recent Linux stable tree kernels carry the patch (e.g. v5.18.12 commit 6b7488071ea8ed6265a39afebd5a5920f6975d02). The exploit fails (here) on stable tree v5.18.9 in an interesting way! $ ./poc [+] Second process currently waiting [+] Get CAP_NET_ADMIN capability [+] Netlink socket created [+] Netlink socket bound [+] Table table created [+] Set for the leak created [+] Set for write primitive created [*] Leak in process[-] add_key: Disk quota exceeded This on an ext4 file-system with no quotas enabled and 9GiB free space. The message via perror() is of course wrong; in fact during the call via SYSCALL_DEFINES(add_key, ...) in security/keys/keyctl.c a return value of 122 (EDQUOT) is returned. There are 3 call sites in that function that call PTR_ERR() - a function that determines if a pointer value is a valid 'errno' value - so one of strndup_user(), lookup_user_key(), or key_create_or_update() failed.