MFHead @r350386

Sponsored by: The FreeBSD Foundation

Check and avoid overflow when incrementing fp->f_count in
fget_unlocked() and fhold().

On sufficiently large machine, f_count can be legitimately very large,
e.g. malicious code can dup same fd up t

Check and avoid overflow when incrementing fp->f_count in
fget_unlocked() and fhold().

On sufficiently large machine, f_count can be legitimately very large,
e.g. malicious code can dup same fd up to the per-process
filedescriptors limit, and then fork as much as it can.
On some smaller machine, I see
kern.maxfilesperproc: 939132
kern.maxprocperuid: 34203
which already overflows u_int. More, the malicious code can create
transient references by sending fds over unix sockets.

I realized that this check is missed after reading
https://secfault-security.com/blog/FreeBSD-SA-1902.fd.html

Reviewed by: markj (previous version), mjg
Tested by: pho (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D20947

show more ...

Use a consistent snapshot of the fd's rights in fget_mmap().

fget_mmap() translates rights on the descriptor to a VM protection
mask. It was doing so without holding any locks on the descriptor
tab

Use a consistent snapshot of the fd's rights in fget_mmap().

fget_mmap() translates rights on the descriptor to a VM protection
mask. It was doing so without holding any locks on the descriptor
table, so a writer could simultaneously be modifying those rights.
Such a situation would be detected using a sequence counter, but
not before an inconsistency could trigger assertion failures in
the capability code.

Fix the problem by copying the fd's rights to a structure on the stack,
and perform the translation only once we know that that snapshot is
consistent.

Reported by: syzbot+ae359438769fda1840f8@syzkaller.appspotmail.com
Reviewed by: brooks, mjg
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D20800

show more ...

MFHead @349476

Sponsored by: The FreeBSD Foundation

fcntl: fix overflow when setting F_READAHEAD

VOP_READ and VOP_WRITE take the seqcount in blocks in a 16-bit field.
However, fcntl allows you to set the seqcount in bytes to any nonnegative
31-bit va

fcntl: fix overflow when setting F_READAHEAD

VOP_READ and VOP_WRITE take the seqcount in blocks in a 16-bit field.
However, fcntl allows you to set the seqcount in bytes to any nonnegative
31-bit value. The result can be a 16-bit overflow, which will be
sign-extended in functions like ffs_read. Fix this by sanitizing the
argument in kern_fcntl. As a matter of policy, limit to IO_SEQMAX rather
than INT16_MAX.

Also, fifos have overloaded the f_seqcount field for a completely different
purpose ever since r238936. Formalize that by using a union type.

Reviewed by: cem
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D20710

show more ...

MFHead @348740

Sponsored by: The FreeBSD Foundation

Make pack_kinfo() available for external callers.

Reviewed by: jilles, tmunro
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D20258

MFHead@r345677

Reject F_SETLK_REMOTE commands when sysid == 0.

A sysid of 0 denotes the local system, and some handlers for remote
locking commands do not attempt to deal with local locks. Note that
F_SETLK_REMOT

Reject F_SETLK_REMOTE commands when sysid == 0.

A sysid of 0 denotes the local system, and some handlers for remote
locking commands do not attempt to deal with local locks. Note that
F_SETLK_REMOTE is only available to privileged users as it is intended
to be used as a testing interface.

Reviewed by: kib
Reported by: syzbot+9c457a6ae014a3281eb8@syzkaller.appspotmail.com
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19702

show more ...

MFHead@r345275

MFhead@r344786

Merge ^/head r344549 through r344775.

Rename seq to seqc to avoid namespace clashes with Linux

Linux generates the content of procfs files using a mechanism prefixed with
seq_*. This in particular came up with recent gcov import.

Spons

Rename seq to seqc to avoid namespace clashes with Linux

Linux generates the content of procfs files using a mechanism prefixed with
seq_*. This in particular came up with recent gcov import.

Sponsored by: The FreeBSD Foundation

show more ...

MFhead@r344527

Merge ^/head r344178 through r344512.

Change seq_read to seq_load to avoid namespace conflicts with lkpi

MFC after: 1 week
Sponsored by: iX Systems

Remove an obsolete comment.

MFC after: 3 days

vfs: mostly depessimize NDINIT_ALL

1) filecaps_init was unnecesarily a function call
2) an asignment at the end was preventing tail calling of cap_rights_init

Sponsored by: The FreeBSD Foundation

fd: dedup code in sys_getdtablesize

Sponsored by: The FreeBSD Foundation

fd: tidy up closing a fd

- avoid a call to knote_close in the common case
- annotate mqueue as unlikely

Sponsored by: The FreeBSD Foundation

fd: stop looking for exact freefile after allocation

If a lower fd is closed later, the lookup goes to waste. Allocation
always performs the lookup anyway.

Sponsored by: The FreeBSD Foundation

Merge ^/head r340918 through r341763.

fd: use racct_set_unlocked

Sponsored by: The FreeBSD Foundation

fd: try do less work with the lock in dup

Sponsored by: The FreeBSD Foundation

fd: unify fd range check across the routines

While here annotate out of range as unlikely.

Sponsored by: The FreeBSD Foundation