linux-kernel - RE: Improving read/write/close system call reliability when used with pthreads

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

Message-ID: <MDEHLPKNGKAHNMBLJOLKOEHMGBAC.davids@webmaster.com>
Date:	Sun, 12 Aug 2007 20:14:47 -0700
From:	"David Schwartz" <davids@...master.com>
To:	<noring@...rew.org>
Cc:	<linux-kernel@...r.kernel.org>
Subject: RE: Improving read/write/close system call reliability when used with pthreads

> 2) Do close reader fd, but what results can then applications
> reliably expect? What would be the sane intention of applications
> closing reader fd? Do programmers expect all of the current results?

> Fredrik

Since there's no atomic "unlock and read" function, any code that could ever
close a socket in one thread while another thread is blocked on read might
call close just before another thread blocks in read. Nothing stops another
thread from opening something, getting the same file descriptor, and then
allowing the thread to call "read" on the wrong file descriptor entirely.

Since this can never be made sane in general, I see little point in making
one variation of what can go wrong a bit saner. It is still irresponsible to
code like this.

DS

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