netdev - RE: [PATCH] net: unix: non blocking recvmsg() should not return -EINTR

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:	Wed, 26 Mar 2014 15:00:27 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Eric Dumazet' <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>
CC:	netdev <netdev@...r.kernel.org>,
	Rainer Weikusat <rweikusat@...ileactivedefense.com>
Subject: RE: [PATCH] net: unix: non blocking recvmsg() should not return
 -EINTR

From: Eric Dumazet
> From: Eric Dumazet <edumazet@...gle.com>
> 
> Some applications didn't expect recvmsg() on a non blocking socket
> could return -EINTR. This possibility was added as a side effect
> of commit b3ca9b02b00704 ("net: fix multithreaded signal handling in
> unix recv routines").
> 
> To hit this bug, you need to be a bit unlucky, as the u->readlock
> mutex is usually held for very small periods.

The commit message for b3ca9b02b00704 looks very strange.
Maybe something else is wrong.

If we assume that u->readlock is only held for a short period
why should it matter than the kernel decided to give the
signal to that thread?

There is the hint that if there are multiple readers, all
but one are blocked waiting for u->readlock.
But I should be able to have on thread/process doing
a blocking read and a second doing a non-blocking read
(through a different fd).

If we assume that all readers are either blocking or non-blocking
then maybe u->readlock should be acquired non-interruptibly
in the non-block case.

Then you don't have to worry about the return code.

	David