linux-kernel - Re: [ARM] Corrupted .got section with 2.6.18 and JFFS2 (solved)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20061114221551.GA17042@localhost>
Date:	Wed, 15 Nov 2006 01:15:51 +0300
From:	Anton Vorontsov <cbou@...l.ru>
To:	Enrico Scholz <enrico.scholz@...ma-chemnitz.de>
Cc:	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org, rpurdie@...ys.net
Subject: Re: [ARM] Corrupted .got section with 2.6.18 and JFFS2 (solved)

Hi all,

On Fri, Nov 03, 2006 at 11:09:35AM +0100, Enrico Scholz wrote:
> [CC lkml; original issue at
>  http://article.gmane.org/gmane.linux.ports.arm.kernel/28068]
> 
> rpurdie@...ys.net (Richard Purdie) writes:
> 
> >> > I have a problem with JFFS2 filesystem and kernel 2.6.18. When
> >> > starting a program which uses a certain library (libutil.so.1 in
> >> > my case), the .got section of the library can be initialized
> >> > wrongly when the used memory is uninitialized.
> >> 
> >> Problem seems to be caused by
> >> 
> >> | [PATCH] zlib_inflate: Upgrade library code to a recent version
> >> 
> >> (4f3865fb57a04db7cca068fed1c15badc064a302)
> >> 
> >> After reverting this (and related patches), things seem to work.
> >> 
> >> I don't have an idea yet, which changes in this complex patch are
> >> really responsible....
> >
> > I'm the author of the above change. I just ran your test program
> > on a device (ARM PXA255 with 2.6.19-rc4 kernel, 2.3.5ish glibc,
> > gcc 3.4.4, libraries on jffs2) and I can't reproduce the
> > problem.
> 
> I can reproduce it 100% with:

As I told before (but it's not delivered to the arm-linux-kernel), I
can reproduce it too, using glibc-2.4 or glibc-2.5. I can't reproduce
it using glibc-2.3.5.

My further investigations shows that reading libutil.so.1
(cat /lib/libutil.so.1 > /dev/null) prior using it eliminates
segfault. That, I suppose, means that glibc can easily operate on 
cached file, but refuses to initially ""read"" it from disk properly.

Quoting Richard Purdie:

"The file is read ok from the disk when copying and when read with
md5sum. I therefore wonder if the dynamic linker is doing something it
shouldn't."

Though, it may be either glibc or JFFS2 issue. As for glibc, it's not
using read() call as do cat, cp or md5sum, glibc using readonly
mmap call (which is supported by JFFS2 if I understood code correctly)
on libraries ld-linux wants to load.

I hope these itinerary of mine will bring some light on that issue, and
someone will guess where real bug is. ;-)

> 
> Enrico

-- Anton (irc: bd2)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/