OpenBSD's October 2026 Big Fish Bug Explained: When a 16-Bit Counter Wraps

The program can free memory while someone is still using it. That is the lesson of the OpenBSD Big Fish bug, which Andrew Griffiths of the security firm Calif published on 16 October 2026.

Picture a hall with a door counter that only shows four digits. After 9,999 guests it rolls back to zero. The caretaker sees zero, thinks the hall is empty, and locks up with people still inside.

Where the picture breaks: the Big Fish counter does not roll to zero. It jumps to a negative number, and the kernel acts on that wrong number, not a caretaker.

Picture a common setup. A small hosting team runs a dozen OpenBSD 7.9 firewalls and four shared build servers. Forty customer developers have their own logins on the build servers. The setup is made up, but the bug is real.

The team has two questions. Which machines are exposed, and what must be patched today? This guide answers both, then shows engineers how to stop the same bug in their own code.

• Kernel: the core of the operating system. It controls memory and hardware, so whoever controls it has root, the master key.
• Local privilege escalation: a normal user on the machine turns themselves into root. The attacker needs a login or some code already running.
• Shared memory segment: one block of memory that several processes, meaning running programs, can see at once, like a shared whiteboard in an office.
• Fork: a process makes a copy of itself, called a child. Calif's write-up says repeated forks of a process with shared memory attached push the count up.
• Reference count: a number that tracks how many users hold an object. When it reaches zero, the object is freed.
• Use-after-free: code keeps using memory after it was freed and perhaps handed to something else.
• Integer overflow: a number grows past the largest value its type can hold and wraps round to a wrong value.
• Errata: OpenBSD's numbered fixes for one release, listed on a page per release, such as the 7.9 errata page.

It is a kernel bug in OpenBSD's System V shared memory code, the classic Unix way for processes to share memory. A counter called shm_nattch counts current attaches to a segment. Calif describes it as a signed 16-bit short, a C number type.

Calif traces that type roughly 37 years back, to the original BSD sources. The OpenBSD shmctl manual page, last changed on 2 September 2026, before the errata, lists shm_nattch as a short. We could not check whether the fixes changed the type, as of 19 October 2026.

Repeatedly forking a process that has shared memory attached could push the counter past 32,767. It then wrapped to a negative value. Calif says this overflow could lead to a use-after-free through a race condition, where the result depends on timing.

A race alone did not give root. Calif combined it with a separate out-of-bounds write in the kernel, a write past the end of a block of memory. Together they gave local root.

For the hosting team, the answer is quick. All 16 machines run OpenBSD 7.9, and none has the September errata yet.

The kernel keeps one attach count per segment. The shmat call maps a segment into a process's memory, and shmdt unmaps it. The shmctl manual page describes shm_nattch as the number of current attaches.

A segment marked for removal with IPC_RMID is destroyed only when no process uses it any more. So the count is the kernel's answer to one question: is anyone still here? On OpenBSD, new callers may even attach to a segment already marked for removal.

You can see these counts yourself. On OpenBSD, ipcs -mo lists active shared memory segments and, per its manual page, the number of processes attached to each. This shows use, not exposure. An attacker can create a segment of their own, so an empty list is no reason to skip the patch.

A signed 16-bit number holds values from -32,768 to 32,767. Add 1 to 32,767 and the bits roll over to -32,768. C has no built-in check that stops this, so someone has to write one.

Pause and predict: a count sits at 32,767 and one more process attaches. What number does the kernel see next?

Python's own integers never overflow, so the example below uses ctypes, Python's module for C number types, to copy a C short. The second function refuses the attach at the limit.

import ctypes

def unsafe_attach(count):
    return ctypes.c_int16(count + 1).value  # wraps like a C short

def safe_attach(count, limit=32_767):
    if count >= limit:
        raise OverflowError("attach limit reached, refusing new attach")
    return count + 1

count = 32_767  # one shared segment on a build server (made up)
print("unsafe:", unsafe_attach(count))  # prints -32768
try:
    safe_attach(count)
except OverflowError as err:
    print("safe:", err)

