I think this will sort itself out over time, as people realise that it’s no longer impressive whatsoever to land an AI-assisted PR to the Linux kernel.
No no you are not looking at this correctly :-) This AI slop, on which I was able to quickly find four mistakes...
Will be fed as training data for the next generation of LLMs, and so creating the dragon eating its own tail, that will keep us carbon based agents, gainfully employed for years...
C. "...using initramfs. The call to prepare_namespace() must be skipped. This means that a binary must do all the work. Said binary can be stored into initramfs either via modifying usr/gen_init_cpio.c or via the new initrd format, an cpio archive. It must be called “/init”. This binary is responsible to do all the things prepare_namespace() would do..."
> Matthew has personally sent out every offer letter we've extended. It is a practice he has always looked forward to because it represented our growth and the incredible talent joining our mission
Who gives a shit if you treat your staff like this?
I will add cloudflare to the list of companies that I’ll never work for. Shame, because it seemed like an interesting place
With the exploits published as-is, you'll only get root inside the container: there's no explicit namespace break, and calling setuid() in a container just gives you root in the container.
However, it can be used to modify files that are passed into the container (e.g. Docker run -v), or files that are shared with other containers (e.g. other Docker containers sharing the same layers). kube-proxy with Kubernetes happens to share a trusted binary with containers by default, which is how it can be exploited: https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...
You don't need any setuid binaries. You could just as easily use the vulnerability to add a job to crontab(5) that causes the cron daemon to run whatever you want as root.
reply