Possible newline injection into fdinfo

[Demi Marie Obenour]

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)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature