On Wed, Mar 04, 2026 at 01:53:42AM -0500, Demi Marie Obenour wrote: > 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
The problem is that most of the anonymous inodes share a single anonymous inode so any uapi that returns information based inode->i_op is not going to be usable. > bugs of this type, which might happen again. readlink() reports > "anon_inode:[eventfd]" and S_IFMT reports a mode of 0, but but my That is definitely uapi by now. We've tried to change S_IFMT and it breaks lsfd and other tools so we can't reasonably change it. In fact, pidfds pretend to be anon_inode even though they're not simply because some tools parse that out. > reading of the kernel source code is that neither is intended to be > stable uAPI. Is there a better interface that can be used?
