Pull up following revision(s) (requested by maxv in ticket #1048):
	sys/kern/kern_exec.c: revision 1.403
'error' is not set on failure. This is a true bug: everything is freed
and unlocked while zero is returned. Since there's no error, execve_runproc()
will get called and will try to use those freed things.
Pull up following revision(s) (requested by abs in ticket #1049):
	distrib/sets/lists/base/rescue.ad.m68k.shl: revision 1.3
	distrib/sets/lists/base/rescue.sparc: revision 1.4
	distrib/sets/lists/base/rescue.shark: revision 1.3
	distrib/sets/lists/base/rescue.vax: revision 1.3
	distrib/sets/lists/base/rescue.i386: revision 1.4
Mark /rescue/ldconfig as 'pic' only to enable building static releases (NOPIC=).
Only MKX11=no tested.
Pull up following revision(s) (requested by maxv in ticket #1050):
	sys/ufs/chfs/chfs_vfsops.c: revision 1.11
	sys/fs/unionfs/unionfs_vfsops.c: revision 1.13
	sys/fs/nilfs/nilfs_vfsops.c: revision 1.16
	sys/ufs/mfs/mfs_vfsops.c: revision 1.107
	sys/fs/sysvbfs/sysvbfs_vfsops.c: revision 1.43
	sys/ufs/ffs/ffs_vfsops.c: revision 1.297
	sys/kern/vfs_syscalls.c: revision 1.478
	sys/kern/vfs_syscalls.c: revision 1.479
	sys/fs/puffs/puffs_vfsops.c: revision 1.110
	sys/fs/cd9660/cd9660_vfsops.c: revision 1.84
	sys/nfs/nfs_vfsops.c: revision 1.227
	sys/fs/v7fs/v7fs_vfsops.c: revision 1.10
	sys/ufs/ext2fs/ext2fs_vfsops.c: revision 1.180
	sys/miscfs/umapfs/umap_vfsops.c: revision 1.92
	sys/fs/filecorefs/filecore_vfsops.c: revision 1.76
	sys/miscfs/nullfs/null_vfsops.c: revision 1.88
	sys/fs/ptyfs/ptyfs_vfsops.c: revision 1.50
	sys/coda/coda_vfsops.c: revision 1.81
	sys/ufs/lfs/lfs_vfsops.c: revision 1.321
	sys/fs/tmpfs/tmpfs_vfsops.c: revision 1.59
	sys/fs/hfs/hfs_vfsops.c: revision 1.31
	sys/miscfs/overlay/overlay_vfsops.c: revision 1.61
	sys/fs/union/union_vfsops.c: revision 1.72
	sys/fs/ntfs/ntfs_vfsops.c: revision 1.94
	sys/kern/vfs_syscalls.c: revision 1.480
	sys/fs/efs/efs_vfsops.c: revision 1.25
	sys/kern/vfs_syscalls.c: revision 1.482
	sys/fs/msdosfs/msdosfs_vfsops.c: revision 1.107
	external/cddl/osnet/dist/uts/common/fs/zfs/zfs_vfsops.c: revision 1.12
	sys/miscfs/procfs/procfs_vfsops.c: revision 1.91
	sys/fs/smbfs/smbfs_vfsops.c: revision 1.100
	sys/fs/adosfs/advfsops.c: revision 1.70
	sys/fs/udf/udf_vfsops.c: revision 1.67
Limit check for 'data_len'. Otherwise a (un)privileged user can easily
panic the system by passing a huge size.
ok christos@
An (un)privileged user can easily make the kernel dereference a NULL
pointer.
The kernel allows 'data' to be NULL; it's the fs's responsibility to
ensure that it isn't NULL (if the fs actually needs data).
ok christos@
Some fs's - like kernfs - set their vfs_min_mount_data to zero. Add a check
to prevent an (un)privileged user from requesting a zero-sized allocation
(and thus a panic).
This thing is totally buggy: 'data_len' is modified by the fs, so calling
kmem_free with it while its value has changed since the kmem_alloc is far
from being a good idea.
If the kernel figures out that something mismatches, it will panic
(typically with kernfs).
tickets 1048, 1049, 1050
Pull up following revision(s) (requested by maxv in ticket #1051):
	sys/compat/linux/common/linux_exec_elf32.c: revision 1.91 via patch
A specially-crafted binary could easily control a kernel array index.
Add some checks to ensure that nothing will be read outside the allocated
area. Rewrite the code so that we don't need to allocate the whole section.
Spotted by several developers, patch from chs@/enami@
ticket 1051