size_t-to-int vulnerability in Linux’s filesystem layer

Re:size_t-to-int vulnerability in Linux’s filesystem layer by jwilk on Wednesday July 21, 2021 @05:21AM (#27904067)

Linux does have a limit, at least for some system calls:

  $ strace -e trace=file perl -e 'open(FH, "<", "/" x 4096)'
  …
  openat(AT_FDCWD, "//////////…"..., O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENAMETOOLONG (File name too long)
  +++ exited with 0 +++

[ Parent | on HN ]

Re:size_t-to-int vulnerability in Linux’s filesystem layer by wahern on Wednesday July 21, 2021 @06:53AM (#27904602)

I stand corrected. It seems that Linux copies the entire path into a kernel-allocated buffer (see getname and getname_flags in fs/namei.c as called by various syscalls in fs/open.c), rejecting paths longer than PATH_MAX.

EDIT: And on Solaris PATH_MAX is 1024 and (AFAICT) Solaris also copies paths into kernel space. It seems I was confusing things with NL_TEXTMAX, which is INT_MAX on glibc (but not Solaris).

[ Parent | on HN ]

Re:size_t-to-int vulnerability in Linux’s filesystem layer by yencabulator on Sunday July 25, 2021 @07:09PM (#27953797)

There's a limit to what path string you can make the kernel interpret. That does not limit total path length. Keep looping on mkdirat/openat and you can make very very deep trees. As opposed to your syscall that is relative to an arbitrary directory, /proc/self/mountinfo has to contain the whole absolute path to be useful.

[ Parent | on HN ]