DF-4879 — unchecked drm_mode_create_standard_properties() in drm_mode_config_init()

File: sys/dev/drm/drm_mode_config.c (pass 2) Severity: Low (kernel NULL-deref panic, setup-gated) Status: source-proven, NOT PoC-verified on this guest (see VERDICT.md)

Summary

drm_mode_config_init() (sys/dev/drm/drm_mode_config.c:370) calls drm_mode_create_standard_properties(dev) at line 392 and discards its return value. That helper performs ~20 sequential allocations (drm_mode_config.c:217-355) and returns -ENOMEM on the first failure, leaving dev->mode_config.prop_fb_id / prop_crtc_id / prop_crtc_x..h / prop_active / prop_mode_id / prop_src_x..h / ... NULL (only the earlier ones are set).

Driver load then continues with half-initialized mode_config: drm_universal_plane_init() attaches those (possibly NULL) property pointers to every plane (drm_plane.c:262-275: drm_object_attach_property(&plane->base, config->prop_fb_id, 0) … — no NULL check), and drm_crtc_init_with_planes() attaches config->prop_active / config->prop_mode_id (drm_crtc.c:339-341).

Any later unprivileged ioctl that enumerates object properties — DRM_IOCTL_MODE_OBJ_GETPROPERTIES (drm_ioctl.c:678, DRM_UNLOCKED | DRM_RENDER_ALLOW, no auth) or DRM_IOCTL_MODE_GETCONNECTOR (drm_connector.c:1820) — walks the property array and dereferences prop->flags with no NULL check (drm_mode_object.c:341-346) → kernel NULL-deref → panic.

Preconditions / honesty

• The NULL-prop state requires -ENOMEM during driver load (root-triggered setup: kldload/boot-time memory pressure). i915, radeon and amdgpu all ignore the (void) init result today (intel_display.c:15342, radeon_display.c:1579, amdgpu_device.c:2604).
• Once the device is in that state, the panic trigger is a plain unprivileged ioctl on /dev/dri/card0 or /dev/dri/renderD128.
• Inherited from Linux (~4.19 drm_mode_config_init); upstream later fixed the class by moving to drmm_mode_config_init() which fails the whole device init. DragonFly port kept the void variant.
• Derefs are reads only (prop->flags, prop->base.id) — no write primitive, no kernel info leak (page-0 mapping would only read back attacker-crafted bytes). Impact ceiling: local DoS/panic.

Why untested here

The audit QEMU guest has no DRM device (/dev/dri absent — QEMU VGA, no i915/radeon/amdgpu binding), so DRM_IOCTL_MODE_OBJ_GETPROPERTIES cannot even be issued; and the ENOMEM-at-load precondition cannot be injected without kernel fault-injection knobs this guest does not have. The chain is verified line-by-line in source instead (VERDICT.md).

Contents

• VERDICT.md — full narrative with path:line evidence
• trigger.c — reference prober (would exercise the deref if a NULL-prop device existed; NOT runnable on this guest)
• build.sh — cc command for trigger.c
• fix.diff — propagate the failure (git-apply-able, never applied to sys/)
• verdict.json / manifest.json

DF-4879 VERDICT — drm_mode_config_init() ignores property-creation failure

Status: untested (source-proven; not runnable on this guest — no DRM device, no fault injection). Impact if manifested: local kernel panic (DoS), Low. Not memory corruption (read-only NULL derefs).

The defect (certain, source)

sys/dev/drm/drm_mode_config.c:392

