Package: ksh
Version: 93u+20120801
Severity: normal
Dear Maintainer,
* Problem:
==
The compiler optimization dropped parts from the ksh job locking mechanism from
the binary code.
As a consequence, ksh could terminate unexpectedly with a segmentation fault
after it received
the SIGCHLD signal.
(gdb) bt
#0 job_chksave (pid=pid@entry=19003) at
/build/ksh-6IEHIC/ksh-93u+20120801/src/cmd/ksh93/sh/jobs.c:1948
#1 0x00000000004282ab in job_reap (sig=17) at
/build/ksh-6IEHIC/ksh-93u+20120801/src/cmd/ksh93/sh/jobs.c:428
#2 <signal handler called>
[New LWP 3882]
Core was generated by `/bin/ksh <KSH_SCRIPT>.ksh'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 job_chksave (pid=pid@entry=19385) at
/build/ksh-6IEHIC/ksh-93u+20120801/src/cmd/ksh93/sh/jobs.c:1948
1948 if(jp->pid==pid)
(gdb) p *jp
Cannot access memory at address 0xb
(gdb) p *jp->pid
Cannot access memory at address 0x13
(gdb) p pid
$2 = 19385
(gdb) p *jpold
$1 = {next = 0xb, pid = -604008960, exitval = 11124}
The struct is corrupted at some point looking at the next,pid and exitval
struct members values which isn't valid data.
# assembly code
=> 0x0000000000427159 <+41>: cmp %edi,0x8(%rdx)
(gdb) p $edi ## pid variable
$1 = 19385
(gdb) p *($rdx + 8) ## jp->pid struct
Cannot access memory at address 0x13
==
* Solution :
==
ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new
development is made upstream nor in debian upstream, but
Red Hat implement their own fix for this particular issue :
* Details about the RH bug :
- https://bugzilla.redhat.com/show_bug.cgi?id=1123467
- https://bugzilla.redhat.com/show_bug.cgi?id=1112306
- https://access.redhat.com/solutions/1253243
- http://rhn.redhat.com/errata/RHBA-2014-1015.html
# ksh.spec
Fri Jul 25 2014 Michal Hlavinka <mhlav...@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
==
I have provided a ksh Ubuntu test package to the bug reporter who had a
reproducer, including the Red Hat fix and the reporter couldn't reproduce the
situation anymore.
He tried over 3000 times so far and stil no new occurence of a segfault.
Regards,
Eric
