Re: bin/55979 (sh single quotes removes nul characters)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/55979; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost, kamil%netbsd.org@localhost
Cc: 
Subject: Re: bin/55979 (sh single quotes removes nul characters)
Date: Wed, 10 Feb 2021 23:48:13 +0700

     Date:        Wed, 10 Feb 2021 08:45:02 +0000 (UTC)
     From:        Kamil Rytarowski <kamil=40netbsd.org>
     Message-ID:  <20210210084502.5509F1A9241=40mollari.NetBSD.org>
 
   =7C  SUMMARY: MemorySanitizer: use-of-uninitialized-value
   =7C  /usr/src/bin/sh/exec.c:138:18 in shellexec
   =7C  Exiting
   =7C  ./hello.com: 6: Syntax error: =22)=22 unexpected
   =7C =20
   =7C  There is something wrong with or around padvance(). ':' gets strip=
 ped
   =7C  from PATH and there is an uninitialized memory read.
 
 I will take a look at that, but first, Kamil can you tell me which sh
 source version you used for that, HEAD, or netbsd-9, or ?   (Perhaps the
 cvs version numbers of exec.c and eval.c).
 
 Also, which hello.com are you using?  When I try it (with the original
 from the original PR, fetched soon after it was filed) I see:
 
 	jinx=24 ./sh /tmp/hello.com
 	./sh: Cannot execute ELF binary /tmp/hello.com
 
 which is exactly what I'd expect to see (but version I have does not
 start with that =22MZqFpD=3D=5Cn=22 string).
 
 The analysis from msan is a little odd, as cmdentry local var (struct)
 used in evalcommand(), and while fields from it are passed to other funct=
 ions,
 the struct itself is not (nor is its address ever evaluated), so it is a
 bit hard to imagine how shellexec() is reading uninit'd values from it.
 
 On the other hand, when evalcommand() calls shellexec() it does pass
 cmdentry.u.index (a field in a union in the struct) as one of the paramet=
 ers,
 but if that is the uninit'd value, I'd have expected it to be detected
 where it is fetched (in evalcommand()) rather than where the value is use=
 d.
 
 Apart from that, about all I can imagine is that something has a wild
 pointer which is accessing random stack memory -- that or perhaps the
 random(ish) binary data which is being used here is somehow fooling msan
 into believing something different than what is actually happening.
 
 kre
 
 ps: everyone ignore the questing/comment about mmap() ... martin=40
 reminded me that that's just malloc() doing its thing.   I date from
 the days when malloc() used sbrk()...