2017-06-12 16:35:19 |
Eric Desrochers |
bug |
|
|
added bug |
2017-06-12 16:35:46 |
Eric Desrochers |
ksh (Ubuntu): importance |
Undecided |
Low |
|
2017-06-12 16:36:26 |
Eric Desrochers |
description |
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
--
# gdb
[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
--
I have looked the "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained anymore. |
--
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained anymore. |
|
2017-06-13 15:41:35 |
Walter Richards |
bug |
|
|
added subscriber Walter Richards |
2017-06-13 16:05:05 |
Dominique Poulain |
bug |
|
|
added subscriber Dominique Poulain |
2017-06-23 20:52:15 |
Eric Desrochers |
tags |
|
sts-sru-needed |
|
2017-06-23 20:53:10 |
Eric Desrochers |
nominated for series |
|
Ubuntu Yakkety |
|
2017-06-23 20:53:10 |
Eric Desrochers |
bug task added |
|
ksh (Ubuntu Yakkety) |
|
2017-06-23 20:53:10 |
Eric Desrochers |
nominated for series |
|
Ubuntu Artful |
|
2017-06-23 20:53:10 |
Eric Desrochers |
bug task added |
|
ksh (Ubuntu Artful) |
|
2017-06-23 20:53:10 |
Eric Desrochers |
nominated for series |
|
Ubuntu Trusty |
|
2017-06-23 20:53:10 |
Eric Desrochers |
bug task added |
|
ksh (Ubuntu Trusty) |
|
2017-06-23 20:53:10 |
Eric Desrochers |
nominated for series |
|
Ubuntu Xenial |
|
2017-06-23 20:53:10 |
Eric Desrochers |
bug task added |
|
ksh (Ubuntu Xenial) |
|
2017-06-23 20:53:10 |
Eric Desrochers |
nominated for series |
|
Ubuntu Zesty |
|
2017-06-23 20:53:10 |
Eric Desrochers |
bug task added |
|
ksh (Ubuntu Zesty) |
|
2017-06-23 20:53:27 |
Eric Desrochers |
ksh (Ubuntu Artful): importance |
Low |
Medium |
|
2017-06-23 20:53:30 |
Eric Desrochers |
ksh (Ubuntu Zesty): importance |
Undecided |
Medium |
|
2017-06-23 20:53:32 |
Eric Desrochers |
ksh (Ubuntu Yakkety): importance |
Undecided |
Medium |
|
2017-06-23 20:53:34 |
Eric Desrochers |
ksh (Ubuntu Xenial): importance |
Undecided |
Medium |
|
2017-06-23 20:53:37 |
Eric Desrochers |
ksh (Ubuntu Trusty): importance |
Undecided |
Medium |
|
2017-06-23 21:11:20 |
Eric Desrochers |
summary |
ksh segfault on job_chksave () |
ksh segfault on job_chksave () after it receive a SIGCHLD (Signal 17) |
|
2017-06-27 12:54:08 |
Eric Desrochers |
description |
--
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained anymore. |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained anymore. |
|
2017-06-29 14:21:20 |
Eric Desrochers |
description |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained anymore. |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
|
2017-07-04 14:28:49 |
Eric Desrochers |
ksh (Ubuntu Artful): assignee |
|
Eric Desrochers (slashd) |
|
2017-07-04 14:28:51 |
Eric Desrochers |
ksh (Ubuntu Zesty): assignee |
|
Eric Desrochers (slashd) |
|
2017-07-04 14:28:53 |
Eric Desrochers |
ksh (Ubuntu Yakkety): assignee |
|
Eric Desrochers (slashd) |
|
2017-07-04 14:28:55 |
Eric Desrochers |
ksh (Ubuntu Xenial): assignee |
|
Eric Desrochers (slashd) |
|
2017-07-04 14:28:57 |
Eric Desrochers |
ksh (Ubuntu Trusty): assignee |
|
Eric Desrochers (slashd) |
|
2017-07-04 14:29:02 |
Eric Desrochers |
ksh (Ubuntu Artful): status |
New |
In Progress |
|
2017-07-04 14:29:05 |
Eric Desrochers |
ksh (Ubuntu Zesty): status |
New |
In Progress |
|
2017-07-04 14:29:07 |
Eric Desrochers |
ksh (Ubuntu Yakkety): status |
New |
In Progress |
|
2017-07-04 14:29:09 |
Eric Desrochers |
ksh (Ubuntu Xenial): status |
New |
In Progress |
|
2017-07-04 14:29:11 |
Eric Desrochers |
ksh (Ubuntu Trusty): status |
New |
In Progress |
|
2017-07-04 14:47:40 |
Eric Desrochers |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867181 |
|
2017-07-04 14:49:30 |
Eric Desrochers |
bug task added |
|
ksh (Debian) |
|
2017-07-04 14:55:20 |
Eric Desrochers |
description |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
* A test package including the RH fix has been tested and verified (pre-SRU) by an affected user with positive feedbacks using his reproducer.
* Feedbacks :
"I've confirmed that our users have not had a single occurrence of core dump on ksh with the patched package. They have run the script sequence over 3000 times since we updated with no issues."
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
|
2017-07-04 16:18:43 |
Bug Watch Updater |
ksh (Debian): status |
Unknown |
New |
|
2017-07-04 16:22:40 |
Eric Desrochers |
description |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
* A test package including the RH fix has been tested and verified (pre-SRU) by an affected user with positive feedbacks using his reproducer.
* Feedbacks :
"I've confirmed that our users have not had a single occurrence of core dump on ksh with the patched package. They have run the script sequence over 3000 times since we updated with no issues."
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
* A test package including the RH fix has been tested and verified (pre-SRU) by an affected user with positive feedbacks using his reproducer.
* Feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
|
2017-07-04 16:23:20 |
Eric Desrochers |
description |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
* A test package including the RH fix has been tested and verified (pre-SRU) by an affected user with positive feedbacks using his reproducer.
* Feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
* A test package including the RH fix has been tested and verified (pre-SRU) by an affected user with positive feedbacks using his reproducer.
* Test package (pre-SRU) feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
|
2017-07-04 17:09:01 |
Eric Desrochers |
attachment added |
|
artful-ksh_93u+20120801-3.2.debdiff https://bugs.launchpad.net/ubuntu/yakkety/+source/ksh/+bug/1697501/+attachment/4909315/+files/artful-ksh_93u+20120801-3.2.debdiff |
|
2017-07-04 17:10:58 |
Eric Desrochers |
tags |
sts-sru-needed |
patch sts-sru-needed |
|
2017-07-04 17:11:10 |
Eric Desrochers |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
2017-07-04 17:12:17 |
Eric Desrochers |
tags |
patch sts-sru-needed |
patch sts sts-sru-needed |
|
2017-07-04 17:13:42 |
Eric Desrochers |
description |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
* A test package including the RH fix has been tested and verified (pre-SRU) by an affected user with positive feedbacks using his reproducer.
* Test package (pre-SRU) feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
* A test package including the RH fix has been tested and verified (pre-SRU) by an affected user with positive feedbacks using his reproducer.
* Test package (pre-SRU) feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
* Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867181
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
|
2017-07-04 17:18:18 |
Eric Desrochers |
description |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
* A test package including the RH fix has been tested and verified (pre-SRU) by an affected user with positive feedbacks using his reproducer.
* Test package (pre-SRU) feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
* Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867181
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* Regression risk : none expected, but even if one found, I'm sure it will be less critical than the current state of the package which unexpectedly segfault. Additionally, I doubt ksh has much users traction nowadays.
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
* A test package including the RH fix has been intensively tested and verified (pre-SRU) by an affected user with positive feedbacks using his reproducer.
* Test package (pre-SRU) feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
* Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867181
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
|
2017-07-04 18:40:26 |
Eric Desrochers |
description |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* Regression risk : none expected, but even if one found, I'm sure it will be less critical than the current state of the package which unexpectedly segfault. Additionally, I doubt ksh has much users traction nowadays.
* This update implements a fix to ensure the compiler does not drop parts of the ksh mechanism for the crash to no longer occurs.
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
* A test package including the RH fix has been intensively tested and verified (pre-SRU) by an affected user with positive feedbacks using his reproducer.
* Test package (pre-SRU) feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
* Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867181
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* Regression risk : none expected, the package has been highly/intensively tested by a user who run over 18M ksh scripts a day on each of their clusters.
+
* Secondly, I doubt ksh has much traction nowadays, so if a regression occurs... It will most likely be limited to a small amount of users IMHO.
For instance, the bug has been reported 3 years ago for Red Hat, and we, Ubuntu, only heard about this same situation for the first time a few weeks ago.
+
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
+
* A test package including the RH fix has been intensively tested and verified (pre-SRU) by an affected user with positive feedbacks using a
reproducer that segfault without the RH patch.
+
* Test package (pre-SRU) feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
* Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867181
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
|
2017-07-04 18:40:39 |
Eric Desrochers |
description |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* Regression risk : none expected, the package has been highly/intensively tested by a user who run over 18M ksh scripts a day on each of their clusters.
+
* Secondly, I doubt ksh has much traction nowadays, so if a regression occurs... It will most likely be limited to a small amount of users IMHO.
For instance, the bug has been reported 3 years ago for Red Hat, and we, Ubuntu, only heard about this same situation for the first time a few weeks ago.
+
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
+
* A test package including the RH fix has been intensively tested and verified (pre-SRU) by an affected user with positive feedbacks using a
reproducer that segfault without the RH patch.
+
* Test package (pre-SRU) feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
* Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867181
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
[Impact]
* 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.
[Test Case]
Unfortunately, there is no clear and easy way to reproduce the segfault.
* But the original reporter of this bug can randomly reproduce the problem using an in-house ksh script that only works inside his infrastructure as follow : "ksh <in-house-script.ksh>" and then once in a while ksh will segfault as follow :
(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>
...
[Regression Potential]
* Regression risk : low/none expected, the package has been highly/intensively tested by a user who run over 18M ksh scripts a day on each of their clusters.
+
* Secondly, I doubt ksh has much traction nowadays, so if a regression occurs... It will most likely be limited to a small amount of users IMHO.
For instance, the bug has been reported 3 years ago for Red Hat, and we, Ubuntu, only heard about this same situation for the first time a few weeks ago.
+
* The fix has been written by RH and has been proven to work for them for the last 3 years.
Note that the RH fix has never been merged upstream (ksh is a unmaintained project) and/or possibly never been proposed to upstream (to be verified).
+
* A test package including the RH fix has been intensively tested and verified (pre-SRU) by an affected user with positive feedbacks using a
reproducer that segfault without the RH patch.
+
* Test package (pre-SRU) feedbacks :
https://bugs.launchpad.net/ubuntu/xenial/+source/ksh/+bug/1697501/comments/7
[Other Info]
* ksh project is unmaintained nowadays [https://github.com/att/ast], thus no new development is made upstream nor in debian upstream.
* 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 <mhlavink@redhat.com> - 20120801-10.8
- job locking mechanism did not survive compiler optimization (#1123467)
# patch
- ksh-20120801-locking.patch
--
* Debian bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867181
[Original Description]
# gdb
[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
--
ksh is segfaulting because it can't access struct "jp" ($rdx) thus cannot de-reference the struct member "jp>pid" ($rdx + 8) at line : src/cmd/ksh93/sh/jobs.c:1948 when looking if jp->pid is equal to pid ($edi) variable.
I have looked at the github project "att/ast" upstream repo and some patches here and there, and nothing seems to apply.
Note that the project seems unmaintained nowadays. |
|
2017-07-04 19:57:02 |
Eric Desrochers |
attachment added |
|
zesty-ksh_93u+20120801-2ubuntu1.debdiff https://bugs.launchpad.net/ubuntu/trusty/+source/ksh/+bug/1697501/+attachment/4909355/+files/zesty-ksh_93u+20120801-2ubuntu1.debdiff |
|
2017-07-04 19:57:28 |
Eric Desrochers |
attachment added |
|
yakkety-ksh_93u+20120801-2ubuntu0.16.10.1.debdiff https://bugs.launchpad.net/ubuntu/trusty/+source/ksh/+bug/1697501/+attachment/4909356/+files/yakkety-ksh_93u+20120801-2ubuntu0.16.10.1.debdiff |
|
2017-07-04 19:57:50 |
Eric Desrochers |
attachment added |
|
xenial-ksh_93u+20120801-2ubuntu0.16.04.1.debdiff https://bugs.launchpad.net/ubuntu/trusty/+source/ksh/+bug/1697501/+attachment/4909357/+files/xenial-ksh_93u+20120801-2ubuntu0.16.04.1.debdiff |
|
2017-07-04 19:58:12 |
Eric Desrochers |
attachment added |
|
trusty-ksh_93u+20120801-1ubuntu0.14.04.1.debdiff https://bugs.launchpad.net/ubuntu/trusty/+source/ksh/+bug/1697501/+attachment/4909358/+files/trusty-ksh_93u+20120801-1ubuntu0.14.04.1.debdiff |
|
2017-07-04 19:59:14 |
Launchpad Janitor |
ksh (Ubuntu Artful): status |
In Progress |
Fix Released |
|
2017-07-05 12:41:39 |
Eric Desrochers |
bug |
|
|
added subscriber SRU Verification |
2017-07-05 12:41:41 |
Eric Desrochers |
removed subscriber Ubuntu Sponsors Team |
|
|
|
2017-07-05 12:41:50 |
Eric Desrochers |
tags |
patch sts sts-sru-needed |
sts sts-sru-needed |
|
2017-07-06 14:57:36 |
Łukasz Zemczak |
ksh (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
2017-07-06 14:57:38 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
2017-07-06 14:57:43 |
Łukasz Zemczak |
tags |
sts sts-sru-needed |
sts sts-sru-needed verification-needed verification-needed-trusty |
|
2017-07-06 15:05:42 |
Łukasz Zemczak |
ksh (Ubuntu Yakkety): status |
In Progress |
Fix Committed |
|
2017-07-06 15:05:47 |
Łukasz Zemczak |
tags |
sts sts-sru-needed verification-needed verification-needed-trusty |
sts sts-sru-needed verification-needed verification-needed-trusty verification-needed-yakkety |
|
2017-07-06 15:09:53 |
Łukasz Zemczak |
ksh (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
2017-07-06 15:09:59 |
Łukasz Zemczak |
tags |
sts sts-sru-needed verification-needed verification-needed-trusty verification-needed-yakkety |
sts sts-sru-needed verification-needed verification-needed-trusty verification-needed-xenial verification-needed-yakkety |
|
2017-07-06 15:27:54 |
Łukasz Zemczak |
ksh (Ubuntu Zesty): status |
In Progress |
Fix Committed |
|
2017-07-06 15:27:59 |
Łukasz Zemczak |
tags |
sts sts-sru-needed verification-needed verification-needed-trusty verification-needed-xenial verification-needed-yakkety |
sts sts-sru-needed verification-needed verification-needed-trusty verification-needed-xenial verification-needed-yakkety verification-needed-zesty |
|
2017-07-14 13:55:05 |
Eric Desrochers |
tags |
sts sts-sru-needed verification-needed verification-needed-trusty verification-needed-xenial verification-needed-yakkety verification-needed-zesty |
sts sts-sru-needed verification-done-trusty verification-needed verification-needed-xenial verification-needed-yakkety verification-needed-zesty |
|
2017-07-14 19:38:21 |
Eric Desrochers |
tags |
sts sts-sru-needed verification-done-trusty verification-needed verification-needed-xenial verification-needed-yakkety verification-needed-zesty |
sts sts-sru-needed verification-done-trusty verification-done-xenial verification-done-yakkety verification-done-zesty |
|
2017-07-17 14:39:46 |
Launchpad Janitor |
ksh (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
2017-07-17 14:39:48 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
2017-07-20 13:46:01 |
Launchpad Janitor |
ksh (Ubuntu Zesty): status |
Fix Committed |
Fix Released |
|
2017-07-20 13:46:15 |
Launchpad Janitor |
ksh (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
2017-07-20 13:46:27 |
Launchpad Janitor |
ksh (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
2018-08-20 13:13:53 |
Edward Hope-Morley |
tags |
sts sts-sru-needed verification-done-trusty verification-done-xenial verification-done-yakkety verification-done-zesty |
sts sts-sru-done verification-done-trusty verification-done-xenial verification-done-yakkety verification-done-zesty |
|
2020-04-15 16:50:01 |
Bug Watch Updater |
ksh (Debian): status |
New |
Fix Released |
|