On Wed, Jun 05, 2024 at 04:40:11PM +0200, Otto Moerbeek wrote:

> On Wed, Jun 05, 2024 at 02:55:57PM +0200, Alex Naumov wrote:
> 
> > Hey,
> > 
> > I tested a new version of the GNU screen on OpenBSD and found the bug.
> > I can't reproduce it on Linux, but it breaks a 'GNU screen' on OpenBSD
> > (crashes immediately after initialization. Just start 'screen')
> > 
> > The problem is here[1]. It seems that it's just the pointer problem (but I
> > don't understand why it works on Linux without any problem).
> > After it returns from the GrowBitfield function, the pointer to 'userbist'
> > is broken (address out of bounce [2]).
> > 
> > I compiled 'screen' on Linux with gcc and clang. It works.
> > I compiled it on OpenBSD with clang and gcc (CC=egcc). It crashed in both
> > cases.
> > 
> > I tried to play with sysctl vm.malloc_conf options [2], but it also doesn't
> > help.
> > 
> > Maybe someone will find time to analyze it and help me to understand/fix
> > this bug.
> > Thank you.
> > 
> > Cheers,
> > Alex
> > 
> > [1] https://git.savannah.gnu.org/cgit/screen.git/tree/src/acls.c#n103
> > [2] https://paste.opensuse.org/pastes/4934561ea6fb
> > [3] sysctl vm.malloc_conf='CFGJS<<'
> 
> You are hitting the case where you pass (1, 0) to calloc. The ACLBYTE
> macro will return &NULL[(0 + 1) >> 3] equals 0.
> 
> On some systems (including OpenBSD) this will return a zero sized
> object: a unique pointer that points to unaccessable memory. This is
> permitted by the standards.
> 
> This is one of the differences between Linux and OpenBSD.  Make sure
> you do not acess the memmory, or handle zero-sized allocations as a
> special case.

Actually, it might be that the + 1 in the size computation is not
in the right place.

	-Otto