On Tue, Jul 27, 2021 at 03:30:55PM +0200, Greg Kroah-Hartman wrote: > On Tue, Jul 27, 2021 at 02:14:37PM +0100, Matthew Wilcox wrote: > > On Tue, Jul 27, 2021 at 02:56:53PM +0200, Greg Kroah-Hartman wrote: > > > And my mistake from earlier, size_t is the same as unsigned int, not > > > unsigned long. > > > > No. > > > > include/linux/types.h:typedef __kernel_size_t size_t; > > > > include/uapi/asm-generic/posix_types.h: > > > > #ifndef __kernel_size_t > > #if __BITS_PER_LONG != 64 > > typedef unsigned int __kernel_size_t; > > #else > > typedef __kernel_ulong_t __kernel_size_t; > > #endif > > #endif > > > > size_t is an unsigned long on 64-bit, unless otherwise defined by the > > arch. > > ugh, ok, so there really is a problem, as we have a size_t value being > passed in as an int, and then it could be treated as a negative value > for some fun pointer math to copy buffers around. > > How is this not causing problems now already? Are we just getting > lucky? include/uapi/linux/limits.h:#define PATH_MAX 4096 /* # chars in a path name including nul */ Clearly some places aren't checking that, but _in principle_, you aren't supposed to be able to create a pathname longer than that.
