[LTP] [PATCH v2] syscalls/statmount07: change "invalid buffer size" test

Jan Stancek jstancek@redhat.com
Tue Oct 15 15:54:38 CEST 2024


On Tue, Oct 15, 2024 at 3:44 PM Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> > Are you sure?
> >
> > 17019 08:32:23 write(2, "tst_buffers.c:57: \33[1;34mTINFO: "..., 66) = 66
> > 17019 08:32:23 mmap(NULL, 8192, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ff94f75000
> > 17019 08:32:23 mprotect(0x3ff94f76000, 4096, PROT_NONE) = 0
> >
> > st_mount_bad: 0x3ff94f75fff
> > (/proc/self/maps)
> > ...
> > 3ff94f2e000-3ff94f30000 rw-p 0002e000 fd:03 67110911
> >   /usr/lib/ld64.so.1
> > 3ff94f75000-3ff94f76000 rw-p 00000000 00:00 0
> > 3ff94f76000-3ff94f77000 ---p 00000000 00:00 0
> > 3ff94f77000-3ff94f7b000 rw-p 00000000 00:00 0
> > 3fffba5a000-3fffba7b000 rw-p 00000000 00:00 0                            [stack]
> > 3fffba9f000-3fffbaa1000 r--p 00000000 00:00 0                            [vvar]
> > 3fffbaa1000-3fffbaa3000 r-xp 00000000 00:00 0                            [vdso]
> >
> > >, since guarded buffers are primarily guarding about off-by-one
> > > at the start of the buffer.
> >
> > I'd expect going over end of buffer to be a lot more common.
>
> Sigh, for some reason I had the case with PROT_NONE before the buffer
> stored in my memory, maybe that was one of the versions the patchset
> went through. Sorry for misleading reply.

No worries, thanks for review.

>
> --
> Cyril Hrubis
> chrubis@suse.cz
>



More information about the ltp mailing list