Bug 1222867

Summary: zsh in ksh emulation mode, coredumps when trying to check the syntax of a shell script
Product: Red Hat Enterprise Linux 7 Reporter: Tim Speetjens <tspeetje>
Component: zshAssignee: Kamil Dudka <kdudka>
Status: CLOSED ERRATA QA Contact: Jan Kepler <jkejda>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 7.0CC: fkrska, isenfeld, mkolaja, msvistun, ovasik
Target Milestone: rcKeywords: Patch, ZStream
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: zsh-5.0.2-11.el7 Doc Type: Bug Fix
Doc Text:
Previously, the code that initializes environment variables in zsh did not correctly handle NULL values. As a consequence, zsh terminated unexpectedly when attempting to check the syntax of a shell script in ksh emulation mode. This update fixes the handling of NULL values, and the syntax check now works as expected when zsh runs in ksh emulation mode.
Story Points: ---
Clone Of:
: 1274697 (view as bug list) Environment:
Last Closed: 2015-11-19 05:20:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1274697    

Description Tim Speetjens 2015-05-19 10:28: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

Fedora21:
zsh-5.0.7-7.fc21.x86_64

How reproducible:
100%

Steps to Reproduce:

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

2 Test syntax
$ ksh -n test

Actual results:
zsh coredumps

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

Additional info:

$ which ksh
/usr/bin/ksh

$ ls -l ksh
lrwxrwxrwx. 1 root root 3 May 19 11:55 ksh -> zsh

On RHEL7 (zsh-5.0.2-7.el7.x86_64)
Core was generated by `ksh -n test'.
Program terminated with signal 11, Segmentation fault.
#0  mkenvstr (name=0x20fcdf0 "HOME", value=0x0, flags=flags@entry=4198400) at params.c:4496
4496		 *s && (*s++ != Meta || *s++ != 32); len_value++);
(gdb) bt
#0  mkenvstr (name=0x20fcdf0 "HOME", value=0x0, flags=flags@entry=4198400) at params.c:4496
#1  0x000000000046312e in createparamtable () at params.c:741
#2  0x000000000043e71f in setupvals () at init.c:987
#3  0x000000000044060c in zsh_main (argc=<optimized out>, argv=<optimized out>) at init.c:1596
#4  0x00007fe7d4056af5 in __libc_start_main (main=0x40eca0 <main>, argc=3, ubp_av=0x7fff92db4098, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, 
    stack_end=0x7fff92db4088) at libc-start.c:274
#5  0x000000000040ecd1 in _start ()
(gdb) 

Running the same check with zsh runs fine

Comment 2 Kamil Dudka 2015-05-19 18:15:24 UTC
Thank you for reporting the bug!

The following patch fixes the problem for me:

--- a/Src/params.c
+++ b/Src/params.c
@@ -4574,22 +4574,24 @@ addenv(Param pm, char *value)


 /* Given strings *name = "foo", *value = "bar", *
  * return a new string *str = "foo=bar".        */

 /**/
 static char *
 mkenvstr(char *name, char *value, int flags)
 {
     char *str, *s;
     int len_name, len_value;
+    if (!value)
+       return NULL;

     len_name = strlen(name);
     for (len_value = 0, s = value;
         *s && (*s++ != Meta || *s++ != 32); len_value++);
     s = str = (char *) zalloc(len_name + len_value + 2);
     strcpy(s, name);
     s += len_name;
     *s = '=';
     copyenvstr(s, value, flags);
     return str;
 }

I will check with upstream whether it is a correct way to fix it.

Comment 3 Kamil Dudka 2015-05-20 17:36:33 UTC
upstream commit:

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

Comment 7 Kamil Dudka 2015-05-22 14:49:38 UTC
fixed in zsh-5.0.7-8.fc2{0,1,2,3}

Comment 8 Kamil Dudka 2015-09-29 13:14:34 UTC
*** Bug 1267251 has been marked as a duplicate of this bug. ***

Comment 13 errata-xmlrpc 2015-11-19 05:20:32 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-2015-2208.html