Bug 514760

Summary: cleanup script segfaults during yum upgrade
Product: [Fedora] Fedora Reporter: darrell pfeifer <darrellpf>
Component: redhat-lsbAssignee: Lawrence Lim <llim>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: awilliam, hliu, holms050, jakub, llim, nicolas.mailhot, schwab, selinux, tcallawa, thomas.moschny, tools-bugs, valdis.kletnieks
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-28 14:01:58 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 473303    
Attachments:
Description Flags
redhat-lsb-trigger.patch none

Description darrell pfeifer 2009-07-30 12:37:04 EDT
Description of problem:

  Cleanup        : glibc-2.10.90-10                                                                     13/18 
/var/tmp/rpm-tmp.znJgz6: line 3:  4339 Segmentation fault      /usr/sbin/redhat_lsb_trigger.x86_64



Version-Release number of selected component (if applicable):


How reproducible:

yum updated from glibc-2.10.90-10 to 2.10.90-11


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Tom London 2009-08-02 12:48:43 EDT
See this:

Aug  2 09:31:36 tlondon kernel: redhat_lsb_trig[6612]: segfault at 7ffff1c76ed8 ip 000000000040e971 sp 00007ffff1c76ee0 error 6 in redhat_lsb_trigger.x86_64[400000+9f000]

Generates an enormous (1010G!!!!!) core file:

[root@tlondon ~]# ls -lh core.*
-rw-------. 1 root root 1010G 2009-08-02 09:34 core.6612
[root@tlondon ~]# 

[Almost certainly mostly zeros....]

Running gdb:

