1267251 – crash in ksh mode with -n and $HOME [RHEL-7]

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1267251 - crash in ksh mode with -n and $HOME [RHEL-7]

Summary: crash in ksh mode with -n and $HOME [RHEL-7]

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	zsh
Sub Component:
Version:	7.0
Hardware:	x86_64
OS:	Linux
Priority:	unspecified
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Kamil Dudka
QA Contact:	Jan Kepler
Docs Contact:	Maxim Svistunov
URL:
Whiteboard:
Duplicates (1):	1389492 (view as bug list)
Depends On:	1269883
Blocks:	1203710 1289025 1295396 1295829 1313485
TreeView+	depends on / blocked

Reported:	2015-09-29 13:03 UTC by Tim Speetjens
Modified:	2019-10-10 10:15 UTC (History)
CC List:	7 users (show)
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.
Clone Of:
Clones:	1269883 (view as bug list)
Environment:
Last Closed:	2016-11-03 23:01:59 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2016:2152	0	normal	SHIPPED_LIVE	zsh bug fix update	2016-11-03 13:13:01 UTC

Description Tim Speetjens 2015-09-29 13:03:43 UTC

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 13:14:34 UTC

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 13:18:04 UTC

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 13:20:57 UTC

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 14:44:40 UTC

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 14:59:01 UTC

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 19:50:02 UTC

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 06:26:40 UTC

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 15:44:21 UTC

(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 16:37:34 UTC

(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 12:18:29 UTC

upstream commit:

https://sourceforge.net/p/zsh/code/ci/83a17579

Comment 19 Zdenek Pytela 2016-10-21 12:23:57 UTC

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 18:53:51 UTC

(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 12:35:43 UTC

*** Bug 1389492 has been marked as a duplicate of this bug. ***

Comment 24 errata-xmlrpc 2016-11-03 23:01:59 UTC

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.