String corruption

[Sebastian Unger]

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)

[Sebastian Unger (sebunger44)]

-L../tt/../../output/ppc => -L../outuut/ppc (corrupt, tt does not exist).
-L../tt/.././output/ppc => -L./oututt/ppc (corrupt)

I think the algorithm that gbuild uses is something like this

Starting from ../tt/.././output/ppc:

- Prepend the path to the config file to the path given in the config file (shared-libs/../tt/.././output/ppc)
- Starting from the beginning each time, search for "/\./" or "/[^/]+/\.\./" and remove each occurrence with "/"

At least that's how I would implement it. It's unlikely that they are using regular expressions of course. It is likely that they simply scan through the string and then use memcpy, memmove or strcpy move the remainder of the string forward to effect the replacement. So I would suspect those kind of functions. Have there been any changes in this area between libc 2.13 and 2.15?

[Sebastian Unger (sebunger44)]

Actually, my algorithm isn't exactly right, as it wouldn't remove "shared-libs/../" at the beginning.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matthias Klose (doko)]

 - don't mix releases. rebuild ifupdown in oneiric, if needed.
 - please report the issue where you did download this software.

[Sebastian Unger (sebunger44)]

Hi Matthias,

1. I don't think that mixing releases is a reason to mark a bug as invalid. I have neither the means, time nor expertise to backport ifupdown to oneiric. Besides if there is potentially a bug hidden somewhere in libc6, I would have thought that's serious enough to warrant a bit more investigation. I have attempted to upgrade the entire installation to precise, but that failed because it could not resolve some pre-depends.
2. Said software has been working fine for the last 5 years including VERY similar installations of lucid, maverick, natty and oneiric. Only when I pulled libc from precise I have run into this issue. Therefor I don't really believe it to be a bug in that software.

I will attempt to do a clean reinstall of this machine with precise and see if the issue goes away, but I have my doubts as to whether this is going to be successful and even then, it's not really ready for production use, is it?

Seb

[Sebastian Unger (sebunger44)]

Setting status back to confirmed. I have reproduced the same problem with a clean install of precise.

[Matthias Klose (doko)]

do not confirm your issues yourself.

[Sebastian Unger (sebunger44)]

Matthias, I did not confirm this, the launchpad janitor did!

[Adam Conrad (adconrad)]

Is this issue still reproducible? Can I get a testcase for it, or some sort of hint as to how to reproduce it?

[Sebastian Unger (sebunger44)]

Hi Adam,

unfortunately I no longer work at that company and so can't retest
this issue. I have included Keith in the address list who is still
working there and may be able to retest this.

Cheers,
Seb

On Sun, Feb 10, 2013 at 12:43 PM, Adam Conrad <[e-mail]> wrote:
> Is this issue still reproducible? Can I get a testcase for it, or some
> sort of hint as to how to reproduce it?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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 ...

[Launchpad Janitor (janitor)]

[Expired for eglibc (Ubuntu) because there has been no activity for 60 days.]