Errata

The public and security community closely scrutinizes each release of OpenBSD — again, there's nothing like claiming to be the best to make people try to knock you down. Bugs are frequently found after a release, but most of these bugs are trivial. If a bug is bad enough, the OpenBSD team will issue an errata. An errata is a fix for a serious bug that affects system security, reliability, or stability. (They may be issued for other reasons as well, but those are the most popular.) Errata are announced on the OpenBSD website, under the "Patches" link, and on the [e-mail] mailing list. I highly recommend subscribing to security-announce, so that you can be notified of errata immediately when they are available.

Evaluate each errata for its impact on your environment, and decide how quickly you need to apply: Do you need this fix as soon as possible, or can it wait for a maintenance window? If an errata comes out for a part of the system you are not using, it isn't necessary to rush the patch into production. On the other hand, if an errata applies directly to a system component you are using, you should apply it as soon as possible. If you're experiencing a problem that can be explained by a new errata, you certainly want to install it immediately if not sooner!

Here's a typical errata entry for OpenBSD 3.2 from the website:

 1 # 004: RELIABILITY FIX: November 6, 2002 2 A logic error in the pool kernel memory allocator could cause memory corruption in low-memory situations, causing the system to crash. 3 A source code patch exists which remedies the problem. 

Each errata has a 1 unique number within the release; the sample shown is errata #4 for OpenBSD 3.2. You'll also get a 2 brief description of the problem, and a 3 link to the patch that solves the issue. The information presented is generally enough to decide if you need to worry about the issue. Any errata that discusses system crashes should certainly be applied!

As I write this, OpenBSD 3.2 has four errata. Two are "reliability fixes," one of which is shown above. The other is a patch for OpenBSD systems configured as bridges that are also using PF scrubbing. The other two issues are security problems, one affecting the Sendmail restricted shell smrsh(8) and the other affecting the Kerberos administration daemon. If you're using these features, you need to apply the patches as soon as possible. If you're not using the features you should still apply the patches, but you don't need to rush them into place.

Errata should be applied in order, as a later errata can touch a piece of code affected by earlier errata. For example, if you have two errata that affect a single program, the second errata assumes that the first has been applied. You might get unpleasant results by applying errata out of order.

Errata Prerequisites

Before you can use any of the errata, you need to have both the kernel and the system source code available and ready for use on your system. If you read Chapter 5 and did as suggested, you have everything you need. If not, go back to Chapter 5 and install the source code for both the userland programs and the kernel on your system before trying to continue.

Applying Errata

Download the indicated source code patch for the errata and review it. Each errata has instructions at the top and actual code below. The instructions for kernel patches are usually the simplest, while patches for userland programs go into more depth. That's largely because the kernel has its own build process, which we cover in great depth in Chapter 12, and you're assumed to know it. Still, let's look at both. Here are the instructions for OpenBSD 3.2 errata #4.

 Apply by doing:      cd /usr/src      patch -p0 < 004_pool.patch And then rebuild your kernel. 

Let's see what happens. The only possible complication here is that you need to give the full path to the errata file. In this case, I've stored the patch under /home/mwlucas/errata.

 # patch -p0 < /home/mwlucas/errata/004_pool.patch Hmm...  Looks like a unified diff to me... The text leading up to this was: 

You'll then see the instructions for applying the patch, as patch(1) separates them out from actual code. The program will generate comparisons between the patch and the file(s) being patched and should eventually try to apply the patches directly to the source code. If the errata patch is successful, you will see something like this:

 Patching file sys/kern/subr_pool.c using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 1947. Hunk #3 succeeded at 1962. Hunk #4 succeeded at 1982. done # 

The patch examined four different parts of this file and was able to successfully alter each section of the file as it should. Your source code is now patched, and you can just rebuild the kernel.

Suppose something goes wrong? Here's what you look for to see if a patch fails:

 Hunk #1 succeeded at 1. Hunk #2 failed 1 at 2470. Hunk #3 succeeded at 2507. Hunk #4 succeeded at 2525. 1 out of 4 hunks failed--saving rejects to sys/net/if_bridge.c.rej 2 

Part of the patch 1 failed to apply, which means that either your patch was damaged during the download or the system source code on your system is damaged in some way. ^[1] More likely you didn't apply some previous errata, or someone has edited the source code. Patch(1) will tell you 2 where the failed piece of the patch is saved, so you can try to identify the problem.

Compiling Kernel Errata

If you're running in the default configuration, you just need to rebuild and reinstall the GENERIC kernel. The following commands will rebuild and reinstall a GENERIC kernel when you're logged in as root.

 # cd /sys/arch/i386/conf # config GENERIC # cd ../compile/GENERIC/ # make depend # make # cp /bsd /bsd.old # cp bsd /bsd # reboot 

We discuss compiling kernels from source in great detail in Chapter 12.

Compiling Userland Errata

Userland errata are slightly more difficult to compile than kernel errata, if only because the process is unique to each patch. Follow the instructions in the errata exactly, performing all tasks as root. The errata includes the exact commands to run. If you do not follow the instructions precisely, you will have problems afterward.

^[1]Both of these are very rare. To write this demonstration, I had to deliberately damage the patch file.