Unroll0201

Manual auditing ;-) I have specified it in https://pwning.tech/nftables#31-finding-the-bug

I'm a bit late, but it's because I wanted my exploit to be universal. When patching kernel .text I'd need know: - know the offset to the patched instructions (memory scanning will not work) - know the architecture-compatible instructions to replace it with

Thank you so much! It feels great to hear this.

The sysctl command isn't available on specific kernel configurations. You could try running `unshare -Urn`. If it runs without sudo (and you haven't configured any specific permissions yourself), unprivileged namespaces are enabled.

Is there a reason why you did this? I knowingly chose the other title because it would apply more to the Hackernews audience to raise more awareness of the exploit and that people should update. This title was aimed at the Linux kernel VR community, which also shows because the post instantly dropped down from a 2-hour #1 position to #8

For me it is about the ethics among other things. I do not know to which goverments Zerodium is selling, much like any other zeroday broker. Additionally, I wouldn't be surprised if selling to Zerodium is illegal to begin with.

By taking the KernelCTF approach I get my bounty, I don't get into legal trouble, and I get to contribute to the Linux kernel VR community which means a lot to me

This is an educated guess, but I believe unprivileged Docker containers cannot create (user) namespaces. Hence, the vulnerability cannot be triggered, since the exploit requires interaction with nf_tables, which requires (namespace) root.

LXC containers and privileged Docker containers allow these namespaces to be made inside of them, whilst unprivileged Docker containers do not.

This is indeed expected. I specified in the "Caveats" section in README.md that the exploit does not work on Ubuntu v6.5 (because it enables a certain kernel config value that indirectly mitigates the exploit starting from v6.4), and may not work on other kernels above v6.4 depending on the config.

The exploit support from v6.4 - v6.6 is depending on a Linux kernel kconfig value. If `CONFIG_INIT_ON_ALLOC_DEFAULT_ON` is set to `y`, the exploit is not working. If it is set to `n`, it does work. I have updated my comment.

The attack vectors are pretty much the same for other Linux kernel LPE exploits. The impact is also much alike: privilege escalation from unprivileged user to root user. Should be noted that the exploit can read/write any physical memory on the device, but uses it to become root user.

An important note is that the exploit requires nf_tables to be present, and unprivileged user namespaces. This can be checked with commands specified in the README.md file in the repo.

Notice however that the exploit contains a namespace escape, allowing it to break out of namespaces on vulnerable kernels. As said in the other comment, this possibly includes LXC containers and privileged Docker containers, but this is not tested and is purely an educated guess).

The namespace escape is included because it is a requirement for the KernelCTF program.

Correct, but it is definitively worth updating for on high-profile systems.

I have not tested it, but because I have included the namespace escape in the exploit for KernelCTF, it may be able to break out of LXC containers and privileged Docker containers running on vulnerable Linux kernels.

Thanks for the notice. I will immediately fix it.

Today I published a proof-of-concept exploit for CVE-2024-1086, working on Debian and Ubuntu among others.

The affected exploit versions are from Linux kernel v5.14 up to v6.6. The support for v6.4 to v6.6 is depending on the `CONFIG_INIT_ON_ALLOC_DEFAULT_ON` kernel config variable, but please check README.md for this info.

The bug was patched in February 2024, and has been labelled CVE-2024-1086.

Make sure to update your Linux devices!