On Thu, Sep 3, 2020 at 6:58 AM Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> wrote: > > On Thu, Sep 03, 2020 at 02:43:40PM +0100, Matthew Wilcox wrote: > > On Thu, Sep 03, 2020 at 04:25:37PM +0300, Kirill A. Shutemov wrote: > > > IIUC, it gives userspace direct control of content of /proc/$PID/maps and > > > /proc/$PID/smaps. There's no verification of the given string whatsoever. > > > I'm sure security experts would find clever usage of the feature :P > > > > What, you think that naming a VMA > > "\n55bc3e0f9000-55bc3e0fb000 r--p 00000000 fd:01 16777285 /bin/cat" might cause problems? The data is wrapped inside "[anon: ]", which limits the ability to masquerade as a real file. > Something that would cause buffer overrun or out-of-bound access in a > privilaged parser can be even more interesting. :) This is the same as /proc/pid/cmdline, which has no sanitization. It's also limited to 255 bytes, which should hopefully limit the opportunity for a buffer overrun. > > Would it be enough to restrict the characters to isalnum()? > > I guess. > > But current design stores userspace pointer and there's time-of-check vs. > time-of-use problem. It copies from userspace into a kernel buffer at read time, any desired sanitization could easily be added there. > -- > Kirill A. Shutemov >
