Memory error on exporting XPC_SERVICE_NAME from a subshell

Memory error on exporting XPC_SERVICE_NAME from a subshell

[Varun Gandhi]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

Hey folks,

While bisecting my shell configuration for an unrelated issue, I ran into what looks like a use-after-free on exporting XPC_SERVICE_NAME from a subshell. Minimized example shown below:

❯ env -i -S'XPC_SERVICE_NAME=0' zsh --no-rcs
Varuns-MacBook-Pro% export
HOME=/Users/varun
LOGNAME=varun
OLDPWD=/Users/varun
PWD=/Users/varun
SHLVL=1
XPC_SERVICE_NAME=0
Varuns-MacBook-Pro% (export XPC_SERVICE_NAME=0)
zsh(29836,0x104d1c580) malloc: *** error for object 0x14c9043d0: pointer being freed was not allocated
zsh(29836,0x104d1c580) malloc: *** set a breakpoint in malloc_error_break to debug
zsh: abort      ( export XPC_SERVICE_NAME=0 ; )

Configuration information:
- zsh 5.8.1 (x86_64-apple-darwin21.0) (from /bin/zsh). This bug doesn't seem arch-specific, but I'll note that the x86_64 in the version is misleading, the binary is a universal one (arm64e + x86_64).
- macOS 12.4 (21F79) running on an M1 Mac.

Let me know if you're having trouble reproducing the issue.

Cheers,
Varun

[-- Attachment #2: Type: text/html, Size: 1509 bytes --]

Re: Memory error on exporting XPC_SERVICE_NAME from a subshell

[Bart Schaefer]

On Mon, Jul 18, 2022 at 11:46 AM Varun Gandhi <varun@cutcul.us> wrote:
>
> While bisecting my shell configuration for an unrelated issue, I ran into what looks like a use-after-free on exporting XPC_SERVICE_NAME from a subshell.

This is an error in a MacOS library routine.  Previously seen in zsh
with constructs like
% XPC_SERVICE_NAME=0 somecommand

However, if you're able to reproduce it with "env -i
-S'XPC_SERVICE_NAME=0'" then it's not limited to the zsh internals and
should probably be reported to Apple as well.

Re: Memory error on exporting XPC_SERVICE_NAME from a subshell

[Jun T]

> 2022/07/20 9:11, Bart Schaefer <schaefer@brasslantern.com> wrote:
> 
> On Mon, Jul 18, 2022 at 11:46 AM Varun Gandhi <varun@cutcul.us> wrote:
>> 
>> While bisecting my shell configuration for an unrelated issue, I ran into what looks like a use-after-free on exporting XPC_SERVICE_NAME from a subshell.
> 
> This is an error in a MacOS library routine.  Previously seen in zsh
> with constructs like
> % XPC_SERVICE_NAME=0 somecommand

The error occurs at line 5263 in params.c.

I din't know why the problem occurs only with XPC_SERVER_NAME, but
I think we can fix it (at least for relatively new macOS).

On macOS, USE_SET_UNSET_ENV is not defined because setenv(3) had a
strange feature that it removed a leading '=' from the value
(Bart's patch in workers/38432); line 786 in zsh_system.h.

But on my Macs setenv() behaves normally. I've looked into the
source (setenv.c) and manpage (getenv.3) of older macOS (now on
GitHub), and found that Apple has fixed this in macOS Sierra (10.12).
El Capitan (10.11) is the last version with this problem, but Apple
has stopped supporting El Capitan on Oct. 2018. There are very few
Macs still running El Captain or older OS X now (about 2% of Macs?).

So the simplest solution is to ignore El Capitan and older, and
remove !defined(__APPLE__) from the line 786 in zsh_system.h.

Or we can check the macOS version in configure.ac, as in the
patch below (I don't know the way to get the macOS version
from C preprocessor macro).

Or we can use the Peter's patch in workers/38433⁩ (with some fixes?).



diff --git a/Src/zsh_system.h b/Src/zsh_system.h
index 6f4efce96..16f724401 100644
--- a/Src/zsh_system.h
+++ b/Src/zsh_system.h
@@ -783,7 +783,8 @@ extern char **environ;
  * We always need setenv and unsetenv in pairs, because
  * we don't know how to do memory management on the values set.
  */
-#if defined(HAVE_SETENV) && defined(HAVE_UNSETENV) && !defined(__APPLE__)
+#if defined(HAVE_SETENV) && defined(HAVE_UNSETENV) \
+    && !defined(SETENV_MANGLES_EQUAL)
 # define USE_SET_UNSET_ENV
 #endif
 
diff --git a/configure.ac b/configure.ac
index 77e381f50..890ef8dd2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1515,6 +1515,14 @@ else
 zsh_cv_use_xattr=no
 fi])
 
+dnl We don't want to use setenv(3) on El Capitan or older OS X because it
+dnl removes a leading '=' from the value of the environment variable
+AH_TEMPLATE([SETENV_MANGLES_EQUAL],
+[Define to 1 if setenv removes a leading =])
+case $host_os in
+  darwin1[0-5]*) AC_DEFINE(SETENV_MANGLES_EQUAL) ;;
+esac
+
 dnl -------------
 dnl CHECK SIGNALS
 dnl -------------

Re: Memory error on exporting XPC_SERVICE_NAME from a subshell

[Bart Schaefer]

On Thu, Jul 21, 2022 at 2:46 AM Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
>
> So the simplest solution is to ignore El Capitan and older, and
> remove !defined(__APPLE__) from the line 786 in zsh_system.h.
>
> Or we can check the macOS version in configure.ac, as in the
> patch below (I don't know the way to get the macOS version
> from C preprocessor macro).
>
> Or we can use the Peter's patch in workers/38433⁩ (with some fixes?).

I still compile on some older (not upgradable) Mac laptops, but could
live with having to manually disable USE_SET_UNSET_ENV

Your suggested configure change is simpler than PWS's and would
probably be fine.  I don't think we ever got a working version of
38433, but if you want to chase that down, that would be the "most
complete" fix.