There existed a race when a process was trying to read from a spliced

socket.  soreceive() releases splsoftnet for uiomove().  In that
moment, somove() could pull the mbuf from the receive buffer.  After
that, soreceive removed the mbuf again.  The corrupted length
accounting resulted in a panic.
The fix is to block read calls in soreceive() until splicing has
been finished.
just commit deraadt@

1 files changed, 6 insertions, 4 deletions

diff --git a/share/man/man9/sosplice.9 b/share/man/man9/sosplice.9
index e21ba301c31..7f865f479fd 100644
--- a/share/man/man9/sosplice.9
+++ b/share/man/man9/sosplice.9
@@ -1,4 +1,4 @@
-.\"	$OpenBSD: sosplice.9,v 1.1 2011/03/08 00:13:41 bluhm Exp $
+.\"	$OpenBSD: sosplice.9,v 1.2 2011/03/12 18:31:41 bluhm Exp $
 .\"
 .\" Copyright (c) 2011 Alexander Bluhm <bluhm@openbsd.org>
 .\"
@@ -14,7 +14,7 @@
 .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 .\"
-.Dd $Mdocdate: March 8 2011 $
+.Dd $Mdocdate: March 12 2011 $
 .Dt SOSPLICE 9
 .Os
 .Sh NAME
@@ -152,8 +152,10 @@ and
 will call
 .Fn somove
 to trigger the transfer when new data or buffer space is available.
-While socket splicing is active, the read wakeup will not be delivered
-to the source file descriptor.
+While socket splicing is active, any
+.Xr read 2
+from the source socket will block and the wakeup will not be delivered
+to the file descriptor.
 A read event is signaled to user-land after dissolving.
 .Sh RETURN VALUES
 .Fn sosplice