kern/95559: [RELENG_6] write(2) fails with EPERM on TCP socket under certain situations

[Xin LI]

>Number:         95559
>Category:       kern
>Synopsis:       [RELENG_6] write(2) fails with EPERM on TCP socket under certain situations
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Apr 10 01:50:14 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Xin LI
>Release:        FreeBSD 6.1-RC i386
>Organization:
The FreeBSD Project
>Environment:
System: FreeBSD tarsier.delphij.net 6.1-RC FreeBSD 6.1-RC #26: Sun Apr 9 04:27:53 CST 2006 delphij at tarsier.delphij.net:/usr/obj/usr/src/sys/TARSIER i386

>Description:
	With two rule set in pf.conf, connection from cvsup client
within a jail to the cvsupd running in the host would fail, which
ends up with that cvsupd (in the host) died with write(2) on the
TCP socket, which suddenly returns EPERM.

	The box has pf(4) and ipfw(4) installed where, pf(4) was
loaded with two rules, while ipfw(4) has an empty ruleset with
a default accept rule.
>How-To-Repeat:

	First, one should load the following ruleset onto pf(4)

--- pf.conf begins here ---
scrub reassemble tcp random-id
set skip on lo0
--- pf.conf ends here ---

	Second, run a cvsupd daemon from the host.

	Third, set up a jail and try to transfer some big data
from the host.

	A ktrace dump is available at:
		http://www.delphij.net/kdump.txt.bz2

	Please note that the dump is big (about 7MB).

>Fix:

	By removing either rule from the pf.conf seems to work
around the issue.  However, we have grep'ed EPERM from netinet
and pf code and found that there is not a reasonable reason
why write(2) would return EPERM in the code path.
>Release-Note:
>Audit-Trail:
>Unformatted: