full-disclosure - Linux kernel file offset pointer races

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 for Android: free password hash cracker in your pocket

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

From: peak at argo.troja.mff.cuni.cz (Pavel Kankovsky)
Subject: Linux kernel file offset pointer races

On Wed, 4 Aug 2004, Andrew Farmer wrote:

> Furthermore, mtrr_read doesn't seem to exist anywhere in the Linux
> kernel, at least not by that name. The function in question would
> probably exist in linux/arch/i386/kernel/cpu/mtrr/if.c, but there's
> nothing of the sort in there. Heck, the kernel code shown isn't even
> VALID.

The kernel code shown is from arch/i386/kernel/mtrr.c in 2.4. 2.6 is
different but the race between read()/write() and llseek() (or even
other read()/write() on the same fd (*)) is still possible. I don't know
whether it is exploitable on 2.6 but afaik it violates POSIX (see my post
to LKML: http://www.uwsg.iu.edu/hypermail/linux/kernel/0408.0/0925.html)
ergo it should be fixed.

(*) write()-write() race on the same inode using generic_file_write() is
not possible because they are serialized by inode->i_sem.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."