CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2023/01/26 00:44:31 Modified files: sys/uvm: uvm_map.h Log message: delete repeated word
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2023/01/26 00:32:40 Modified files: sys/dev/pci: if_ix.c if_ixl.c sys/net: if_ethersubr.c sys/netinet: if_ether.h Log message: backing "consolidate mbuf header parsing on device driver layer" easily repeatable ASSERT happens seconds after starting compiles over nfs.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: dera...@cvs.openbsd.org 2023/01/25 16:42:03 Modified files: sys/uvm: uvm_map.c Log message: In the previous commit, FIXPROT would upgrade a PROT_NONE mapping too far. Correct the logic, still blocking PROT_EXEC ok anton kettenis
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: k...@cvs.openbsd.org2023/01/25 14:44:09 Modified files: sbin/disklabel : editor.c Log message: Use getpartno() in editor_delete(), enhancing getpartno() to allow '*' to select all partitions when the action is 'delete'. No intentional functional change.
Re: CVS: cvs.openbsd.org: src
On Wed, 25 Jan 2023 12:06:50 -0700, Todd C. Miller wrote: > CVSROOT: /cvs > Module name: src > Changes by: mill...@cvs.openbsd.org 2023/01/25 12:06:50 > > Modified files: > usr.bin/pkg-config/OpenBSD: PkgConfig.pm > > Log message: > Fix CVE-2023-24056, unbounded variable expansion in pkg-config. > We now die with an error when trying to expand a variable that is > already longer than 64K. This was never a buffer overflow in our > pkg-config, but rather an unbounded memory allocation that would > eventually run up against resource limits. OK sthen@ jasper@ To avoid confusion on the matter, the CVE listed is for the C version of pkg-config, not our Perl version. This is not a security issue on OpenBSD because: 1) there is no buffer overflow in our perl version 2) only root can install .pc files anyway However, it still makes sense to limit the amount of variable expansion to avoid using excessive memory. The 64K limit was chosen to be compatible with the C version. - todd
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: mill...@cvs.openbsd.org 2023/01/25 12:06:50 Modified files: usr.bin/pkg-config/OpenBSD: PkgConfig.pm Log message: Fix CVE-2023-24056, unbounded variable expansion in pkg-config. We now die with an error when trying to expand a variable that is already longer than 64K. This was never a buffer overflow in our pkg-config, but rather an unbounded memory allocation that would eventually run up against resource limits. OK sthen@ jasper@
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: dera...@cvs.openbsd.org 2023/01/25 10:07:53 Modified files: . : innovations.html Log message: powerpc64 also heading towards xonly
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: bl...@cvs.openbsd.org 2023/01/25 08:43:39 Modified files: . : errata71.html errata72.html Log message: The vmm and vmd errata only affect the amd64 architecture. noticed by Georg Wulfes
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: chel...@cvs.openbsd.org 2023/01/25 07:14:39 Modified files: sys/arch/armv7/omap: gptimer.c Log message: gptimer(4): switch to clockintr - Remove custom clock interrupt scheduling code. - Remove local evcount structs. - Wire up gptimer_intrclock. - Switch stathz from 128 to hz - Switch profhz from 1024 to (stathz * 10). This change is untested. Nobody seems to have hardware that actually uses the gptimer(4) as an interrupt clock. If this patch doesn't work, the driver is probably not too distant from a working state. Compile-tested by jca@. Discussed with kettenis@, jca@, drahn@, patrick@, jsg@, and uwe@. Link: https://marc.info/?l=openbsd-tech=167451333419815=2 ok patrick@ kettenis@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: es...@cvs.openbsd.org 2023/01/25 06:25:07 Modified files: usr.sbin/pkg_add: pkg_create.1 usr.sbin/pkg_add/OpenBSD: PkgCreate.pm Log message: change naming convention for the lru "save history" cache, so that ports like "lang/chicken/core" do generate files like lang.chicken.core.lru instead of lang.chicken.core (which can create confusion in people's mind) do so transparently by reading the old file if need be, and removing it afterwards. Funny thing noticed by tb@ ok tb@, sthen@
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: a...@cvs.openbsd.org2023/01/25 03:53:15 Modified files: etc: rc Log message: Delete TAB only line.
CVS: cvs.openbsd.org: src
CVSROOT:/cvs Module name:src Changes by: kette...@cvs.openbsd.org2023/01/25 02:53:53 Modified files: sys/arch/powerpc64/include: cpufunc.h pte.h sys/arch/powerpc64/powerpc64: cpu.c pmap.c Log message: Implement execute-only mappings by using the Virtual Page Class Key Protection mechanism provided by modern POWER CPUs. This is implemented in a way data allows us to use the Data Address Compare mechanism that was available on older versions of the architecture if we ever add support for these older CPUs (e.g. the PowerPC 970 aka G5). Special thanks to gkoehler@ for spotting the bug in my initial implementation that made this not work at all. ok deraadt@, gkoehler@
CVS: cvs.openbsd.org: www
CVSROOT:/cvs Module name:www Changes by: clau...@cvs.openbsd.org 2023/01/25 01:53:24 Modified files: . : want.html Log message: I'm looking for CPU activation keys for an M10-1 server. To improve and speed up sparc64 work.
