OpenBSD Errata: September 27, 2021 (libressl)
An errata patch for LibreSSL has been released for OpenBSD 6.8 and OpenBSD 6.9. A stack overread could occur when checking X.509 name constraints. Binary updates for the amd64, i386 and arm64 platform are available via the syspatch utility. Source code patches can be found on the respective errata page: https://www.openbsd.org/errata68.html https://www.openbsd.org/errata69.html
OpenBSD Errata: September 27, 2021 (sshd)
An errata patch for sshd(8) has been released for OpenBSD 6.8 and OpenBSD 6.9. sshd(8) from OpenSSH 6.2 (OpenBSD 5.3) through 8.7 (OpenBSD 6.9) failed to correctly initialise supplemental groups when executing an AuthorizedKeysCommand or AuthorizedPrincipalsCommand, where a AuthorizedKeysCommandUser or AuthorizedPrincipalsCommandUser directive has been set to run the command as a different user. Instead these commands would inherit the groups that sshd(8) was started with. Depending on system configuration, inherited groups may allow AuthorizedKeysCommand/AuthorizedPrincipalsCommand helper programs to gain unintended privilege. Neither AuthorizedKeysCommand nor AuthorizedPrincipalsCommand are enabled by default in sshd_config(5). Binary updates for the amd64, i386 and arm64 platform are available via the syspatch utility. Source code patches can be found on the respective errata page: https://www.openbsd.org/errata68.html https://www.openbsd.org/errata69.html
Re: sigwaitinfo(2) and sigtimedwait(2)
> Date: Fri, 24 Sep 2021 19:36:21 +0200 > From: Rafael Sadowski > > I'm trying to port the more KDE stuff so my question is from porter > perspective. > > I need sigwaitinfo(2)/sigtimedwait(2) and I found both functions in > lib/libc/gen/sigwait.c with the comment "need kernel to fill in more > siginfo_t bits first". Is the comment still up to date? If no, is it > possible to unlock the functions? Still true. These functions are somewhat underspecified by POSIX so it isn't really obvious whatadditional bits need to be filled in. Having examples of code that use these interfaces from ports could help with that.
snmpd(8): Log correct engineid
ober_get_nstring writes a pointer to buf and does not overwrite the content of buf itself. So pushing an array in there will result in it only writing the pointer address to the array, which is not exactly what we want to show. I choose to go for sizeof, instead of using the define to be a little more on the safe side, but I didn't change SNMPD_MAXCONTEXNAMELEN to keep the diff small. OK? martijn@ Index: snmpe.c === RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v retrieving revision 1.76 diff -u -p -r1.76 snmpe.c --- snmpe.c 6 Sep 2021 13:32:18 - 1.76 +++ snmpe.c 26 Sep 2021 08:19:59 - @@ -237,7 +237,7 @@ snmpe_parse(struct snmp_message *msg) long longerrval, erridx; u_intclass; char*comn; - char*flagstr, *ctxname; + char*flagstr, *ctxname, *engineid; size_t len; struct sockaddr_storage *ss = &msg->sm_ss; struct ber_element *root = msg->sm_req; @@ -300,9 +300,12 @@ snmpe_parse(struct snmp_message *msg) } if (ober_scanf_elements(a, "{xxeS$}$", - &msg->sm_ctxengineid, &msg->sm_ctxengineid_len, - &ctxname, &len, &msg->sm_pdu) != 0) + &engineid, &msg->sm_ctxengineid_len, &ctxname, &len, + &msg->sm_pdu) != 0) goto parsefail; + if (msg->sm_ctxengineid_len > sizeof(msg->sm_ctxengineid)) + goto parsefail; + memcpy(msg->sm_ctxengineid, engineid, msg->sm_ctxengineid_len); if (len > SNMPD_MAXCONTEXNAMELEN) goto parsefail; memcpy(msg->sm_ctxname, ctxname, len);