Bug 1267251 - crash in ksh mode with -n and $HOME [RHEL-7]
crash in ksh mode with -n and $HOME [RHEL-7]
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: zsh (Show other bugs)
7.0
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Kamil Dudka
Jan Kepler
Maxim Svistunov
: Patch
: 1389492 (view as bug list)
Depends On: 1269883
Blocks: 1203710 1295396 1313485 1289025 1295829
  Show dependency treegraph
 
Reported: 2015-09-29 09:03 EDT by Tim Speetjens
Modified: 2016-11-03 19:01 EDT (History)
7 users (show)

See Also:
Fixed In Version: zsh-5.0.2-17.el7
Doc Type: Bug Fix
Doc Text:
Syntax check in *ksh* compatibility mode now works as expected in *zsh* Previously, while checking the syntax of a shell script in *ksh* compatibility mode, *zsh* incorrectly initialized the `$HOME` internal variable. Consequently, the *zsh* process terminated unexpectedly after it attempted to dereference a *NULL* pointer. With this update, the $HOME internal variable is properly initialized. As a result, the syntax check in *ksh* compatibility mode now works as expected in *zsh*.
Story Points: ---
Clone Of:
: 1269883 (view as bug list)
Environment:
Last Closed: 2016-11-03 19:01:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Speetjens 2015-09-29 09:03:43 EDT
Description of problem:
zsh in ksh emulation mode, coredumps when trying to check the syntax of a shell script


Version-Release number of selected component (if applicable):
RHEL7:
zsh-5.0.2-7.el7.x86_64

How reproducible:
100%

Steps to Reproduce:

1 Create test script:
$ cat <<EOF > test1.ksh
#!/usr/bin/ksh
echo $HOME
EOF

or

$ cat <<EOF > test2.ksh
#!/usr/bin/ksh
V=$HOME
EOF

$ cat <<EOF > test3.ksh
#!/usr/bin/ksh
export V=${HOME}
EOF


2 Test syntax
$ ksh -n test1.ksh

$ ksh -n test2.ksh

Actual results:
zsh coredumps, in both occurences

Expected results:
exit cleanly, with code 0 or 1, depending on validity of the given script

Additional info:
Some variations of using the HOME env variable are ok:
D=${HOME} or D=$HOME, for example
This issue is similar to bz#1222867, but the fix for that issue doesn't fix this one.

$ which ksh
/usr/bin/ksh

$ ls -l ksh
lrwxrwxrwx. 1 root root 3 May 19 11:55 ksh -> zsh
Comment 1 Kamil Dudka 2015-09-29 09:14:34 EDT
I believe this is fixed in zsh-5.0.2-14.el7.

*** This bug has been marked as a duplicate of bug 1222867 ***
Comment 2 Tim Speetjens 2015-09-29 09:18:04 EDT
The scripts that do core dump are:

$ cat <<EOF > test1.ksh
#!/usr/bin/ksh
echo $HOME
EOF

or

$ cat <<EOF > test2.ksh
#!/usr/bin/ksh
export V=${HOME}
EOF

Not the one with only V=$HOME.

I did test it with the package that should have fixed the issue. Also the backtraces are very different.
Comment 3 Tim Speetjens 2015-09-29 09:20:57 EDT
Backtrace from checking the first script:

(gdb) bt
#0  sepsplit (s=0x0, sep=sep@entry=0x0, allownull=allownull@entry=0, heap=heap@entry=1) at utils.c:3198
#1  0x000000000047c1da in paramsubst (pf_flags=<optimized out>, qt=<optimized out>, str=0x7ffdc3b69070, n=<optimized out>, 
    l=<optimized out>) at subst.c:3242
#2  stringsubst (list=list@entry=0x7f34d129a130, node=<optimized out>, pf_flags=<optimized out>, pf_flags@entry=0, asssub=asssub@entry=0)
    at subst.c:236
#3  0x000000000047e7c5 in prefork (list=list@entry=0x7f34d129a130, flags=0) at subst.c:77
#4  0x0000000000428d98 in execcmd (state=state@entry=0x7ffdc3b69950, input=input@entry=0, output=output@entry=0, how=how@entry=18, last1=2)
    at exec.c:2587
#5  0x000000000042b356 in execpline2 (state=state@entry=0x7ffdc3b69950, pcode=pcode@entry=195, how=how@entry=18, input=0, output=0, 
    last1=last1@entry=0) at exec.c:1685
#6  0x000000000042b78c in execpline (state=state@entry=0x7ffdc3b69950, slcode=<optimized out>, how=how@entry=18, last1=0) at exec.c:1470
#7  0x000000000042cb12 in execlist (state=state@entry=0x7ffdc3b69950, dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0)
    at exec.c:1253
