Do sleeping malloc() and copyin() before checks within sys_semop().
Otherwise the semaphore id referenced by `semaptr' could be destroyed
or replaced during context switch.
ok cludwig
Do not cache format for status line because it stores various pointers
that might be stale, instead cache the cmd_find_state and rebuild the
formats every time they are needed. Reported by Marcel Partap in GitHub
isue 5065.
x509_purp: fix doc comment for check_ca()
This comment has gotten out of sync with reality. The "I don't know..."
fallback was removed and a special case for netscape CAs was added.
Sync from the manual and add some more details.
Pointed out by Maximilian Radoy in
https://github.com/libressl/portable/issues/1274
ok kenjiro
asr regress: workaround due to removal of . from the path
Since . is no longer part of the default path, . regress.subr no longer
works. Use ${PWD}.
With this, the regress appears to mostly work except for what looks like
ordering issues and of course it isn't using bsd.regress.mk. I leave the
former to the DNS experts and the latter to the regress experts if they're
interested.
make ifconfig build without trunklacp.h
The only used part of trunklacp.h in ifconfig is LACP_STATE_BITS.
Add it to if_trunk.h so trunklacp.h can be removed.
ok dlg@
Use unsigned int for the length variable when traversing the others array.
Doing this in all places now after fixing an overflow in attr_optadd().
OK tb@ deraadt@
A collection of AI-assisted reports come from Frank Denis, which says that
the YP getgrent code when doing YP operations has a group of buffer
mismanagement issues which in the reports are labelled 'high severity'.
This fixes the buffer checks.
The big question to ask is this: Is a malicious YP server going to
send you messages that exercise a buffer overflow codepath, or are
they going to send you perfectly correct messages containing wrong group members?
The old-school ypserv model was that you run ypserv on a "trusted network"
segment, which today is laughable but it matched operations in that era.
(Our) new operational model is that ypbind is reached with a custom system call
and provides trusted path to a an on-host ypserv, which is more likely to be
the ypldap(8) LDAP schema to YP protocol converter.
If a YP server is broken and sending bad messages, THIS code is the least
of your worries. High severity? No.
ok millert jmatthew
A collection of AI-assisted reports come from Frank Denis, which says that
the YP getpwent code when doing YP operations has a group of buffer
mismanagement issues which in the reports are labelled 'high severity'.
This fixes the buffer checks.
In reality, the memory being operated on is always a full page so the
overflow onto unmanagement memory is hard to see as a risk.
The big question to ask is this: Is a malicious YP server going to
send you messages that exercise a buffer overflow codepath, or are
they going to send you perfectly correct messages containing :0:0: ?
The old-school ypserv model was that you run ypserv on a "trusted network"
segment, which today is laughable but it matched operations in that era.
(Our) new operational model is that ypbind is reached with a custom system call
and provides trusted path to a an on-host ypserv, which is more likely to be
the ypldap(8) LDAP schema to YP protocol converter.
If a YP server is broken and sending bad messages, THIS code is the least
of your worries. High severity? No.
ok millert jmatthew
In session_graceful_restart() also arm the SessionDown timer
session_graceful_restart() does more or less the same as session_down()
and therefor needs to arm the SessionDown timer and on top of that
update stats.last_updown. The interval for the SessionDown timer needs
to depend on the graceful restart timer, since that one needs to fire
first.
OK tb@
Add checks for invalid dir count and max size for readdir/readdirplus.
A zero count or max size value is now rejected early instead of
relying on VOP_GETATTR to return an error. Also verify that the
max size after rounding up to a multiple of DIRBLKSIZ is positive.
A negative value would turn into a large allocation, causing the
malloc() to fail.
From an LLM bug report. With help from miod@ and kirill@.
from millert@
this is errata/7.7/041_nfs.patch.sig
