Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 109918 - executable code in .data in ld.so renders system unusable for PaX users
executable code in .data in ld.so renders system unusable for PaX users
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i686 Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-11-12 18:05 EST by PaX Team
Modified: 2016-11-24 10:02 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.3.2-27.9.7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-11-13 16:51:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2003:325 normal SHIPPED_LIVE : Updated glibc packages provide security and bug fixes 2003-11-12 00:00:00 EST

  None (edit)
Description PaX Team 2003-11-12 18:05:17 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
Due to an error somewhere in the toolchain or glibc itself, the 
dl_sysinfo_int80() function ends up in the .data section of ld-
linux.so instead of its usual place .text. On systems that use a PaX 
kernel this will make all dynamically linked applications die and 
render the system unusable.

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

How reproducible:

Steps to Reproduce:
1. install a PaX kernel (http://pageexec.virtualave.net)
2. enable the SEGMEXEC and MPROTECT options, recompile/reboot
3. watch syslog/console as dynamically linked applications run and 
get killed

Actual Results:  PaX will kill dynamically linked applications and 
report messages like:

Nov 12 21:45:50 goliath kernel: PAX: terminating task: /bin/ls
(ls):2323, uid/euid: 0/0, PC: 268a8440, SP: 5f908958
Nov 12 21:45:50 goliath kernel: PAX: bytes at PC: cd 80 c3 00 0e 00 
00 00 b0 02 00 00 04 00 00 00 94 30 89 26

Note that addresses are randomized but based on the reported byte 
sequence you can quickly find and identify dl_sysinfo_int80 as the 

Expected Results:  No errors, apps should have worked as before.

Additional info:

After having looked in the corresponding .src.rpm it's not clear 
where the error was introduced, the source code properly puts the 
code in question into .text, so it might be a problem with 
binutils/ld instead.
Comment 1 Jakub Jelinek 2003-11-12 20:09:32 EST
Please try ftp://people.redhat.com/jakub/glibc/errata/2.3.2-27.9.7/
Comment 2 Roy W. Reter 2003-11-12 20:13:13 EST
Work around that I found if you have a custom kernel.  Boot into a Red
Hat standard kernel and force install glibc-2.3.2-27.9.6.i386.rpm and
then reboot into your custom kernel.
Comment 3 PAX USER 2003-11-13 02:42:21 EST
The version 2.3.2-27.9.7 is working except for /usr/sbin/iconvconfig

Nov 13 08:29:24 goliath kernel: PAX: terminating task:
/usr/sbin/iconvconfig(iconvconfig):3078, uid/euid: 0/0, PC: 5eed1030,
SP: 5eed0f3c
Nov 13 08:29:24 goliath kernel: PAX: bytes at PC: b9 90 10 ed 5e e9 36
8a 17 a9 ed 5e 7f 98 04 08 f8 d8 07 08

look like it break the install of the rpm in the %post section
error: %post(glibc-2.3.2-27.9.7) scriptlet failed, exit status 115
Comment 4 Jakub Jelinek 2003-11-13 03:41:06 EST
If PaX doesn't handle programs using nested functions whose address
is taken, then it is broken IMHO.
See Exec-Shield in Fedora Core 1 for a (better) alternative.
Comment 5 PaX Team 2003-11-13 06:47:57 EST
PaX handles nested function trampolines by emulating them however 
this requires that users explicitly enable this feature (both in the 
kernel .config and on affected binaries). Work is in progress to do 
this automatically based on the PT_GNU_STACK marking (note that this 
particular series of glibc releases does not carry such markings so 
they would still require user intervention).

The suggested alternative is not acceptable to PaX users because of 
its lesser security features, also it is an apples to oranges 
comparison as iconvconfig in Fedora has been explicitly modified to 
not use nested functions (see the move of 
iconv/iconvconfig.c:name_insert() in glibc-redhat.patch), obviously 
that will work with a non-executable stack, be that provided by Exec-
Shield or PaX.
Comment 6 Jakub Jelinek 2003-11-13 16:51:43 EST
iconvconfig in Fedora doesn't use trampolines simply because I needed
that patch when Exec-Shield did not honor PT_GNU_STACK yet.
But as iconvconfig is single threaded, it really doesn't have to use
the trampolines, so I kept the patch.  It would work just fine even
without it though in FC1.

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