linux-kernel - [Q] eCryptFS race window?

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

Message-ID: <20080520170321.GC6926@cvg>
Date:	Tue, 20 May 2008 21:03:21 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	"Michael A. Halcrow" <mhalcrow@...ibm.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: [Q] eCryptFS race window?

Hi Michael,

it seems there is a few potential race window in eCryptFS which I was trying
to fix but it requires more deeper eCrypFS knowledge that have (at least only
by understanding eCryptFS in big picture it is possible to fix this problem
by elegant path). So what is the problem - the procedures

	ecryptfs_miscdev_poll
	ecryptfs_miscdev_read

does take ecryptfs_daemon_hash_mux mutex and then daemon->mux _but_ releases
them not in exactly backward order as it should. My patches (not in mainline
but you saw them) was screwed up 'cause mutex_is_locked could release mutex
acquired by another process and that is wrong. But I've a hope that I'm simply
*wrong* about this possible races ;) Take a look please.

		- Cyrill -
--
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/