Bug#389084: libc6: nasty bug in xdrmem_setpos(): signed comparison op is used for the pointers
Package: libc6
Version: 2.3.6.ds1-4
Severity: normal
Tags: patch
We've found a nasty bug in xdrmem_setpos() function.
Issue is caused by casts (char*) -> (long) and signed comparison
afterwards. Which causes xdrmem_setpos() to fail completely unexpectedly
if mem buffer starts little bit below 2Gb point and ends little bit above
(that's when the sign of 32bit int is flipping).
Proposed patch is somewhat trivial:
--- xdr_mem.c.orig 2002-12-16 05:25:27.0 -0500
+++ xdr_mem.c 2006-09-23 13:39:01.0 -0400
@@ -171,19 +171,21 @@
* xdrs modified
*/
static bool_t
-xdrmem_setpos (xdrs, pos)
- XDR *xdrs;
- u_int pos;
+xdrmem_setpos (XDR *xdrs, u_int pos)
{
caddr_t newaddr = xdrs->x_base + pos;
caddr_t lastaddr = xdrs->x_private + xdrs->x_handy;
+ size_t dist = 0;
- if ((long) newaddr > (long) lastaddr
- || (UINT_MAX < LONG_MAX
- && (long) UINT_MAX < (long) lastaddr - (long) newaddr))
+ if ( newaddr > lastaddr )
return FALSE;
+
+ dist = lastaddr - newaddr;
+ if ( (u_int)dist != dist )
+return FALSE;
+
xdrs->x_private = newaddr;
- xdrs->x_handy = (long) lastaddr - (long) newaddr;
+ xdrs->x_handy = (u_int)dist;
return TRUE;
}
___
I have not recompiled the whole libc locally, but just this file and
I've compared disasm dumps of original and patched version of the
function:
--- disass.orig 2006-09-23 13:54:10.0 -0400
+++ disass.patched 2006-09-23 13:53:20.0 -0400
@@ -12,7 +12,7 @@
0x0075 : add%esi,%eax
0x0077 : xor%esi,%esi
0x0079 : cmp%eax,%edx
-0x007b : jg 0x8a
+0x007b : ja 0x8a
0x007d : sub%edx,%eax
0x007f : mov$0x1,%esi
0x0084 : mov%edx,0xc(%ecx)
As you can see the only result of the changes is the type of cmp op:
signed (jg) -> unsigned (ja)
We believe that all the distros are affected by this (file has not been
touched for a three years or so), so probably patch have to be pushed
upstream asap. In particular this hurts our production (various versions
of RHEL) and hurts a lot...
100% of the credit for finding this goes to Konstantine Smaguine.
I've just prepared the patch and sent report to (hopefully) right people.
Thank you,
Nick Orlov.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-rc6-mm1-8.swp
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Versions of packages libc6 depends on:
ii tzdata2006l-1Time Zone and Daylight Saving Time
libc6 recommends no packages.
-- debconf-show failed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#388489: Processed: Cloning this bug
Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow a écrit :
> What do you mean by "smooth transition"? Could you explain to others
> what do you have in mind, it seems you have your own view on how to
> implement and how to do the transition to multiarch.
My plan is to provide an environment where packages can already switch
to multiarch and can be used as is (see fakeroot below) or with the
help of a simple apt/dpkg-deb wrapper even though some slow moving
packages like glibc neccessarily are behind on converting. Making
libc6-i386 behave just like libc6:i386 means that we don't have to
stop everything till glibc is converted.
> Until now the plan to transition to multiarch is the following:
> - apply patch to binutils
> - apply patch to gcc
The multiarch includes are already searched by gcc.
When I move /usr/lib32/libc.{a,so} to /usr/lib/i486-linux-gnu and
patch binutils then gcc -m32 works just fine. Without binutils patch
it says "/usr/bin/ld: cannot find -lc". Doesn't even need a gcc
recompile.
What patch is missing?
> - split-out binaries from libc6
and move libnss* and gconv to multiarch dirs.
> all those steps could be done in parallel
>
> - implement multiarch in dpkg.
That can be done in parallel too. And it can be tested with simple
libs like zlib without the need to have glibc fully ready.
> Then you can install libc6:i386 on an amd64 system. No need to make an
> other change, as libc6:i386 provide
Every other library can also be changed to multiarch in
parallel. Provided ld looks there.
A prime candidate for this is fakeroot which comes with libs for
multiple archs. Since nothing gets compiled against those libs the
binutils bug doesn't matter there. The ideal package to test and use
the runtime stuff for multiarch. It only needs support from the ld,
meaning libc6-i386 on amd64.
>> The
>> ld.so.conf.d/i486-linux-gnu.conf files only logical place is in the
>> libc6[-i386] packages and the multiarch libc6 oni386 already has to
>> conflict with libc6-i386 on amd64 (reverse for libc6-amd64). If
>> ld.so.conf.d/i486-linux-gnu.conf is in any other package then that
>> just further complicates the dependencies and conflicts in the future.
>
> Why do you want to add a conflict there? There is no need now. But if
> you add the file, there will be a need to do that.
Both libc6:i386 and libc6-i386 provide the ld. Without proper
conflicts, replaces, provides you get an overwrite error. So I don't
add a conflict where there isn't already is one.
> Why do you want for libc6-i386 servers as a "transition package" while
> simply installing libc6:i386 will work?
Because we don't have a (usable) libc6:i386 in the archive yet and
with the goal of multiarch it is not there to stay. So it is
temporary, transitional. That's just what it is.
The current libc6:i386 does not look in the multiarch dirs for its
plugins so it can not be converted by the apt/dpkg-deb wrapper
automatically. It needs to be patched and recompiled for that. Most
other packages can be converted on the fly. The closer libc6-i386
mimics a multiarch libc6:i386 the better people can test multiarch
with the wrapper or convert their own libs.
>> I see 3 scenarios where I would consider this bug fixed:
>>
>> 1) you add the file
>
> From my point of view this will complexify the transition to
> multiarch, because you will need to add conflicts.
The ld already neccessitates the conflict so no change there.
>> 2) ia32-libs takes the libc6-i386 package
>
> I already explained I am not in favor of that.
And I prefer it that way too as long as it doesn't hinder me.
>> 3) binutils adds the patch from #369064 and obsoletes the
>>/etc/ld.so.conf.d/arch-os-gnu.conf files
>
> I don't see how it would fix the "problem". This patch only add the
> native multiarch directory (ie i486-linux-gnu on i386,
> x86_64-linux-gnu on amd64, etc...) to the search path. Not the 32- or
> 64-bit counterpart one. Well I haven't looked in deep in your latest
> patch...
Please read that bug again. It adds the native multiarch dir to every
output format. The native dir for that format. Elf 32bit i486 gets
i486-linux-gnu as dir. Elf 64bit amd64 gets x86_64-linux-gnu as
dir. Exactly as we want it. It is easy to miss because binutils still
uses i386 so /usr/lib/i386-linux-gnu is used. The second patch
corrects that too.
In fact this is better than ld.so.conf.d since only linking 32bit code
would look in i486-linux-gnu and only 64bit code in x86_64-linux-gnu.
No '/usr/bin/ld: skipping incompatible
/usr/lib/x86_64-linux-gnu/libc.so when searching for -lc' warnings.
MfG
Goswin
Bug#388489: Processed: Cloning this bug
Goswin von Brederlow a écrit : Test multiarch: % mkdir /usr/lib/i486-linux-gnu % mv /usr/lib32/libz.* /usr/lib/i486-linux-gnu Wrong. The purpose of multiarch is to remove bi-arch packages. With multiarch if you want to install a 32-bit glibc on amd64, install the package from i386. Not libc6-i386. We can't lay an egg because we have no chicken and we can't breed a chicken because we have no eggs. The purpose of libc6-i386 is to cover the interim time till multiarch and it isn't to strictly deadlock everything at bi-arch. Well that's your opinion. It's not my opinion and also not the opinion of Tollef for example (we discussed about how to implement multiarch during Fosdem last year). Remeber that we already did have the libc6 package from i386 in use in ia32-libs (and still have). You wanted to have a special libc6-i386 package for amd64 and since you maintain glibc we respected that. We can add libc6 back to the list of packages for amd64 if you don't want to provide a transitional package that mimics multiarch. That would be a one line change. I am in favor of eventually dropping ia32-libs, because I consider this package has not its place in main. You can't rebuild it from sources. I has to go into testing. The ld.so.conf.d/i486-linux-gnu.conf file is essential so multiarch directories can be used already and to allow a smooth transition. What do you mean by "smooth transition"? Could you explain to others what do you have in mind, it seems you have your own view on how to implement and how to do the transition to multiarch. Until now the plan to transition to multiarch is the following: - apply patch to binutils - apply patch to gcc - split-out binaries from libc6 all those steps could be done in parallel - implement multiarch in dpkg. Then you can install libc6:i386 on an amd64 system. No need to make an other change, as libc6:i386 provide The ld.so.conf.d/i486-linux-gnu.conf files only logical place is in the libc6[-i386] packages and the multiarch libc6 oni386 already has to conflict with libc6-i386 on amd64 (reverse for libc6-amd64). If ld.so.conf.d/i486-linux-gnu.conf is in any other package then that just further complicates the dependencies and conflicts in the future. Why do you want to add a conflict there? There is no need now. But if you add the file, there will be a need to do that. Why do you want for libc6-i386 servers as a "transition package" while simply installing libc6:i386 will work? I see 3 scenarios where I would consider this bug fixed: 1) you add the file From my point of view this will complexify the transition to multiarch, because you will need to add conflicts. 2) ia32-libs takes the libc6-i386 package I already explained I am not in favor of that. 3) binutils adds the patch from #369064 and obsoletes the /etc/ld.so.conf.d/arch-os-gnu.conf files I don't see how it would fix the "problem". This patch only add the native multiarch directory (ie i486-linux-gnu on i386, x86_64-linux-gnu on amd64, etc...) to the search path. Not the 32- or 64-bit counterpart one. Well I haven't looked in deep in your latest patch... -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 388489 is wishlist
Processing commands for [EMAIL PROTECTED]: > severity 388489 wishlist Bug#388489: libc6-i386: Missing /etc.ld.so.conf.d/i486-linux-gnu.conf Severity set to `wishlist' from `wishlist' > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 388489 is wishlist
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.20 > severity 388489 wishlist Bug#388489: libc6-i386: Missing /etc.ld.so.conf.d/i486-linux-gnu.conf Severity set to `wishlist' from `wishlist' > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 388489 is wishlist
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.9.20 > severity 388489 wishlist Bug#388489: libc6-i386: Missing /etc.ld.so.conf.d/i486-linux-gnu.conf Severity set to `wishlist' from `grave' > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
