Re: [yocto-patches] [pseudo] [PATCH 6/7] exec*: Replace bash workaround to avoid memory corruption
Richard Purdie <[email protected]> Thu, 02 Jul 2026 07:23:44 +0100
| Newsgroups | org.yoctoproject.lists.yocto-patches |
|---|---|
| Message-ID | <7a87ea66f1db2762737f424921a38eb6ce026dfe.camel@linuxfoundation.org> |
Hi Gaël, On Thu, 2026-07-02 at 07:54 +0200, Gaël PORTAY via lists.yoctoproject.org wrote: > On Wed Jul 1, 2026 at 3:13 PM CEST, Richard Purdie via lists.yoctoproject.org wrote: > > Bash intercepts getenv/setenv/unsetenv and does magic with it internally. > > > > The data pointed to by environ may not be allocated by glibc but by bash > > and the glibc env functions have their own memory handling outside of malloc. > > Unfortuantely bash doesn't keep environ and the result of setenv/getenv/unsetenv > > in sync either. This means the current workaround badly corrupts memory and it > > is just luck we're not breaking more often than the occasional opkg-build segfaults > > we've been seeing. > > > > Fixing this is tricky, the best we can probably do is to read through environ and > > create our own copy of the it, modifying it how we need to keep the pseudo variables > > correct. > > > > We do already have a function which can copyn and modify the environment, we can > > s,copyn,copy, I'll tweak, thanks. > > therefore swap some setupenv calls for setupenvp and switch out environ around > > the exec calls. > > > > Signed-off-by: Richard Purdie <[email protected]> > > --- > > ports/common/guts/execv.c | 19 ++++++++++++++----- > > ports/common/guts/execvp.c | 15 ++++++++++++--- > > ports/unix/guts/popen.c | 16 +++++++++++++--- > > ports/unix/guts/system.c | 16 +++++++++++++--- > > Don't you need to make these changes to execve(), and posix_spawn{,p}()? > i.e. in files: > - ports/common/guts/posix_spawnp.c > - ports/common/guts/posix_spawn.c > - ports/common/guts/execve.c Those already have a environment being passed in and so they already use setupenvp and we don't need to change that. We only need to change the places setupenv is being used. There are still some setupenv calls left and in theory we probably don't need many of them but they're harmless as long as we use bash's setenv so I just left them. Cheers, Richard