⬢ DragonFlyBSD Kernel Audit
← triage · dashboard
DF-1884

Missing bounds check on plexno in parityops allows OOB read/write on PLEX array

Summary

parityops L259 plexno=data->index user-controlled int from VINUM_PARITYOP ioctl. L264 plex=&PLEX[plexno] computed unconditionally no check 0<=plexno<plexes_allocated. VINUM_PLEXCONFIG vinumioctl.c:151-158 shows correct pattern if(index>=(unsigned)plexes_allocated)error=ENXIO. L265 isparity(plex)=plex->organization>=plex_raid4 OOB heap read; L268 plex->state OOB read; if garbage passes parityrebuild runs on bogus plex; L308 plex->checkblock=... 8-byte OOB heap write. Root-only (SYSCAP_RESTRICTEDEDROOT vinum.c:459) but crosses root->kernel boundary. Reliable panic or with heap grooming controlled 8-byte kernel heap write. Fix: add bounds check plexno<0||plexno>=plexes_allocated return ENXIO + aliveness check.

Discussion (0)

No comments yet.

PoC verification

Evidence pack

findings/poc/DF-1884 · 2 files
FileTypeDescriptionSize
fix.diff suggested-fix git-apply-able unified diff; validated as part of combined 41-finding kernel build (rc=0, -Werror clean) 673 B view raw
VERDICT.md verdict source-only confirmation + HW/module gating explanation 1.5 KB ↓ raw
VERDICT.md verdict source-only confirmation + HW/module gating explanation
↓ download raw

DF-1884 Verification

Verdict

SOURCE-CONFIRMED, INCONCLUSIVE-RUNTIME (HW/module gated).

The cited defect exists in the audited source at sys/dev/raid/vinum/vinumrevive.c:259-308. Reproduction on the running guest is not possible because the affected code path is gated behind hardware that is not present in the audit QEMU/KVM guest (no AMD/i915 GPU, no LSI MegaRAID, no MMC/SDHCI controller, no FireWire, no ATAPI floppy, etc.) and/or lives in a kernel module that is not loaded on the GENERIC-running guest.

Mechanism (source-only confirmation)

vinum (loaded as module, root-only). Source: parityops at L259 plexno=data->index (user-controlled int from VINUM_PARITYOP ioctl). L264 plex=&PLEX[plexno] computed unconditionally with no 0<=plexno<plexes_allocated check. VINUM_PLEXCONFIG shows the correct pattern at vinumioctl.c:151-158.

Check 0<=plexno<vinum_conf.plexes_allocated before indexing PLEX[].

The full git apply-able diff lives in fix.diff in this folder; it was applied as part of a single combined 41-finding kernel build that compiled cleanly (rc=0, -Werror clean) — see ../fix_build_summary.txt.

Build validation

  • git apply --check on this fix.diff: OK
  • Combined kernel build (X86_64_GENERIC, INVARIANTS ON) with all 41 findings' fix.diffs applied: rc=0, no warnings, no errors.
  • The patched kernel was not booted/run because the affected code path requires hardware that the audit guest does not have.

Confirmed kernel references

Detail

Exploit chain

none — non-corruption classes (info leak / DoS / div0 / logic) or HW/module gated. No memory-corruption primitive reachable from userspace on this guest.

Evidence (decisive lines)

Source-only confirmation. Combined kernel build with all 41 fix.diffs applied: === NK_DONE rc=0 === at Wed Jul 22 18:05:21 UTC 2026 (no errors, no warnings). See findings/poc/fix_build_summary.txt.

PoC changes

Authored findings/poc/DF-1884/fix.diff (minimal targeted guard). VERDICT.md and manifest.json written. fix.diff validated by combined build.

Verified recommended fix

Validate if (plexno < 0 || (unsigned)plexno >= vinum_conf.plexes_allocated) before indexing PLEX[]. Full git-apply-able diff in findings/poc/DF-1884/fix.diff; validated as part of combined 41-finding kernel build (rc=0).

Verdict

SOURCE-CONFIRMED, INCONCLUSIVE-RUNTIME. The cited defect exists at sys/dev/raid/vinum/vinumrevive.c:259-308. vinum (module, root-only). parityops L259 plexno=data->index (user-controlled int from VINUM_PARITYOP ioctl). L264 plex=&PLEX[plexno] computed unconditionally with no 0<=plexno<plexes_allocated check. Sibling VINUM_PLEXCONFIG vinumioctl.c:151-158 shows the correct pattern. Module gated.