#8  0x000000000042ce02 in execode (p=p@entry=0x7f34d129a0b0, dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0, 
    context=context@entry=0x48ef99 "toplevel") at exec.c:1062
#9  0x000000000043d4a2 in loop (toplevel=toplevel@entry=1, justonce=justonce@entry=0) at init.c:185
#10 0x000000000044074e in zsh_main (argc=<optimized out>, argv=<optimized out>) at init.c:1616
#11 0x00007f34d0176af5 in __libc_start_main (main=0x40ecf0 <main>, argc=3, ubp_av=0x7ffdc3b69b88, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdc3b69b78) at libc-start.c:274


From checking the second one
(gdb) bt
#0  __strlen_sse2_pminub () at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:38
#1  0x000000000047bcd2 in paramsubst (pf_flags=<optimized out>, qt=<optimized out>, str=0x7ffdec4aca80, n=<optimized out>, 
    l=<optimized out>) at subst.c:3719
#2  stringsubst (list=list@entry=0x7fbf76307130, node=<optimized out>, pf_flags=<optimized out>, pf_flags@entry=0, asssub=asssub@entry=1)
    at subst.c:236
#3  0x000000000047e7c5 in prefork (list=list@entry=0x7fbf76307130, flags=1) at subst.c:77
#4  0x0000000000428d98 in execcmd (state=state@entry=0x7ffdec4ad360, input=input@entry=0, output=output@entry=0, how=how@entry=18, last1=2)
    at exec.c:2587
#5  0x000000000042b356 in execpline2 (state=state@entry=0x7ffdec4ad360, pcode=pcode@entry=195, how=how@entry=18, input=0, output=0, 
    last1=last1@entry=0) at exec.c:1685
#6  0x000000000042b78c in execpline (state=state@entry=0x7ffdec4ad360, slcode=<optimized out>, how=how@entry=18, last1=0) at exec.c:1470
#7  0x000000000042cb12 in execlist (state=state@entry=0x7ffdec4ad360, dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0)
    at exec.c:1253
#8  0x000000000042ce02 in execode (p=p@entry=0x7fbf763070b0, dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0, 
    context=context@entry=0x48ef99 "toplevel") at exec.c:1062
#9  0x000000000043d4a2 in loop (toplevel=toplevel@entry=1, justonce=justonce@entry=0) at init.c:185
#10 0x000000000044074e in zsh_main (argc=<optimized out>, argv=<optimized out>) at init.c:1616
#11 0x00007fbf751e3af5 in __libc_start_main (main=0x40ecf0 <main>, argc=3, ubp_av=0x7ffdec4ad598, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdec4ad588) at libc-start.c:274
#12 0x000000000040ed21 in _start ()
(gdb)
Comment 5 Kamil Dudka 2015-09-29 10:44:40 EDT
As discussed on IRC, this is likely not a duplicate of bug #1222867 but it still seems to be fixed in zsh-5.0.2-14.el7.  The backtrace in comment #3 is obtained using zsh from a scratch build that I have not the corresponding source code for.

Please provide steps to reproduce using the tagged brew build zsh-5.0.2-14.el7.
Comment 6 Tim Speetjens 2015-09-29 10:59:01 EDT
In my testing, the issue also occurs in zsh-5.0.2-14.el7.

Backtraces are identical, with the exception of some line number differences in exec.c (+2)
Comment 7 Kamil Dudka 2015-09-29 15:50:02 EDT
I tried a fresh RHEL-7.1 machine with zsh-5.0.2-14.el7 installed on top of that and both tests worked as expected.  Please provide steps to reproduce the crash applicable on a fresh RHEL-7.1 machine.
Comment 9 Tim Speetjens 2015-09-30 02:26:40 EDT
Looks like I blindly copied the method to create the files, which replace $HOME to its actual value.

The files should instead be created using the following commands:

$ cat <<EOF > test1.ksh
#!/usr/bin/ksh
echo \$HOME
EOF

or

