Re: Possible newline injection into fdinfo

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2063 bytes --]

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?

Maybe it is time for a prctl that disables this legacy behavior?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]