pstree seg fault
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
psmisc (Debian) |
Fix Released
|
Unknown
|
|||
psmisc (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Xenial |
Fix Released
|
Low
|
Lucas Kanashiro |
Bug Description
[Impact]
Users might face a segmentation fault crash while executing 'pstree'. Backporting this fix will avoid 'pstree' breakage in our users' systems under
certain circumstances.
This is a timing issue where if the 'get_threadname' function is called and
during its execution the target thread is deleted, it tries to close a file
that does not exist anymore. This happens because of a coding issue, 'pstree'
invokes fclose function even if the fopen function call returns NULL. The
proposed patch fixes this issue simply moving the fclose function call three
lines up, inside of a conditional block which guarantees that the file was
properly open (the pointer to the file is not NULL).
This bug was introduced in upstream version 22.21 and fixed in version 23.0,
which means that Xenial is the only affected Ubuntu release:
$ rmadison psmisc
psmisc | 22.15-2ubuntu1 | precise | source, amd64, armel, armhf, i386, powerpc
psmisc | 22.15-2ubuntu1.2 | precise-updates | source, amd64, armel, armhf, i386, powerpc
psmisc | 22.20-1ubuntu2 | trusty | source, amd64, arm64, armhf, i386, powerpc, ppc64el
psmisc | 22.21-2.1build1 | xenial | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
psmisc | 23.1-1 | bionic | source, amd64, arm64, armhf, i386, ppc64el, s390x
psmisc | 23.1-1ubuntu0.1 | bionic-updates | source, amd64, arm64, armhf, i386, ppc64el, s390x
psmisc | 23.2-1 | disco | source, amd64, arm64, armhf, i386, ppc64el, s390x
psmisc | 23.2-1 | eoan | source, amd64, arm64, armhf, i386, ppc64el, s390x
[Test Case]
Since timing is an important factor for this issue, it is not easy to reproduce via a test case. This bug might pop up in any 'pstree' call regardless of the parameters passed to it. When it happens the user will be able to notice the segmentation fault immediately in the standard output. Below is the stack trace generated by the user who reported this bug on Debian [1]:
Core was generated by `pstree'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 _IO_new_fclose (fp=0x0) at iofclose.c:54
54 iofclose.c: No such file or directory.
(gdb) bt
#0 _IO_new_fclose (fp=0x0) at iofclose.c:54
#1 0x00000000004037be in ?? ()
#2 0x0000000000401a43 in ?? ()
#3 0x00007f577c553b45 in __libc_start_main (main=0x401670, argc=1,
argv=0x7ffeb613
rtld_fini=
#4 0x0000000000401e8d in ?? ()
However, as presented in the last section it is an easily identifiable error
in the code, and the fix is quite straightforward.
[1] https:/
[Regression Potential]
There is a potential problem since the bug was not reproducible in our side. Timing issues are hard to reproduce in general, so there might be another case(s) where this kind of situation can happen. The fix impacts only the 'pstree' utility, so any problem with other binaries provided by psmisc is not related to this update.
[Original message]
As per https:/
Perhaps Xenial needs to be upgraded to use 22.22??
Related branches
- Andreas Hasenack: Approve
- Canonical Server: Pending requested
-
Diff: 57 lines (+36/-0)3 files modifieddebian/changelog (+6/-0)
debian/patches/fix-pstree-seg-fault.patch (+29/-0)
debian/patches/series (+1/-0)
description: | updated |
Changed in psmisc (Ubuntu): | |
status: | Triaged → Fix Released |
Changed in psmisc (Ubuntu Xenial): | |
status: | New → Triaged |
importance: | Undecided → Low |
description: | updated |
Changed in psmisc (Ubuntu Xenial): | |
assignee: | nobody → Lucas Kanashiro (lucaskanashiro) |
tags: | removed: verification-needed verification-needed-xenial |
tags: | added: verification-done-xenial |
Changed in psmisc (Debian): | |
status: | Unknown → Fix Released |
Thanks for filing this bug in Ubuntu.
This looks like a straight forward patch, already applied upstream. If I understand it correctly, it might be hard to reproduce, because the thread deletion has to happen at the right time. Do you encounter this frequently, or have a way to reproduce that doesn't take too long?