Re: Possible newline injection into fdinfo

[Christian Brauner <brauner@kernel.org>]

On Wed, Mar 04, 2026 at 01:57:31PM -0500, Demi Marie Obenour wrote:
> On 3/4/26 08:03, Christian Brauner wrote:
> > 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.
> 
> Does Linux guarantee that anything that is not an anonymous inode
> will have (st_mode & S_IFMT) != 0?

Ignoring bugs or disk corruption anonymous inodes should be the only
inode type that has a zero type. Everything else should have a non-zero
type and the I made the VFS splat in may_open():

          switch (inode->i_mode & S_IFMT) {
          case S_IFLNK:
                  return -ELOOP;
          case S_IFDIR:
                  if (acc_mode & MAY_WRITE)
                          return -EISDIR;
                  if (acc_mode & MAY_EXEC)
                          return -EACCES;
                  break;
          case S_IFBLK:
          case S_IFCHR:
                  if (!may_open_dev(path))
                          return -EACCES;
                  fallthrough;
          case S_IFIFO:
          case S_IFSOCK:
                  if (acc_mode & MAY_EXEC)
                          return -EACCES;
                  flag &= ~O_TRUNC;
                  break;
          case S_IFREG:
                  if ((acc_mode & MAY_EXEC) && path_noexec(path))
                          return -EACCES;
                  break;
          default:
                  VFS_BUG_ON_INODE(!IS_ANON_FILE(inode), inode);
          }

> Maybe it is time for a prctl that disables this legacy behavior?

I've switched anonymous inodes internally to S_IFREG a while ago in [1]
and then masked it off for userspace. Even just the internal conversion
caused various subsystems like io_uring to lose it which is why we
reverted it in [2].

So any next attempt needs to ensure that there are no internal and no
external regressions. And no prctl()s please. It's a strong contender
for Linux' main landfill next to procfs.

Ideally we'd just look at lsfd and lsof and move them away from any type
assertions. I have asked them to do that for pidfds a while ago and they
have merged a patch to that effect.

[1]: cfd86ef7e8e7 ("anon_inode: use a proper mode internally")
[2]: 1e7ab6f67824 ("anon_inode: rework assertions")