Fix the length calculation for the final block of a sendfile(2)

transmission which could be tricked into rounding up to the nearest
page size, leaking up to a page of kernel memory.  [13:11]

In IPv6 and NetATM, stop SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR
and SIOCSIFNETMASK at the socket layer rather than pass them on to the
link layer without validation or credential checks.  [SA-13:12]

Prevent cross-mount hardlinks between different nullfs mounts of the
same underlying filesystem.  [SA-13:13]

Security:	CVE-2013-5666
Security:	FreeBSD-SA-13:11.sendfile
Security:	CVE-2013-5691
Security:	FreeBSD-SA-13:12.ifioctl
Security:	CVE-2013-5710
Security:	FreeBSD-SA-13:13.nullfs
Approved by:	so

11 files changed, 600 insertions, 0 deletions

diff --git a/share/security/advisories/FreeBSD-SA-13:11.sendfile.asc b/share/security/advisories/FreeBSD-SA-13:11.sendfile.asc
new file mode 100644
index 0000000000..191e683c11
--- /dev/null
+++ b/share/security/advisories/FreeBSD-SA-13:11.sendfile.asc
@@ -0,0 +1,126 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+=============================================================================
+FreeBSD-SA-13:11.sendfile                                   Security Advisory
+                                                          The FreeBSD Project
+
+Topic:          Kernel memory disclosure in sendfile(2)
+
+Category:       core
+Module:         sendfile
+Announced:      2013-09-10
+Credits:        Ed Maste
+Affects:        FreeBSD 9.2-RC1 and 9.2-RC2
+Corrected:      2013-09-10 10:07:21 UTC (stable/9, 9.2-STABLE)
+                2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC1-p2)
+                2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC2-p2)
+CVE Name:       CVE-2013-5666
+
+For general information regarding FreeBSD Security Advisories,
+including descriptions of the fields above, security branches, and the
+following sections, please visit <URL:http://security.FreeBSD.org/>.
+
+I.   Background
+
+The sendfile(2) system call allows a server application (such as an
+HTTP or FTP server) to transmit the contents of a file over a network
+connection without first copying it to application memory.  High
+performance servers such as Apache and ftpd use sendfile.
+
+II.  Problem Description
+
+On affected systems, if the length passed to sendfile(2) is non-zero
+and greater than the length of the file being transmitted, sendfile(2)
+will pad the transmission up to the requested length or the next
+pagesize boundary, whichever is smaller.
+
+The content of the additional bytes transmitted in this manner depends
+on the underlying filesystem, but may potentially include information
+useful to an attacker.
+
+III. Impact
+
+An unprivileged user with the ability to run arbitrary code may be
+able to obtain arbitrary kernel memory contents.
+
+IV.  Workaround
+
+No workaround is available.
+
+V.   Solution
+
+Perform one of the following:
+
+1) Upgrade your vulnerable system to a supported FreeBSD stable or
+release / security branch (releng) dated after the correction date.
+
+2) To update your vulnerable system via a source code patch:
+
+The following patches have been verified to apply to the applicable
+FreeBSD release branches.
+
+a) Download the relevant patch from the location below, and verify the
+detached PGP signature using your PGP utility.
+
+[FreeBSD 9.2-STABLE]
+# fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-stable.patch
+# fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-stable.patch.asc
+# gpg --verify sendfile-9.2-stable.patch.asc
+
+[FreeBSD 9.2-RC1 and 9.2-RC2]
+# fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-rc.patch
+# fetch http://security.FreeBSD.org/patches/SA-13:11/sendfile-9.2-rc.patch.asc
+# gpg --verify sendfile-9.2-rc.patch.asc
+
+b) Apply the patch.
+
+# cd /usr/src
+# patch < /path/to/patch
+
+c) Recompile your kernel as described in
+<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
+system.
+
+3) To update your vulnerable system via a binary patch:
+
+Systems running a RELEASE version of FreeBSD on the i386 or amd64
+platforms can be updated via the freebsd-update(8) utility:
+
+# freebsd-update fetch
+# freebsd-update install
+
+VI.  Correction details
+
+The following list contains the correction revision numbers for each
+affected branch.
+
+Branch/path                                                      Revision
+- -------------------------------------------------------------------------
+stable/9/                                                         r255443
+releng/9.2/                                                       r255444
+- -------------------------------------------------------------------------
+
+To see which files were modified by a particular revision, run the
+following command, replacing NNNNNN with the revision number, on a
+machine with Subversion installed:
+
+# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
+
+Or visit the following URL, replacing NNNNNN with the revision number:
+
+<URL:http://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
+
+VII. References
+
+<URL:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5666>
+
+The latest revision of this advisory is available at
+<URL:http://security.FreeBSD.org/advisories/FreeBSD-SA-13:11.sendfile.asc>
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.14 (FreeBSD)
+
+iEYEARECAAYFAlIu8rIACgkQFdaIBMps37K01ACgmwaW3PZhjDqWSlTHusjIPNVy
+A/YAn3DFUAvlX8sH89taM+sedjbD5In8
+=gZwu
+-----END PGP SIGNATURE-----
diff --git a/share/security/advisories/FreeBSD-SA-13:12.ifioctl.asc b/share/security/advisories/FreeBSD-SA-13:12.ifioctl.asc
new file mode 100644
index 0000000000..5bdf6b1431
--- /dev/null
+++ b/share/security/advisories/FreeBSD-SA-13:12.ifioctl.asc
@@ -0,0 +1,150 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+=============================================================================
+FreeBSD-SA-13:12.ifioctl                                    Security Advisory
+                                                          The FreeBSD Project
+
+Topic:          Insufficient credential checks in network ioctl(2)
+
+Category:       core
+Module:         sys_netinet6 sys_netatm
+Announced:      2013-09-10
+Credits:        Loganaden Velvindron
+                Gleb Smirnoff
+Affects:        All supported versions of FreeBSD.
+Corrected:      2013-09-10 10:07:21 UTC (stable/9, 9.2-STABLE)
+                2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC1-p2)
+                2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC2-p2)
+                2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC3-p1)
+                2013-09-10 10:15:33 UTC (releng/9.1, 9.1-RELEASE-p7)
+                2013-09-10 10:12:09 UTC (stable/8, 8.4-STABLE)
+                2013-09-10 10:14:19 UTC (releng/8.4, 8.4-RELEASE-p4)
+                2013-09-10 10:13:14 UTC (releng/8.3, 8.3-RELEASE-p11)
+CVE Name:       CVE-2013-5691
+
+For general information regarding FreeBSD Security Advisories,
+including descriptions of the fields above, security branches, and the
+following sections, please visit <URL:http://security.FreeBSD.org/>.
+
+I.   Background
+
+The ioctl(2) system call allows an application to perform device- or
+protocol-specific operations through a file or socket descriptor
+associated with a specific device or protocol.
+
+The SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR and SIOCSIFNETMASK
+ioctl requests are used to associate a network address, broadcast
+address, destination address (for point-to-point interfaces) or
+netmask with an interface.  They operate on the assumption that each
+interface only has one address per protocol, and are therefore of
+limited use for IPv4, where interfaces may have more than one address.
+They were never implemented for IPv6, where interfaces nearly always
+have at least two, and in many cases three, addresses; nor were they
+ever implemented for ATM.
+
+II.  Problem Description
+
+As is commonly the case, the IPv6 and ATM network layer ioctl request
+handlers are written in such a way that an unrecognized request is
+passed on unmodified to the link layer, which will either handle it or
+return an error code.
+
+Network interface drivers, however, assume that the SIOCSIFADDR,
+SIOCSIFBRDADDR, SIOCSIFDSTADDR and SIOCSIFNETMASK requests have been
+handled at the network layer, and therefore do not perform input
+validation or verify the caller's credentials.  Typical link-layer
+actions for these requests may include marking the interface as "up"
+and resetting the underlying hardware.
+
+III. Impact
+
+An unprivileged user with the ability to run arbitrary code can cause
+any network interface in the system to perform the link layer actions
+associated with a SIOCSIFADDR, SIOCSIFBRDADDR, SIOCSIFDSTADDR or
+SIOCSIFNETMASK ioctl request; or trigger a kernel panic by passing a
+specially crafted address structure which causes a network interface
+driver to dereference an invalid pointer.
+
+Although this has not been confirmed, the possibility that an attacker
+may be able to execute arbitrary code in kernel context can not be
+ruled out.
+
+IV.  Workaround
+
+No workaround is available.
+
+V.   Solution
+
+Perform one of the following:
+
+1) Upgrade your vulnerable system to a supported FreeBSD stable or
+release / security branch (releng) dated after the correction date.
+
+2) To update your vulnerable system via a source code patch:
+
+The following patches have been verified to apply to the applicable
+FreeBSD release branches.
+
+a) Download the relevant patch from the location below, and verify the
+detached PGP signature using your PGP utility.
+
+# fetch http://security.FreeBSD.org/patches/SA-13:12/ifioctl.patch
+# fetch http://security.FreeBSD.org/patches/SA-13:12/ifioctl.patch.asc
+# gpg --verify ifioctl.patch.asc
+
+b) Apply the patch.
+
+# cd /usr/src
+# patch < /path/to/patch
+
+c) Recompile your kernel as described in
+<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
+system.
+
+3) To update your vulnerable system via a binary patch:
+
+Systems running a RELEASE version of FreeBSD on the i386 or amd64
+platforms can be updated via the freebsd-update(8) utility:
+
+# freebsd-update fetch
+# freebsd-update install
+
+VI.  Correction details
+
+The following list contains the correction revision numbers for each
+affected branch.
+
+Branch/path                                                      Revision
+- -------------------------------------------------------------------------
+stable/8/                                                         r255445
+releng/8.3/                                                       r255446
+releng/8.4/                                                       r255447
+stable/9/                                                         r255443
+releng/9.1/                                                       r255448
+releng/9.2/                                                       r255444
+- -------------------------------------------------------------------------
+
+To see which files were modified by a particular revision, run the
+following command, replacing NNNNNN with the revision number, on a
+machine with Subversion installed:
+
+# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
+
+Or visit the following URL, replacing NNNNNN with the revision number:
+
+<URL:http://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
+
+VII. References
+
+<URL:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5691>
+
+The latest revision of this advisory is available at
+<URL:http://security.FreeBSD.org/advisories/FreeBSD-SA-13:12.ifioctl.asc>
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.14 (FreeBSD)
+
+iEYEARECAAYFAlIu8rUACgkQFdaIBMps37ImRQCdGUcSBvK6+kAN69aGChHT6fVb
+YI4AoJNveN9PSowTG0NnUkPJR9oJimZT
+=xb3g
+-----END PGP SIGNATURE-----
diff --git a/share/security/advisories/FreeBSD-SA-13:13.nullfs.asc b/share/security/advisories/FreeBSD-SA-13:13.nullfs.asc
new file mode 100644
index 0000000000..06aab44ca0
--- /dev/null
+++ b/share/security/advisories/FreeBSD-SA-13:13.nullfs.asc
@@ -0,0 +1,139 @@
+-----BEGIN PGP SIGNED MESSAGE-----
+Hash: SHA1
+
+=============================================================================
+FreeBSD-SA-13:13.nullfs                                     Security Advisory
+                                                          The FreeBSD Project
+
+Topic:          Cross-mount links between nullfs(5) mounts
+
+Category:       core
+Module:         nullfs
+Announced:      2013-09-10
+Credits:        Mateusz Guzik
+		Konstantin Belousov
+Affects:        All supported versions of FreeBSD.
+Corrected:      2013-09-10 10:07:21 UTC (stable/9, 9.2-STABLE)
+                2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC1-p2)
+                2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC2-p2)
+                2013-09-10 10:08:20 UTC (releng/9.2, 9.2-RC3-p1)
+                2013-09-10 10:15:33 UTC (releng/9.1, 9.1-RELEASE-p7)
+                2013-09-10 10:12:09 UTC (stable/8, 8.4-STABLE)
+                2013-09-10 10:14:19 UTC (releng/8.4, 8.4-RELEASE-p4)
+                2013-09-10 10:13:14 UTC (releng/8.3, 8.3-RELEASE-p11)
+CVE Name:       CVE-2013-5710
+
+For general information regarding FreeBSD Security Advisories,
+including descriptions of the fields above, security branches, and the
+following sections, please visit <URL:http://security.FreeBSD.org/>.
+
+I.   Background
+
+The nullfs(5) filesystem allows all or a part of an already mounted
+filesystem to be made available in a different part of the global
+filesystem namespace.  It is commonly used to make a set of files
+available to multiple chroot(2) or jail(2) environments without
+replicating the files in each environment.  A common idiom, described
+in the FreeBSD Handbook, is to mount one subtree of a filesystem
+read-only within a jail's filesystem namespace, and mount a different
+subtree of the same filesystem read-write.
+
+II.  Problem Description
+
+The nullfs(5) implementation of the VOP_LINK(9) VFS operation does not
+check whether the source and target of the link are both in the same
+nullfs instance.  It is therefore possible to create a hardlink from a
+location in one nullfs instance to a file in another, as long as the
+underlying (source) filesystem is the same.
+
+III. Impact
+
+If multiple nullfs views into the same filesystem are mounted in
+different locations, a user with read access to one of these views and
+write access to another will be able to create a hard link from the
+latter to a file in the former, even though they are, from the user's
+perspective, different filesystems.  The user may thereby gain write
+access to files which are nominally on a read-only filesystem.
+
+IV.  Workaround
+
+No workaround is available, but systems which do not use the nullfs(5)
+filesystem, or do not null-mount different subtrees of the same source
+filesystem with different permissions, are not vulnerable.
+
+V.   Solution
+
+Perform one of the following:
+
+1) Upgrade your vulnerable system to a supported FreeBSD stable or
+release / security branch (releng) dated after the correction date.
+
+2) To update your vulnerable system via a source code patch:
+
+The following patches have been verified to apply to the applicable
+FreeBSD release branches.
+
+a) Download the relevant patch from the location below, and verify the
+detached PGP signature using your PGP utility.
+
+# fetch http://security.FreeBSD.org/patches/SA-13:13/nullfs.patch
+# fetch http://security.FreeBSD.org/patches/SA-13:13/nullfs.patch.asc
+# gpg --verify nullfs.patch.asc
+
+b) Apply the patch.
+
+# cd /usr/src
+# patch < /path/to/patch
+
+c) Recompile your kernel as described in
+<URL:http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the
+system.
+
+3) To update your vulnerable system via a binary patch:
+
+Systems running a RELEASE version of FreeBSD on the i386 or amd64
+platforms can be updated via the freebsd-update(8) utility:
+
+# freebsd-update fetch
+# freebsd-update install
+
+VI.  Correction details
+
+The following list contains the correction revision numbers for each
+affected branch.
+
+Branch/path                                                      Revision
+- -------------------------------------------------------------------------
+stable/8/                                                         r255445
+releng/8.3/                                                       r255446
+releng/8.4/                                                       r255447
+stable/9/                                                         r255443
+releng/9.1/                                                       r255448
+releng/9.2/                                                       r255444
+- -------------------------------------------------------------------------
+
+To see which files were modified by a particular revision, run the
+following command, replacing NNNNNN with the revision number, on a
+machine with Subversion installed:
+
+# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base
+
+Or visit the following URL, replacing NNNNNN with the revision number:
+
+<URL:http://svnweb.freebsd.org/base?view=revision&revision=NNNNNN>
+
+VII. References
+
+<URL:http://www.freebsd.org/doc/en/books/handbook/jails-application.html>
+
+<URL:http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5710>
+
+The latest revision of this advisory is available at
+<URL:http://security.FreeBSD.org/advisories/FreeBSD-SA-13:13.nullfs.asc>
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.14 (FreeBSD)
+
+iEYEARECAAYFAlIu8rgACgkQFdaIBMps37KX4QCgn/PjsnAZItGRi7CMbp2jlFvS
+IokAniKX2FVr8xXuJPtrLdv+7syjCTQt
+=Lj26
+-----END PGP SIGNATURE-----
diff --git a/share/security/patches/SA-13:11/sendfile-9.2-rc.patch b/share/security/patches/SA-13:11/sendfile-9.2-rc.patch
new file mode 100644
index 0000000000..aeb5c9f202
--- /dev/null
+++ b/share/security/patches/SA-13:11/sendfile-9.2-rc.patch
@@ -0,0 +1,20 @@
+Index: sys/kern/uipc_syscalls.c
+===================================================================
+--- sys/kern/uipc_syscalls.c	(revision 253912)
++++ sys/kern/uipc_syscalls.c	(working copy)
+@@ -2087,11 +2087,10 @@
+ 			 * or the passed in nbytes.
+ 			 */
+ 			pgoff = (vm_offset_t)(off & PAGE_MASK);
+-			if (uap->nbytes)
+-				rem = (uap->nbytes - fsbytes - loopbytes);
+-			else
+-				rem = va.va_size -
+-				    uap->offset - fsbytes - loopbytes;
++			rem = obj->un_pager.vnp.vnp_size - uap->offset;
++			if (uap->nbytes != 0)
++				rem = omin(rem, uap->nbytes);
++			rem -= fsbytes + loopbytes;
+ 			xfsize = omin(PAGE_SIZE - pgoff, rem);
+ 			xfsize = omin(space - loopbytes, xfsize);
+ 			if (xfsize <= 0) {
diff --git a/share/security/patches/SA-13:11/sendfile-9.2-rc.patch.asc b/share/security/patches/SA-13:11/sendfile-9.2-rc.patch.asc
new file mode 100644
index 0000000000..3c183fc1d7
--- /dev/null
+++ b/share/security/patches/SA-13:11/sendfile-9.2-rc.patch.asc
@@ -0,0 +1,7 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.14 (FreeBSD)
+
+iEYEABECAAYFAlIuF7gACgkQFdaIBMps37LokwCcD0WafThPclpU1qRNCTzNhe61
+S04AmwfYZwH8ZsCbTWFw1bZVOhcqim/m
+=6DgA
+-----END PGP SIGNATURE-----
diff --git a/share/security/patches/SA-13:11/sendfile-9.2-stable.patch b/share/security/patches/SA-13:11/sendfile-9.2-stable.patch
new file mode 100644
index 0000000000..21805c6325
--- /dev/null
+++ b/share/security/patches/SA-13:11/sendfile-9.2-stable.patch
@@ -0,0 +1,20 @@
+Index: sys/kern/uipc_syscalls.c
+===================================================================
+--- sys/kern/uipc_syscalls.c	(revision 255414)
++++ sys/kern/uipc_syscalls.c	(working copy)
+@@ -2126,11 +2126,10 @@
+ 			 * or the passed in nbytes.
+ 			 */
+ 			pgoff = (vm_offset_t)(off & PAGE_MASK);
+-			if (uap->nbytes)
+-				rem = (uap->nbytes - fsbytes - loopbytes);
+-			else
+-				rem = va.va_size -
+-				    uap->offset - fsbytes - loopbytes;
++			rem = va.va_size - uap->offset;
++			if (uap->nbytes != 0)
++				rem = omin(rem, uap->nbytes);
++			rem -= fsbytes + loopbytes;
+ 			xfsize = omin(PAGE_SIZE - pgoff, rem);
+ 			xfsize = omin(space - loopbytes, xfsize);
+ 			if (xfsize <= 0) {
diff --git a/share/security/patches/SA-13:11/sendfile-9.2-stable.patch.asc b/share/security/patches/SA-13:11/sendfile-9.2-stable.patch.asc
new file mode 100644
index 0000000000..182c78bf2d
--- /dev/null
+++ b/share/security/patches/SA-13:11/sendfile-9.2-stable.patch.asc
@@ -0,0 +1,7 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.14 (FreeBSD)
+
+iEYEABECAAYFAlIuF70ACgkQFdaIBMps37Ir2ACeJiObKBkQvyI/3HTotiQnx+7p
+laYAoJZlhgNrqHbAiaDg5qjUbTPZCECa
+=GX/T
+-----END PGP SIGNATURE-----
diff --git a/share/security/patches/SA-13:12/ifioctl.patch b/share/security/patches/SA-13:12/ifioctl.patch
new file mode 100644
index 0000000000..9aef1503f7
--- /dev/null
+++ b/share/security/patches/SA-13:12/ifioctl.patch
@@ -0,0 +1,89 @@
+Index: sys/net/if.c
+===================================================================
+--- sys/net/if.c	(revision 254941)
++++ sys/net/if.c	(working copy)
+@@ -2553,11 +2553,23 @@
+ 		CURVNET_RESTORE();
+ 		return (EOPNOTSUPP);
+ 	}
++
++	/*
++	 * Pass the request on to the socket control method, and if the
++	 * latter returns EOPNOTSUPP, directly to the interface.
++	 *
++	 * Make an exception for the legacy SIOCSIF* requests.  Drivers
++	 * trust SIOCSIFADDR et al to come from an already privileged
++	 * layer, and do not perform any credentials checks or input
++	 * validation.
++	 */
+ #ifndef COMPAT_43
+ 	error = ((*so->so_proto->pr_usrreqs->pru_control)(so, cmd,
+ 								 data,
+ 								 ifp, td));
+-	if (error == EOPNOTSUPP && ifp != NULL && ifp->if_ioctl != NULL)
++	if (error == EOPNOTSUPP && ifp != NULL && ifp->if_ioctl != NULL &&
++	    cmd != SIOCSIFADDR && cmd != SIOCSIFBRDADDR &&
++	    cmd != SIOCSIFDSTADDR && cmd != SIOCSIFNETMASK)
+ 		error = (*ifp->if_ioctl)(ifp, cmd, data);
+ #else
+ 	{
+@@ -2601,7 +2613,9 @@
+ 								   data,
+ 								   ifp, td));
+ 		if (error == EOPNOTSUPP && ifp != NULL &&
+-		    ifp->if_ioctl != NULL)
++		    ifp->if_ioctl != NULL &&
++		    cmd != SIOCSIFADDR && cmd != SIOCSIFBRDADDR &&
++		    cmd != SIOCSIFDSTADDR && cmd != SIOCSIFNETMASK)
+ 			error = (*ifp->if_ioctl)(ifp, cmd, data);
+ 		switch (ocmd) {
+ 
+Index: sys/netinet6/in6.c
+===================================================================
+--- sys/netinet6/in6.c	(revision 254941)
++++ sys/netinet6/in6.c	(working copy)
+@@ -431,6 +431,18 @@
+ 	case SIOCGIFSTAT_ICMP6:
+ 		sa6 = &ifr->ifr_addr;
+ 		break;
++	case SIOCSIFADDR:
++	case SIOCSIFBRDADDR:
++	case SIOCSIFDSTADDR:
++	case SIOCSIFNETMASK:
++		/*
++		 * Although we should pass any non-INET6 ioctl requests
++		 * down to driver, we filter some legacy INET requests.
++		 * Drivers trust SIOCSIFADDR et al to come from an already
++		 * privileged layer, and do not perform any credentials
++		 * checks or input validation.
++		 */
++		return (EINVAL);
+ 	default:
+ 		sa6 = NULL;
+ 		break;
+Index: sys/netnatm/natm.c
+===================================================================
+--- sys/netnatm/natm.c	(revision 254941)
++++ sys/netnatm/natm.c	(working copy)
+@@ -339,6 +339,21 @@
+ 	npcb = (struct natmpcb *)so->so_pcb;
+ 	KASSERT(npcb != NULL, ("natm_usr_control: npcb == NULL"));
+ 
++	switch (cmd) {
++	case SIOCSIFADDR:
++	case SIOCSIFBRDADDR:
++	case SIOCSIFDSTADDR:
++	case SIOCSIFNETMASK:
++		/*
++		 * Although we should pass any non-ATM ioctl requests
++		 * down to driver, we filter some legacy INET requests.
++		 * Drivers trust SIOCSIFADDR et al to come from an already
++		 * privileged layer, and do not perform any credentials
++		 * checks or input validation.
++		 */
++		return (EINVAL);
++	}
++
+ 	if (ifp == NULL || ifp->if_ioctl == NULL)
+ 		return (EOPNOTSUPP);
+ 	return ((*ifp->if_ioctl)(ifp, cmd, arg));
diff --git a/share/security/patches/SA-13:12/ifioctl.patch.asc b/share/security/patches/SA-13:12/ifioctl.patch.asc
new file mode 100644
index 0000000000..b28a32f6b9
--- /dev/null
+++ b/share/security/patches/SA-13:12/ifioctl.patch.asc
@@ -0,0 +1,7 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.14 (FreeBSD)
+
+iEYEABECAAYFAlIuF98ACgkQFdaIBMps37KefgCeNtxM4xIH3gYvoj4BbefvRoC8
+I8gAnRT1I915xp4nk2lgWK+5HGoDqApO
+=W+Ro
+-----END PGP SIGNATURE-----
diff --git a/share/security/patches/SA-13:13/nullfs.patch b/share/security/patches/SA-13:13/nullfs.patch
new file mode 100644
index 0000000000..83f30e84fe
--- /dev/null
+++ b/share/security/patches/SA-13:13/nullfs.patch
@@ -0,0 +1,28 @@
+Index: sys/fs/nullfs/null_vnops.c
+===================================================================
+--- sys/fs/nullfs/null_vnops.c	(revision 254941)
++++ sys/fs/nullfs/null_vnops.c	(working copy)
+@@ -858,6 +858,15 @@
+ 	return (error);
+ }
+ 
++static int
++null_link(struct vop_link_args *ap)
++{
++
++	if (ap->a_tdvp->v_mount != ap->a_vp->v_mount)
++		return (EXDEV);
++	return (null_bypass((struct vop_generic_args *)ap));
++}
++
+ /*
+  * Global vfs data structures
+  */
+@@ -871,6 +880,7 @@
+ 	.vop_getwritemount =	null_getwritemount,
+ 	.vop_inactive =		null_inactive,
+ 	.vop_islocked =		vop_stdislocked,
++	.vop_link =		null_link,
+ 	.vop_lock1 =		null_lock,
+ 	.vop_lookup =		null_lookup,
+ 	.vop_open =		null_open,
diff --git a/share/security/patches/SA-13:13/nullfs.patch.asc b/share/security/patches/SA-13:13/nullfs.patch.asc
new file mode 100644
index 0000000000..e5cdf5919e
--- /dev/null
+++ b/share/security/patches/SA-13:13/nullfs.patch.asc
@@ -0,0 +1,7 @@
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.14 (FreeBSD)
+
+iEYEABECAAYFAlIuGawACgkQFdaIBMps37J1OgCgm847iabfWVTdyCXAeXVQkK/g
+ZR4AoJrz+a812XboghdqiTvVKVHUyD+b
+=wGcC
+-----END PGP SIGNATURE-----