Bug 1117404 - ksh shell segv faults when handling trap
Summary: ksh shell segv faults when handling trap
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ksh
Version: 6.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: 6.7
Assignee: Michal Hlavinka
QA Contact: Martin Kyral
URL:
Whiteboard:
Depends On:
Blocks: 1211540
TreeView+ depends on / blocked
 
Reported: 2014-07-08 15:23 UTC by Nathan Galvin
Modified: 2019-08-15 03:53 UTC (History)
8 users (show)

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.
Clone Of:
: 1211540 (view as bug list)
Environment:
Last Closed: 2015-07-22 06:55:54 UTC


Attachments (Terms of Use)
ksh-20120801-trapcom.patch (1.71 KB, patch)
2014-08-27 12:42 UTC, Paulo Andrade
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1450 normal SHIPPED_LIVE ksh bug fix update 2015-07-20 18:43:49 UTC

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


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