Run it with python3 and you get two lines. The first is unsafe: -32768. The second is safe: attach limit reached, refusing new attach. We ran it on Python 3.13.

What just happened? The unsafe version produced a count no real segment can have. The safe version refused the request instead. A refused request beats a wrong number.

Because code that uses a reference count frees memory based on the count, not on who really holds it. If the count says nobody is left, the memory can be released while processes still map it. Any later use touches memory that may now belong to something else.

Anyone running an unpatched OpenBSD 7.9 or 7.8 machine where an untrusted person can run code. The attacker needs a normal account or a running program first. Calif names only the 7.9 patches, but the 7.8 errata page lists matching fixes.

Only the two most recent releases get security fixes, according to the OpenBSD FAQ. As of 19 October 2026, until OpenBSD 8.0 ships, that means 7.9 and 7.8. Calif does not list affected versions, but older releases likely share the decades-old counter and get no errata, so upgrade them.

Shared machines come first

The four build servers are the worry. Forty outside developers run their own code there, so any one of them could try the local path to root.

Admin-only firewalls can wait for the next window

The 12 firewalls have only 3 admin logins. Nobody untrusted runs code on them, so the team schedules them for the next maintenance window, not today.

Install the errata for your release, then reboot into the patched kernel. On 7.9 that means 018 and 026; on 7.8 it means 054 and 062. Erratum 018 is listed as a reliability fix, and 026 as a security fix. Calif still names 018 among the Big Fish fixes, so never skip an erratum because of its label.

The errata pages also list two related System V fixes. On 7.9 they are 005 (16 July) and 029 (30 September); on 7.8 they are 041 and 065. Calif does not mention them, but syspatch installs them too.

1. 1

   Check each machine's release

   Run uname -r. It prints the release, such as 7.9. The team's list has 12 firewalls and 4 build servers, all on 7.9.

2. 2

   Read the errata page for that release

   Confirm 018 and 026 are listed for 7.9, or 054 and 062 for 7.8.

3. 3

   Patch shared machines first

   Start where untrusted users run code: the four build servers.

4. 4

   Run syspatch as root

   With no options, syspatch applies all missing patches. Its manual says patches are cumulative, so it cannot install only some of them. Full binary updates exist for the amd64, i386 and arm64 processor families. Elsewhere, build from the -stable branch, the release plus its errata, instead.

5. 5

   Reboot into the new kernel

   The running kernel stays the old, unpatched one until the machine restarts.

6. 6

   Verify and record

   Run syspatch -l, which lists installed patches, and look for 018 and 026 (054 and 062 on 7.8). Then run syspatch -c, which lists missing patches, and expect an empty list.

The 7.9 errata page says -stable is maintained for one year after release. Each errata entry also links a signed source patch with its own instructions.

Beginners can stop here. You know what broke, who is exposed and how to patch. The rest is for engineers who write or review low-level code.

Calif, which found both bugs, gives the mapping. It writes that the issues were addressed in errata 026 and 018, respectively. By that order, 026 fixed the counter bug and 018 the separate out-of-bounds write.

The errata titles do not spell out the link. Erratum 026 fixes a reference counting bug that could lead to use-after-free, which closely matches Calif's counter bug. Erratum 018 prevents integer overflow in shmat, the attach call.

Neither title names the out-of-bounds write, so that half of the mapping rests on Calif's word. We could not open the patch files to check it. Either way the action is the same: install both.

On 7.8, the 062 entry adds that the ipcs command stopped working after an ABI change, meaning a change to a binary interface programs rely on. If you rely on ipcs there, read that entry before patching.

Calif reached root with KARL, SMAP and SMEP all enabled, and without an information leak bug, one that reveals kernel memory such as addresses. These defences make attacks harder, but none of them fixes a wrong count.

KARL is OpenBSD's kernel relinking: it builds a freshly shuffled kernel at install, upgrade and boot, so function and data addresses change. SMEP stops the kernel running code from user-space memory. SMAP stops it reading or writing user-space memory except where it explicitly allows that.

