Bug 588994 - [abrt] crash in coreutils-7.6-9.fc12: Process /bin/ls was killed by signal 11 (SIGSEGV)
[abrt] crash in coreutils-7.6-9.fc12: Process /bin/ls was killed by signal 11...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
12
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
abrt_hash:a49bbe83f659995944f3d5c9507...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-05 00:02 EDT by Dheeraj Kumar
Modified: 2010-05-05 08:11 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-05 08:11:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
File: backtrace (8.63 KB, text/plain)
2010-05-05 00:02 EDT, Dheeraj Kumar
no flags Details

  None (edit)
Description Dheeraj Kumar 2010-05-05 00:02:52 EDT
abrt 1.0.9 detected a crash.

architecture: i686
Attached file: backtrace
comment: try vfork program
component: coreutils
executable: /bin/ls
global_uuid: a49bbe83f659995944f3d5c9507c07855b510f1e
kernel: 2.6.32.11-99.fc12.i686.PAE
package: coreutils-7.6-9.fc12
rating: 4
reason: Process /bin/ls was killed by signal 11 (SIGSEGV)
release: Fedora release 12 (Constantine)

How to reproduce
-----
1. i have done program using Vfork system call.
2.
3.
Comment 1 Dheeraj Kumar 2010-05-05 00:02:54 EDT
Created attachment 411466 [details]
File: backtrace
Comment 2 Ondrej Vasik 2010-05-05 04:49:00 EDT
Thanks for report, the same could be done for every single coreutils utility ... except true and false - where it was fixed because of https://bugzilla.redhat.com/show_bug.cgi?id=537684 ;) .

"set_program_name (argv[0] ? argv[0] : PROGRAM_NAME);" instead of "set_program_name (argv[0]);" in every single coreutils source file could solve the problem...

Upstream maintainer stated in http://marc.info/?l=coreutils-bug&m=125832075427611&w=2 that he still haven't decided how to accomodate this. Therefore adding him to CC to check if the comment is still valid.
Comment 3 Jim Meyering 2010-05-05 05:41:43 EDT
Thanks for the report.

Actually, this *was* resolved.
We addressed that problem via a change to gnulib's progname module.
In newer versions of coreutils, when a program is abused in this way, it prints a diagnostic telling what you've done wrong:

  $ printf '%s\n' '#include <unistd.h>' 'int main(int c, char**v)' \
    '{ execve (v[1], 0, 0); }' > k.c && gcc k.c && ./a.out $PWD/ls  
  A NULL argv[0] was passed through an exec system call.
  zsh: abort (core dumped)  ./a.out $PWD/ls
  [Exit 134 (ABRT)]

The solution is not to pass a NULL argv to any exec-style system call.
Comment 4 Ondrej Vasik 2010-05-05 08:11:59 EDT
Ah, ok, sorry for confusion, Jim ... confirmed - diagnostic is present in coreutils-8.5 (now in Rawhide) and in coreutils-8.4 (to be in F-13) ... I do not plan to backport diagnostics into F-12 at the moment - as this is misuse of execve. Closing NEXTRELEASE.

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