$ cat <<EOF > test2.ksh
#!/usr/bin/ksh
export V=\${HOME}
EOF
Comment 10 Kamil Dudka 2015-10-01 11:44:21 EDT
(In reply to Tim Speetjens from comment #9)
> Looks like I blindly copied the method to create the files, which replace
> $HOME to its actual value.

Thank you for clarifying that!

> The files should instead be created using the following commands:
> 
> $ cat <<EOF > test1.ksh
> #!/usr/bin/ksh
> echo \$HOME
> EOF

This crashes even with the latest upstream version of zsh.

> or
> 
> $ cat <<EOF > test2.ksh
> #!/usr/bin/ksh
> export V=\${HOME}
> EOF

This crash seems to be fixed (or avoided) in the current upstream version.
Comment 11 Kamil Dudka 2015-10-05 12:37:34 EDT
(In reply to Kamil Dudka from comment #10)
> > $ cat <<EOF > test1.ksh
> > #!/usr/bin/ksh
> > echo \$HOME
> > EOF
> 
> This crashes even with the latest upstream version of zsh.

Reported upstream:

http://www.zsh.org/mla/workers/2015/msg02696.html

> > $ cat <<EOF > test2.ksh
> > #!/usr/bin/ksh
> > export V=\${HOME}
> > EOF
> 
> This crash seems to be fixed (or avoided) in the current upstream version.

Assuming the fix for bug #1222867 is applied (it actually came later):

https://sourceforge.net/p/zsh/code/ci/af957f2e

... the crash was avoided by the following upstream commit:

https://sourceforge.net/p/zsh/code/ci/44757a65

... where it started to print the following diagnostic message:

    1: subst.c:3712: value is NULL in paramsubst

The diagnostic message went away with the following upstream commit:

https://sourceforge.net/p/zsh/code/ci/39b28980

Nevertheless the following command still crashes with the latest upstream:

$ ARGV0=ksh zsh -nc 'export .V=${HOME}'
Comment 12 Kamil Dudka 2015-10-08 08:18:29 EDT
upstream commit:

https://sourceforge.net/p/zsh/code/ci/83a17579
Comment 19 Zdenek Pytela 2016-10-21 08:23:57 EDT
I can confirm the test scripts from

https://access.redhat.com/solutions/2221031

lead to coredump in zsh-5.0.2-14.el7_2.2.x86_64 (latest atm) as well:

#0  __strlen_sse2_pminub () at ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:38
#1  0x00000000004819d2 in paramsubst (pf_flags=<optimized out>, qt=<optimized out>,
    str=0x7fffa70326b0, n=<optimized out>, l=<optimized out>) at subst.c:3719
#2  stringsubst (list=list@entry=0x7efffb63f1b8, node=<optimized out>, pf_flags=<optimized out>,
    pf_flags@entry=0, asssub=asssub@entry=1) at subst.c:236
#3  0x00000000004844c5 in prefork (list=list@entry=0x7efffb63f1b8, flags=1) at subst.c:77
#4  0x00000000004296a8 in execcmd (state=state@entry=0x7fffa7034190, input=input@entry=0,
    output=output@entry=0, how=how@entry=18, last1=2) at exec.c:2611
#5  0x000000000042c2a6 in execpline2 (state=state@entry=0x7fffa7034190, pcode=pcode@entry=195,
    how=how@entry=18, input=0, output=0, last1=last1@entry=0) at exec.c:1707
#6  0x000000000042c6e3 in execpline (state=state@entry=0x7fffa7034190, slcode=<optimized out>,
    how=how@entry=18, last1=0) at exec.c:1487
#7  0x000000000042e475 in execlist (state=state@entry=0x7fffa7034190,
    dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0) at exec.c:1259
#8  0x000000000042e762 in execode (p=p@entry=0x7efffb63f138,
    dont_change_job=dont_change_job@entry=0, exiting=exiting@entry=0,
    context=context@entry=0x495299 "toplevel") at exec.c:1062
#9  0x000000000044098f in loop (toplevel=toplevel@entry=1, justonce=justonce@entry=0)
    at init.c:187
#10 0x00000000004440ce in zsh_main (argc=<optimized out>, argv=<optimized out>) at init.c:1620
#11 0x00007efffa512b15 in __libc_start_main (main=0x40ed30 <main>, argc=3,
    ubp_av=0x7fffa7034558, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffa7034548) at libc-start.c:274
#12 0x000000000040ed61 in _start ()

Is it possible to obtain the updates zsh package for testing?
Comment 20 Kamil Dudka 2016-10-23 14:53:51 EDT
(In reply to Zdenek Pytela from comment #19)
> lead to coredump in zsh-5.0.2-14.el7_2.2.x86_64 (latest atm) as well:

zsh-5.0.2-14.el7_2.2 does not contain a fix for this bug, but it is going to be fixed in RHEL-7.3 (zsh-5.0.2-17.el7 or newer, as the Fixed In Version field suggests).
Comment 22 Kamil Dudka 2016-10-31 08:35:43 EDT
*** Bug 1389492 has been marked as a duplicate of this bug. ***
Comment 24 errata-xmlrpc 2016-11-03 19:01:59 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2152.html

Note You need to log in before you can comment on or make changes to this bug.