CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: an...@cvs.openbsd.org 2022/06/01 23:32:28 Modified files: sys/kern : vfs_lockf.c Log message: Stop hiding a few assertions behind the opt-in LOCKF_DIAGNOSTIC option. This code has already been exercised quite extensively by syzkaller and got decent test coverage.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: jmatt...@cvs.openbsd.org2022/06/01 21:09:39 Modified files: sys/arch/arm64/conf: GENERIC RAMDISK Log message: enable aq(4) on arm64 now that it works reasonably well
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: schwa...@cvs.openbsd.org2022/06/01 17:20:19 Modified files: usr.bin/mandoc : roff_escape.c Log message: Fix a buffer overrun in the roff(7) escape sequence parser that could be triggered by macro arguments ending in double backslashes, for example if people wrote .Sq "\\" instead of the correct .Sq "\e". The bug was hard to find because it caused a segfault only very rarely, according to my measurements with a probability of less than one permille. I'm sorry that the first one to hit the bug was an arm64 release build run by deraadt@. Thanks to bluhm@ for providing access to an arm64 machine for debugging purposes. In the end, the bug turned out to be architecture-independent. The reason for the bug was that i assumed an invariant that does not exist. The function roff_parse_comment() is very careful to make sure that the input buffer does not end in an escape character before passing it on, so i assumed this is still true when reaching roff_expand() immediately afterwards. But roff_expand() can also be reached from roff_getarg(), in which case there *can* be a lone escape character at the end of the buffer in case copy mode processing found and converted a double backslash. Fix this by handling a trailing escape character correctly in the function roff_escape(). The lesson here probably is to refrain from assuming an invariant unless verifying that the invariant actually holds is reasonably simple. In some cases, in particular for invariants that are important but not simple, it might also make sense to assert(3) rather than just assume the invariant. An assertion failure is so much better than a buffer overrun...
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2022/06/01 11:47:18 Modified files: sys/arch/amd64/amd64: pmap.c vmm.c sys/arch/amd64/include: pmap.h Log message: change amd64 pmap_convert to return void There are no other return options, so adjust function signature to void. This also allows for cleaning up its usage in vmm(4) in the vm pmap initialization logic. ok mlarkin@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: sas...@cvs.openbsd.org 2022/06/01 11:34:13 Modified files: sys/net: if_veb.c Log message: callers to pf(4) must continue to run with packet as returned by firewall. OK dlg@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2022/06/01 11:16:00 Modified files: sys/arch/i386/include: pmap.h Log message: remove unused pmap_convert prototype from i386 Leftover lint from early days of vmm(4). ok mlarkin@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: n...@cvs.openbsd.org2022/06/01 09:43:22 Modified files: usr.bin/tmux : tty-keys.c Log message: If escape-time is 0, force to 1 instead - not waiting at all is asking for problems on some platforms.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2022/06/01 08:48:53 Modified files: usr.sbin/rpki-client: main.c Log message: Remove a confusing comment that has been stale since e2k19 (r1.26).
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2022/06/01 08:21:50 Modified files: regress/sys/kern/flock: Makefile flock.c Log message: Add a regress test for the end of lock range ambiguity bug.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2022/06/01 08:18:43 Modified files: sys/kern : vfs_lockf.c Log message: Fix ambiguity with lock range end When the user requests a lock range that ends at LLONG_MAX, replace the end point with the special EOF value -1. This avoids ambiguity with lf_end in lf_split(). The ambiguity could result in a broken data structure. This change is visible to userspace in a corner case. When a lock range has been requested with an end point at absolute position LLONG_MAX, fcntl(F_GETLK) returns l_len == 0, instead of a positive value, for that range. This seems consistent with FreeBSD and Linux. OK anton@ Reported-by: syzbot+c93afea6c27a3fa3a...@syzkaller.appspotmail.com
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: v...@cvs.openbsd.org2022/06/01 08:16:28 Modified files: sys/kern : vfs_lockf.c Log message: Fix lock range start when l_whence == SEEK_END and l_len < 0. OK anton@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2022/06/01 04:59:21 Modified files: usr.sbin/rpki-client: extern.h rsc.c Log message: Limit the number of RSC checklist FileNameAndHash entries the same way as mft FileAndHash entries are checked. ok claudio job
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: t...@cvs.openbsd.org2022/06/01 04:58:34 Modified files: usr.sbin/rpki-client: mft.c Log message: Fix off-by-one in MAX_MANIFEST_ENTRIES check ok claudio job
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2022/06/01 02:19:15 Modified files: sys/dev/fdt: if_mvneta.c Log message: shrink dmesg output by printing the ethernet address on the attach line.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2022/06/01 00:33:46 Modified files: sys/dev/fdt: if_mvneta.c Log message: mark the mvneta interrupt handler as mpsafe. link state changes still take the kernel lock, but packet processing is unlocked now.
