[Bug 932621] [NEW] String corruption

[Sebastian Unger]

Public bug reported:

Hi there,

I'm installing a 64 bit ubuntu server system with oneiric. However, due
to https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/905660 I am
trying to pull in ifupdown from precise. This pulls in the following
additional packages from precise due to dependencies:

libc-bin
libc-dev-bin
libc6
libc6-dev
libc6-dev-i386
libc6-i386
libnih-dbus1
libnih1

The oneiric version of the libc packages is 2.13-20ubuntu5.
The precise version of the libc packages is 2.15-0ubuntu2.

After this, a i386 application that I have installed on the machine
breaks. The application is multi V4.2.4 from Green Hills. It is their
proprietary compiler suite and IDE. When I use this compiler suite to
compiler our embedded application, it fails to find a particular
library. Upon further investigation I found that the front-end compiler
driver (gbuild) passed the wrong library search path down to the
compiler. The output of ldd gbuild is:

la:~/trunk $ ldd /usr/ghs/multi424/gbuild 
        linux-gate.so.1 =>  (0xf774d000)
        libm.so.6 => /lib32/libm.so.6 (0xf7710000)
        libnsl.so.1 => /lib32/libnsl.so.1 (0xf76f7000)
        libdl.so.2 => /lib32/libdl.so.2 (0xf76f2000)
        libc.so.6 => /lib32/libc.so.6 (0xf7578000)
        /lib/ld-linux.so.2 (0xf774e000)

With the oneiric version of the above packages, gbuild passing the
(correct) option -L../output/ppc to the compiler. With the precise
version of these libraries gbuild passes -L../outuut/ppc to the
compiler. gbuild gets the path from a config file, which actually
contains the option -L../../output/ppc, but is located one directory
below the current working directory of the compiler invocation and is
defined to be local to that file.

So I suspect that gbuild recognizes the -L option and the fact that it's
argument is a relative path (another -L in the same file with an
absolute path is passed through correctly) and tries to strip off the
initial ../ but something goes wrong. I also suspect that the bug only
shows up in the 32bit version of libc on 64 bit systems, since all my 64
bit apps seem to behave normally.

I can modify the option in the config file to check what, if any,
corruption occurs to different strings. Here are some results:

-L../../output/ppc   =>  -L../outuut/ppc  (corrupted, that's the one that I found this with)
-L../../../output/ppc   =>  -L../../output/ppc   (correct, no corruption)
-L./../../output/ppc   =>  -Lshared-libs/.../output/ppppc  (corrupted, shared-libs is the directory that the config file resides in)
-L./../output/ppc   => -Loutput/ppc    (correct, no corruption)
-L.././../output/ppc  =>  -L../output/ppc    (correct, no corruption)
-L../.././output/ppc  =>  -L../output/ppc  (correct, no corruption)

** Affects: eglibc (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/932621

Title:
  String corruption

Status in “eglibc” package in Ubuntu:
  New

Bug description:
  Hi there,

  I'm installing a 64 bit ubuntu server system with oneiric. However,
  due to https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/905660
  I am trying to pull in ifupdown from precise. This pulls in the
  following additional packages from precise due to dependencies:

  libc-bin
  libc-dev-bin
  libc6
  libc6-dev
  libc6-dev-i386
  libc6-i386
  libnih-dbus1
  libnih1

  The oneiric version of the libc packages is 2.13-20ubuntu5.
  The precise version of the libc packages is 2.15-0ubuntu2.

  After this, a i386 application that I have installed on the machine
  breaks. The application is multi V4.2.4 from Green Hills. It is their
  proprietary compiler suite and IDE. When I use this compiler suite to
  compiler our embedded application, it fails to find a particular
  library. Upon further investigation I found that the front-end
  compiler driver (gbuild) passed the wrong library search path down to
  the compiler. The output of ldd gbuild is:

  la:~/trunk $ ldd /usr/ghs/multi424/gbuild 
          linux-gate.so.1 =>  (0xf774d000)
          libm.so.6 => /lib32/libm.so.6 (0xf7710000)
          libnsl.so.1 => /lib32/libnsl.so.1 (0xf76f7000)
          libdl.so.2 => /lib32/libdl.so.2 (0xf76f2000)
          libc.so.6 => /lib32/libc.so.6 (0xf7578000)
          /lib/ld-linux.so.2 (0xf774e000)

  With the oneiric version of the above packages, gbuild passing the
  (correct) option -L../output/ppc to the compiler. With the precise
  version of these libraries gbuild passes -L../outuut/ppc to the
  compiler. gbuild gets the path from a config file, which actually
  contains the option -L../../output/ppc, but is located one directory
  below the current working directory of the compiler invocation and is
  defined to be local to that file.

  So I suspect that gbuild recognizes the -L option and the fact that
  it's argument is a relative path (another -L in the same file with an
  absolute path is passed through correctly) and tries to strip off the
  initial ../ but something goes wrong. I also suspect that the bug only
  shows up in the 32bit version of libc on 64 bit systems, since all my
  64 bit apps seem to behave normally.

  I can modify the option in the config file to check what, if any,
  corruption occurs to different strings. Here are some results:

  -L../../output/ppc   =>  -L../outuut/ppc  (corrupted, that's the one that I found this with)
  -L../../../output/ppc   =>  -L../../output/ppc   (correct, no corruption)
  -L./../../output/ppc   =>  -Lshared-libs/.../output/ppppc  (corrupted, shared-libs is the directory that the config file resides in)
  -L./../output/ppc   => -Loutput/ppc    (correct, no corruption)
  -L.././../output/ppc  =>  -L../output/ppc    (correct, no corruption)
  -L../.././output/ppc  =>  -L../output/ppc  (correct, no corruption)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/932621/+subscriptions