void drm_mode_config_init(struct drm_device *dev)
{
        ...
        drm_mode_create_standard_properties(dev);   /* ret discarded */

drm_mode_create_standard_properties() (same file, 212-356) creates ~20 properties through drm_connector_create_standard_properties() (line 217) and then drm_property_create_{range,signed_range,object,bool} / drm_property_create calls (lines 221-353). Each returns NULL on allocation failure; the helper bails with -ENOMEM at the first NULL. On a mid-way failure the earlier dev->mode_config.*_property pointers are set and the rest stay NULL (struct comes from kzalloc'd drm_device).

The failure is invisible to all three in-tree callers, which treat init as infallible:

• sys/dev/drm/i915/intel_display.c:15342 — drm_mode_config_init(dev);
• sys/dev/drm/radeon/radeon_display.c:1579 — drm_mode_config_init(rdev->ddev);
• sys/dev/drm/amd/amdgpu/amdgpu_device.c:2604 — drm_mode_config_init(adev->ddev);

Propagation to NULL pointers stored in objects (certain)

drm_universal_plane_init() attaches the standard properties to every plane without NULL checks — sys/dev/drm/drm_plane.c:262-275:

        drm_object_attach_property(&plane->base, config->prop_fb_id, 0);
        drm_object_attach_property(&plane->base, config->prop_in_fence_fd, -1);
        drm_object_attach_property(&plane->base, config->prop_crtc_id, 0);
        drm_object_attach_property(&plane->base, config->prop_crtc_x, 0);
        ...

drm_object_attach_property() (drm_mode_object.c) performs no NULL validation. Atomic CRTC init attaches config->prop_active / config->prop_mode_id the same way (sys/dev/drm/drm_crtc.c:339-341). radeon marks mode_config_initialized = true unconditionally after init (radeon_display.c:1580), i.e. even a half-failed init proceeds to full registration (drm_modeset_register_all()).

Unprivileged sink (certain reachability once state exists)

drm_mode_object_get_properties() — sys/dev/drm/drm_mode_object.c:341-346:

        for (i = 0, count = 0; i < obj->properties->count; i++) {
                struct drm_property *prop = obj->properties->properties[i];
                ...
                if ((prop->flags & DRM_MODE_PROP_ATOMIC) && !atomic)   /* NULL deref */

Reached from: * DRM_IOCTL_MODE_OBJ_GETPROPERTIES → drm_mode_obj_get_properties_ioctl() (drm_mode_object.c:382-407), registered DRM_UNLOCKED|DRM_RENDER_ALLOW — no authentication, render-node allowed (drm_ioctl.c:678). * DRM_IOCTL_MODE_GETCONNECTOR → drm_connector.c:1820.

Trigger: open /dev/dri/card0 (or renderD128), GETPLANERESOURCES / GETRESOURCES to learn any plane/crtc/connector id, then MODE_OBJ_GETPROPERTIES on it with count_props>0 → prop->flags read at NULL+offset → kernel page fault → panic. All subsequent uses (__drm_object_property_get_value at 296-304 compares pointers, then prop->base.id at 353) are reads too — no write primitive, no kernel memory disclosure (if the attacker mapped page zero, the reads return their own bytes). DoS only.

Why not reproduced on the guest

1. Guest has no DRM device: /dev/dri does not exist (QEMU std VGA; no i915/radeon/amdgpu attaches), so the trigger ioctl has no target.
2. The setup precondition (-ENOMEM inside drm_mode_create_standard_properties during driver load) cannot be forced: the guest has no memory-allocation fault-injection knob, and the DRM drivers cannot be meaningfully loaded without their GPUs.
3. Verified live on guest dfbsd 6.5-DEVELOPMENT #0 Thu Jul 2 06:02:54 UTC 2026: ls -l /dev/dri/ → No such file or directory.

Classification: real defect, upstream-inherited, Low severity ("narrow trigger, requires already-privileged setup" per rubric). Fix is cheap and local (see fix.diff): propagate the error.

Fix validation

Not possible on this guest (same reasons as above) — fix_status: not_testable. The diff is compile-logic-equivalent to upstream's drmm_mode_config_init() handling (which fails device init when standard property creation fails).

Guest state notes (unrelated findings live-checked this run)

• /dev/nvmm does not exist on this guest: kldload nvmm loads nvmm.ko but MOD_LOAD fails with nvmm: cpu not supported (nvmm_dragonfly.c: nvmm_ident() == NULL — QEMU CPU exposes no SVM/VMX), module_register_init: MOD_LOAD (nvmm) error 45. When the backend does attach, the node is created root:nvmm 0640 (nvmm_dragonfly.c:392) → NVMM is not an unprivileged surface by default (only root or members of group nvmm gid 90 can open it).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.