warning: core file may not match specified executable file.
Core was generated by `/usr/sbin/redhat_lsb_trigger.x86_64 --help'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000000040e971 in _dl_discover_osversion ()
(gdb) where
#0  0x000000000040e971 in _dl_discover_osversion ()
#1  0x0000000000400528 in __libc_start_main ()
#2  0x00000000004002a9 in _start ()
(gdb) 


_dl_discover_osversion() ??????
Comment 2 Tom London 2009-08-02 12:57:16 EDT
Running "gdb /usr/sbin/redhat_lsb_trigger.x86_64" interactively:

(gdb) run
Starting program: /usr/sbin/redhat_lsb_trigger.x86_64 

Program received signal SIGSEGV, Segmentation fault.
0x000000000040e971 in _dl_discover_osversion ()
(gdb) where
#0  0x000000000040e971 in _dl_discover_osversion ()
#1  0x0000000000400528 in __libc_start_main ()
#2  0x00000000004002a9 in _start ()
(gdb) list
434	    {
435	      char buf[sizeof LSBLDSO + 1 + strlen (LSBVER)];
436	      p = buf;
437	      p = mempcpy (p, LSBLDSO, sizeof LSBLDSO - 1);
438	      *p++ = '.';
439	      strcpy (p, LSBVER);
440	      if (is_ia64 ())
441		INTERNAL_SYSCALL (symlink, err, 2, "/emul/ia32-linux/lib/" LDSO, buf);
442	      else
443		INTERNAL_SYSCALL (symlink, err, 2, LDSO, buf);
(gdb)
Comment 3 Tom London 2009-08-02 12:59:57 EDT
Downgrading to redhat-lsb-3.2-4.fc12.x86_64.rpm seems to make it "work for me".
Comment 4 Andreas Schwab 2009-08-05 03:12:52 EDT
*** Bug 515537 has been marked as a duplicate of this bug. ***
Comment 5 Tom London 2009-08-10 09:31:38 EDT
After removing redhat-lsb (not sure what pulled it in, but I had no problems removing it and the few dependencies), I have no problem updating to glibc.x86_64 0:2.10.90-13.

Is redhat-lsb "vestigial"?
Comment 6 Tom "spot" Callaway 2009-10-21 12:56:12 EDT
*** Bug 523270 has been marked as a duplicate of this bug. ***
Comment 7 Nicolas Mailhot 2009-10-21 13:13:37 EDT
When you dupe blocker bugs please move the blocker tag the the report remaining open
Comment 8 Adam Williamson 2009-10-23 12:36:28 EDT
tom: redhat-lsb basically exists to make the distro LSB-compliant when installed. it's not a vestigial package.

Bug was discussed at blocker bug review meeting today. jlaska will ping llim to see what's going on here.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 9 Jakub Jelinek 2009-10-26 15:11:26 EDT
Created attachment 366147 [details]
redhat-lsb-trigger.patch

The reason redhat_lsb_trigger.c is written in the weird way it is is to keep the stripped statically linked binary small.
Normally statically linked binaries are in the .5MB-2MB range because all kinds of stuff gets linked in, the intent was that only very few object files if anything from libc.a gets linked into the binary.  You can add -Wl,-M to see
what is being linked in.
One needs to choose either to keep redhat_lsb_trigger.c correct and uptodate with glibc changes, or just give up on the size.  In that case most of the file can be dropped, you'd use normal symlink, exit, etc. calls instead of *_SYSCALL macros, just have everything in main, etc.
One of the changes since I had anything to do with that file was added underscore to __libc_start_main, that makes absolutely no sense.  The reason for the routine to be defined there is to avoid linking in __libc_start_main from libc.a and all of its numerous dependencies.
Unfortunately due to the ia64 emulation braindamage the trigger can't be written in LUA, at least not solely in LUA :(.

With the attached patch redhat_lsb_trigger.x86_64 is again very small (3KB), haven't tried other arches, if you compile it with additional -fno-stack-protector (although __stack_chk_fail could be stubbed, the provided __libc_start_main doesn't setup %gs/%fs on x86_64/i?86 and doesn't initialize the stack canary).  The reason for the segfaults was IFUNC, the relocations to call strcpy weren't initialized because __libc_csu_start was stubbed.
Comment 10 Tom "spot" Callaway 2009-10-27 19:59:29 EDT
Jakub, even with that patch applied, the trigger binary still segfaults:

[spot@pterodactyl devel]$ sudo /usr/sbin/redhat_lsb_trigger.x86_64
Segmentation fault

Gdb isn't much help either:

[root@pterodactyl ~]# gdb /usr/sbin/redhat_lsb_trigger.x86_64
GNU gdb (GDB) Fedora (7.0-3.fc12)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/redhat_lsb_trigger.x86_64...Reading symbols from /usr/lib/debug/usr/sbin/redhat_lsb_trigger.x86_64.debug...done.
done.
(gdb) run
Starting program: /usr/sbin/redhat_lsb_trigger.x86_64 

Program received signal SIGSEGV, Segmentation fault.
main (argc=<value optimized out>, argv=0x7fffffffe518) at redhat_lsb_trigger.c:495
495	{
(gdb) bt
#0  main (argc=<value optimized out>, argv=0x7fffffffe518) at redhat_lsb_trigger.c:495
(gdb) list
490	  while ((*dst++ = *src++) != '\0');
491	  return ret;
492	}
493	
494	int main (int argc, char **argv)
495	{
496	  INTERNAL_SYSCALL_DECL (err);
497	  char lsbsover[] = LSBSOVER;
498	  char *LSBVER, *p = lsbsover;
499	  while ((LSBVER = strtok (p, " \t")) != NULL)
(gdb)
Comment 11 Jakub Jelinek 2009-10-28 08:05:27 EDT
Was that really compiled with -fno-stack-protector?  It worked for me well when compiled that way (and with the patch applied).
Comment 12 Tom "spot" Callaway 2009-10-28 09:41:18 EDT
Aha, sorry, that wasn't clear to me at first that it was necessary. It works when compiled that way. I'll get this fix pushed out.
Comment 13 Tom "spot" Callaway 2009-10-28 14:01:58 EDT
Fixed in F-12 (redhat-lsb-3.2-7.fc12) and rawhide.
Comment 14 Adam Williamson 2009-10-28 15:54:17 EDT
i'm no expert so prepared for you to laugh at me, but it was my understanding that disabling compiler security features is not the right way to 'fix' problems? the correct approach would be to make the code with with stack protection enabled?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 15 Jakub Jelinek 2009-10-28 16:16:19 EDT
This whole proglet is just 2 syscalls, it is easily provable there is no stack overflow.  -fstack-protect only triggers in main, no other function has any arrays on the stack, and main never returns in this proglet, because it invokes the exit syscall instead.  As -fstack-protector only checks the canary when returning from a function, it would never trigger here.  And the initialization of the thread mmapping etc. would need to be arch specific and would probably double the size of the proglet, for no security improvement at all.
Comment 16 Adam Williamson 2009-10-28 17:29:23 EDT
Thank you for laughing at me in such a kind and informative way :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers