Re: -current tar(1) breakage

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sat, Apr 03, 2021 at 08:14:34PM -0000, Christos Zoulas wrote:
> In article <YGiV7Tup4jYZ9QdO%bec.de@localhost>, Joerg Sonnenberger  <joerg%bec.de@localhost> 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