linux-kernel - Re: file offset corruption on 32-bit machines?

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Apr 2008 21:12:38 +0200
From:	Pavel Machek <pavel@....cz>
To:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Cc:	Jan Kara <jack@...e.cz>, Bodo Eggert <7eggert@....de>,
	Diego Calleja <diegocg@...il.com>,
	Jiri Kosina <jkosina@...e.cz>, Michal Hocko <mhocko@...e.cz>,
	Meelis Roos <mroos@...ux.ee>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: file offset corruption on 32-bit machines?

Hi!

> > Yes, kernel bugs are confusing ;-).
> 
> I only see an application bug so far.

Really?

>       The lseek() function repositions the offset of the open file
> associated with
>       the file descriptor fildes to the argument offset according to
>the directive
>       whence as follows:

It does not say "repositions the offset to the random number" nor
"under certain conditions repositions the offsets" nor "it repositions
the offset unless you are unlucky and hit kernel race". More
seriously, it does not contain note "not safe from multithreaded
programs" nor "multithreaded behaviour is undefined".

So this pretty clearly is application bug.

> > The "application" could be malware trying to confuse debugger, for
> > example.
> 
> If you can't do it on demand (which I can't see any way to do) then I
> don't think malware can take advantage of it.

Really? I see an application to detecting if I'm being debugged. Try
to hit the race 1000 times, if you hit it, you are probably not
debugged (because debugger would be very likely to make that race hard
to hit). Will only work on multicores, but...

[Plus, there's "strace seen it writing to either offset A or offset B,
but I see the data at offset C, WTF?]

> > The "application" could be something you are trying to debug.
> 
> True, but even without this behaviour doing seeks and read/writes from
> multiple threads without locking will already show plenty of problems
> even if you somehow manage to hit this issue, and not only that you have
> to have threads writing to different 4GB aligned chunks of the file
> cause a problem, since otherwise they would all be setting the top bits
> the same.  I would hope anyone doing multithreaded work on a file that
> big would like to avoid the locking issue by using pread and pwrite
> instead in which case there is no problem either.

I'm not saying this kernel bug is likely to hit in practice. It is
still a kernel bug.

Is the slowdown of lseek worth getting rid of this minor bug? Not
sure, probably yes.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/