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]

Message-ID: <20080414170613.GI7385@csclub.uwaterloo.ca>
Date:	Mon, 14 Apr 2008 13:06:13 -0400
From:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
To:	Jan Kara <jack@...e.cz>
Cc:	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?

On Mon, Apr 14, 2008 at 06:53:54PM +0200, Jan Kara wrote:
>   Well, but imagine you have a file /proc/my_secret_file from which you
> are able to read from position A:a and B:b but not from position
> A:b. Concievably, checks for the file position could be bypassed because of
> this race... I know this is kind of dumb example but I can imagine someone
> can eventually find something like this. So I guess one spin lock/unlock
> pair is a price worth paying in the callpath which is quite long anyway.

But only two threads within the process can read from the filehandle and
hence the process would be doing locking.  And external attacker can't
break the internal locking of the process between the threads, and even
if you do open the file in /proc that the process is using, being and
external process you would have your own file handle and hence your own
file position since you aren't part of that process.

-- 
Len Sorensen
--
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/