On Sat, Apr 03, 2021 at 08:14:34PM -0000, Christos Zoulas wrote: > In article <ygiv7tup4jyz9...@bec.de>, Joerg Sonnenberger <jo...@bec.de> > wrote: > >On Sat, Apr 03, 2021 at 01:15:15AM -0400, Christos Zoulas wrote: > >> Yes, I think that the appropriate change is to make those assertions > >> so if there is a broken filesystem/syscall there is a more obvious > >> error (rather than infinite loop in read or core-dump in iconv), but let's > >> see what joerg thinks about all that. > > > >The infinite loops are perfectly reasonable behavior for broken kernel > >input and found in other tools using the interface. IMO the kernel > >should always do a sanity cap for puffs/fuse here. > > Yes, but defensive programming is good. > > >The iconv coredump is a buffer overflow, but nothing libarchive can do > >about. The memory allocated for the dirent is based on the namemax of > >the filesystem and we kind of have to trust the filesystem to do what it > >promised. The system call doesn't have a size argument... > > Right, but it can check if the size makes sense before using it.
The next filesystem will put one in the field and we are back... Joerg
