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

Re:size_t-to-int vulnerability in Linux’s filesystem layer by wahern on Tuesday July 20, 2021 @07:41PM (#27900607)

The Linux kernel doesn't have an actual path limit. Nor does Solaris. PATH_MAX is 4096 in glibc and musl libc because setting to it to something like INT_MAX or ULONG_MAX would break a lot of existing code that uses PATH_MAX to size buffers. (Though Solaris does define it as INT_MAX, IIRC.) OTOH, because of the lack of a hard limit there's also code that relies (if accidentally) on paths longer than PATH_MAX.

[ Parent | on HN ]

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 ]

Re:size_t-to-int vulnerability in Linux’s filesystem layer by yrro on Wednesday July 21, 2021 @07:00AM (#27904663)

https://eklitzke.org/path-max-is-tricky

The Linux kernel defines upper limits for NAME_MAX (255) and PATH_MAX (4096).

The glibc doesn't enforce this limit because it was originally written to run on GNU HURD which I guess doesn't have these limits.

But systemd only runs on glibc on Linux. So I don't see why it doesn't at least sanity check the length of absolute paths with PATH_MAX...

[ Parent | on HN ]