• File: sys/dev/disk/sili/sili_attach.c
• Lines: 375–379
• Severity: Info
• CVSS 3.1: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U:C:N/I:N/A:N
• CWE: CWE-416 Use After Free
• Confidence: certain
• Status: new

Summary

In sili_pci_detach, after releasing the sc->sc_pregs memory resource via bus_release_resource, the cleanup line nulls sc->sc_regs a second time instead of sc->sc_pregs.

The immediately preceding block already set sc->sc_regs = NULL (sili_attach.c:373), so sc->sc_pregs is left holding a dangling pointer to a freed bus resource.

This is a latent code defect / hardening gap with no demonstrated exploitation path: detach is only reachable via kldunload (root/loader) and the dangling pointer is overwritten on any subsequent re-attach before it could be dereferenced.

Root cause

sili_attach.c:375-379:

if (sc->sc_pregs) {
    bus_release_resource(dev, SYS_RES_MEMORY,
                         sc->sc_rid_pregs, sc->sc_pregs);
    sc->sc_regs = NULL;     /* <-- should be sc->sc_pregs = NULL */
}

This is a copy-paste of the sc_regs block at sili_attach.c:370-374 where the assignment was not updated for the sc_pregs field.

The resource itself is correctly released (the bus_release_resource call uses sc->sc_pregs and sc->sc_rid_pregs); only the subsequent pointer invalidation targets the wrong field.

Contrast with the symmetric, correct handling of sc_irq (sili_attach.c:362-366), sc_regs (sili_attach.c:370-374), sc_tag_prbs (sili_attach.c:381-384), and sc_tag_data (sili_attach.c:385-388), all of which null their own field after release.

Threat model

Attacker position: must already be root (or the boot loader) to trigger module detach via kldunload/devctl; there is no unprivileged or remote vector into this code path.

Impact: none demonstrated.

The dangling sc_pregs pointer is not dereferenced anywhere between sili_pci_detach returning and the softc being freed by newbus, and any later sili_pci_attach overwrites sc_pregs unconditionally at sili_attach.c:171-172 before it can be read.

A hypothetical future code change that re-checked sc->sc_pregs != NULL between detach and softc free, or that re-entered sili_pci_detach without the sili_dragonfly.c:128-131 sc_ad=NULL guard, could turn this into a use-after-free / double bus_release_resource on the port-register BAR.

Proof of concept

No working exploit. To demonstrate the latent hazard (not a security impact), as root on a host with a SiI 3132/3124 controller present:

kldunload sili; kldload sili

…and instrument sili_pci_detach with a kprintf of sc->sc_pregs after line 378; observe it is non-NULL despite bus_release_resource having just freed the resource.

A second forced detach that bypassed the sc_ad guard (e.g., a future buggy caller) would then call bus_release_resource on the stale pointer and trigger a double-free in the rman/resource code.

Reproduction is not possible from an unprivileged context.

Recommended fix

Null the correct field.

--- a/sys/dev/disk/sili/sili_attach.c
+++ b/sys/dev/disk/sili/sili_attach.c
@@ -376,7 +376,7 @@
        bus_release_resource(dev, SYS_RES_MEMORY,
                     sc->sc_rid_pregs, sc->sc_pregs);
-       sc->sc_regs = NULL;
+       sc->sc_pregs = NULL;
    }

    if (sc->sc_tag_prbs) {

This makes the sc_pregs cleanup symmetric with sc_regs/sc_irq/sc_tag_* and eliminates the dangling pointer.

References

• sys/dev/disk/sili/sili_attach.c:375-379 — the typo (nulls wrong field after release)
• sys/dev/disk/sili/sili_attach.c:370-374 — the preceding sc_regs block it was copied from
• sys/dev/disk/sili/sili_attach.c:362-366,381-388 — sibling fields that null correctly
• sys/dev/disk/sili/sili_attach.c:171-172 — sc_pregs is unconditionally overwritten on re-attach