I noticed potentially missing input sanitization in dma_buf_set_name(), which is reachable from DMA_BUF_SET_NAME. This allows inserting a name containing a newline, which is then used to construct the contents of /proc/PID/task/TID/fdinfo/FD. This could confuse userspace programs that access this data, possibly tricking them into thinking a file descriptor is of a different type than it actually is.
Other code might have similar bugs. For instance, there is code that uses a sysfs path, a driver name, or a device name from /dev. It is possible to sanitize the first, and the second and third should come from trusted sources within the kernel itself. The last area where I found a potential problem is BPF. I don't know if this can happen. I think this should be fixed by either sanitizing data on write (by limiting the allowed characters in dma_buf_set_name()), on read (by using one of the formats that escapes special characters), or both. Is there a better way to identify that a file descriptor is of a particular type, such as an eventfd? fdinfo is subject to bugs of this type, which might happen again. readlink() reports "anon_inode:[eventfd]" and S_IFMT reports a mode of 0, but but my reading of the kernel source code is that neither is intended to be stable uAPI. Is there a better interface that can be used? -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
