* Jann Horn <ja...@google.com> wrote:
> - A malicious user can pass an arbitrary file to a setuid binary as > stdin/stdout/stderr. When the setuid binary (expecting stdin/stdout to > be something normal, like a proper file or a pipe) then calls read(0, > <buf>, <len>), if the kernel disregards the length argument and writes > beyond the end of the buffer, it can corrupt adjacent userspace data, > potentially allowing a user to escalate their privileges; a write > handler is somewhat less interesting because it can probably (as in > this case) only leak out-of-bounds data from the caller, not corrupt > it, but it's still a concern in theory. BTW., a naive question: would it make sense to simply disallow 'special' fds to be passed to setuid binaries, and fix any user-space that breaks? (i.e. only allow regular files and pipes/sockets.) Also, don't allow splice() on special files either, except if the driver explicitly opts in to it. Sounds a lot more robust in the long run than playing whack-a-mole with the *inevitable* hole in special read() and write() handlers in our 3,000+ device drivers... Thanks, Ingo