Bug 1117404

Summary: ksh shell segv faults when handling trap
Product: Red Hat Enterprise Linux 6 Reporter: Nathan Galvin <ngalvin>
Component: kshAssignee: Michal Hlavinka <mhlavink>
Status: CLOSED ERRATA QA Contact: Martin Kyral <mkyral>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.5CC: ccheney, dkutalek, kdudka, mhlavink, mkyral, ngalvin, ovasik, pandrade
Target Milestone: rcKeywords: Patch
Target Release: 6.7   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: ksh-20120801-26.el6 Doc Type: Bug Fix
Doc Text:
Previously, ksh in some cases terminated unexpectedly when re-setting a trap inside a function. With this update, ksh no longer uses invalid data for trap pointers and does not crash in this situation.
Story Points: ---
Clone Of:
: 1211540 (view as bug list) Environment:
Last Closed: 2015-07-22 06:55:54 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: 1211540    
Attachments:
Description Flags
ksh-20120801-trapcom.patch none

Description Nathan Galvin 2014-07-08 15:23:02 UTC
Description of problem:
ksh shell segv faults when handling trap in function

Version-Release number of selected component (if applicable):
ksh-20120801-10.el6_5.3.x86_64

How reproducible:
Very

Steps to Reproduce:
Example script to generate failure (repMon):
#!/bin/ksh
f()
{(
  trap "" HUP
)}
trap "" HUP
while [ 1 ] ; do
  f
done

./repMon
Segmentation fault (core dumped)

Expected results:
ksh does not crash

Additional info:
Failure does NOT occur on Solaris or RHEL 5.x - only RHEL 6.x.  Bash does not fault.

Tried workaround https://access.redhat.com/site/solutions/142573:
./repMon -c 2 nice -n19
Segmentation fault (core dumped)

Comment 2 Paulo Andrade 2014-08-24 00:09:31 UTC
I corrected this problem for Fedora, and am sure it is also
correct for RHEL.

The problem is that the sh_subshell function was saving pointers
that could change, and when restoring, bad things would happen.

I also added a %with_system_malloc build time option. It
is not enabled by default for the sake of not risking having
it trigger other problems elsewhere, but it was the only way
I managed to get system malloc and valgrind to hint me on the
actual problem.

I did not yet submit the patch upstream (as noted in the spec)
because I could not find a link to a bug report system at
http://www.kornshell.com/

Spec URL: https://pcpa.fedorapeople.org/ksh.spec
SRPM URL: https://pcpa.fedorapeople.org/ksh-20120801-21.fc20.src.rpm

Comment 3 Paulo Andrade 2014-08-27 12:42:42 UTC
Created attachment 931440 [details]
ksh-20120801-trapcom.patch

To make it a bit easier to verify the problem correction here is
the patch.

The only comment I added:
/* contents of shp->st.st.trapcom may change */
may be a bit misleading, the "bad" save/restore already knows it,
probably I should have added a better description telling that the
data is, usually, modified in code like:

tmp = buf[i]; buf[i] = strdup(tmp); free(tmp);

so the shp->st.st.trapcom needs a a "deep copy", as done in the
patch, to properly save/restore pointers.

Comment 4 Paulo Andrade 2014-08-28 12:18:14 UTC
I would like to note that the patch should be applied to all products
shipping ksh-20120801.

Comment 5 Michal Hlavinka 2014-08-28 12:43:21 UTC
This was fixed upstream about a year ago. As we are trying to stay close to upstream, to prevent future incompatibilities(and extra work when backporting other fixes in future), we will have to isolate their fix and use that. Please be aware, when you try to fix some bug, always test the latest upstream version first.

Comment 6 Paulo Andrade 2014-08-28 17:02:48 UTC
Thanks.

Do you have a suggested environment, like an experimental package
source, a git repository, etc, from where to generate the binary?

I can get access to links to downloads. The beta that is
ast-ksh.2014-06-25.tgz is the one with the most recent date
I can find.
When attempting to get access to the gitweb interface I land in
a cgi error page.

Anyway, looking in the related code of the latest beta, the code
itself is still not safe agains't the bug, so I supposed it no
longer trigger the problem (keeping pointers to and reusing or
freeing again already freed pointers) if code that previously was
doing the free/strdup sequence is no longer doing it.

Comment 16 errata-xmlrpc 2015-07-22 06:55:54 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-1450.html