Calif says its chain got past SMAP and SMEP by making its own user-space mapping accessible to the kernel. Allocators are the parts that hand out kernel memory. Calif says KARL shuffles the kernel binary, but the boot-time and best-fit allocators lack base address randomisation.

Because in C this wrap is not undefined behaviour, meaning code the C standard gives no meaning at all. The standard leaves the result to each compiler, and gcc and clang wrap it. The -fsanitize=undefined flag looks for undefined code only.

C first promotes the short to an int. Where an int is 32 bits, as on mainstream compilers, the addition itself cannot overflow.

The bug happens when the result is squeezed back into 16 bits. The clang documentation says issues caught by its implicit conversion checks are not undefined behaviour, and that the undefined group leaves them out.

int printf(const char *format, ...);

int main(void) {
    short nattch = 32767;   /* a 16-bit attach count at its maximum */
    nattch++;               /* one more attach */
    printf("after one more attach: %d\n", nattch);
    return 0;
}

We built this toy file, not kernel code, with gcc 13.3 and clang 18.1.3 on Linux. The table shows what each build did.

The -fsanitize-trap=all flag makes a failed check stop the program with a trap instruction, so no sanitizer runtime library is needed. The clang documentation calls these conversions often unintentional, not always, so review each report before changing code.

Give every lifetime counter a type wide enough that it cannot realistically fill, and still check its limit. When the limit is reached, refuse the new reference or stop the count at its maximum. Never let it wrap.

Saturation is a real design, not a thought experiment. The Linux kernel's refcount_t type pins the count at a saturated value on overflow, and its source comment says this avoids spurious use-after-free bugs.

Refusing is just as short in C. The gcc and clang builtin __builtin_add_overflow reports whether the result fits, so the function can refuse instead of storing a wrapped value.

int printf(const char *format, ...);

/* Refuse the increment instead of wrapping. */
static int attach(short *count) {
    short next;
    if (__builtin_add_overflow(*count, 1, &next))
        return -1;  /* refuse: real code returns an error code */
    *count = next;
    return 0;
}

int main(void) {
    short count = 32766;
    int rc = attach(&count);
    printf("first attach: rc=%d count=%d\n", rc, count);
    rc = attach(&count);
    printf("second attach: rc=%d count=%d\n", rc, count);
    return 0;
}

Built with gcc 13.3 or clang 18.1.3, it prints first attach: rc=0 count=32767, then second attach: rc=-1 count=32767. The second attach is refused, and the count never wraps.

Why was the counter only 16 bits wide?

Calif traces the short back to the original BSD sources. POSIX, the standard Unix interface, now names the type shmatt_t and requires an unsigned integer at least as large as unsigned short.

A signed short meets neither the unsigned rule nor the full range. Old types often linger because changing a public structure can break programs built against it.

What Calif suggests beyond the patch

Fuzzing throws huge numbers of random inputs and call sequences at code. Sanitizers add run-time checks that catch bad behaviour as it happens.

Calif suggested the array bounds sanitizer, a subset of the undefined behaviour sanitizer, to FreeBSD as a possible release-build defence. It privately reported 21 FreeBSD issues that this sanitizer would have caught.

Calif also suggests safe unlinking, a check on linked-list pointers before removing an item. It notes FreeBSD and NetBSD already do this in their list code. Its other proposals randomise allocator base addresses and the order of allocations.

Tell it as a story about object lifetimes and invariants, rules that must always hold. Use this frame.

1. 1

   Name the bug class

   An integer overflow in a reference count, which turns into a use-after-free.

2. 2

   State the invariant

   The count must always equal the real number of users. A signed 16-bit count broke this past 32,767.

3. 3

   Give the trigger at a high level

   Repeated forks of a process with shared memory attached kept raising the count until it wrapped.

4. 4

   Size the risk honestly

   Local only. With a separate out-of-bounds write, it reached root with KARL, SMAP and SMEP on. Shared machines matter most.

5. 5

   Describe fix and defence

   Install both errata and reboot. Use wide, checked counters, test with clang's implicit conversion checks, and fuzz rare states such as a count near its limit.