DF-4206 — vlv_dsi_init !fixed_mode error path kfrees a registered connector → dangling entry in mode_config list/IDR

File: sys/dev/drm/i915/vlv_dsi.c (pass 2) Severity: Low | Confidence: certain | CWE-416 (use after free) with CWE-401 (leak of connector->name / probed modes)

Build / Run

No build or run: Phase V skipped per contract (Low severity — the trigger is a drm_mode_duplicate allocation failure, i.e. kernel OOM at exactly this point in DSI init; the audit guest has no Intel GPU). The defect is provable from source.

The bug (path:line)

Execution order in vlv_dsi_init():

1. vlv_dsi.c:1839 drm_connector_init(dev, connector, ...) — registers the connector in the mode-object IDR (__drm_mode_object_add, drm_connector.c:208) and links it into dev->mode_config.connector_list (drm_connector.c:258).
2. vlv_dsi.c:1842 drm_connector_helper_add.
3. vlv_dsi.c:1848 intel_connector_attach_encoder.
4. vlv_dsi.c:1851 intel_dsi_vbt_get_modes() — duplicates vbt.lfp_lvds_vbt_mode (non-NULL is guaranteed on this path because intel_dsi_vbt_init() already dereferenced it, intel_dsi_vbt.c:544) and adds it as PREFERRED.
5. vlv_dsi.c:1852-1857 loop picks the PREFERRED mode into fixed_mode via a second drm_mode_duplicate.
6. vlv_dsi.c:1860-1863 — if fixed_mode == NULL (either duplicate failed: kernel OOM), goto err.
7. err label vlv_dsi.c:1875-1878: drm_encoder_cleanup(&intel_encoder->base); kfree(intel_dsi); kfree(intel_connector); — drm_connector_cleanup() is never called.

Consequences after step 7 (i915 driver init continues — a failed output does not abort the driver):

• dev->mode_config.connector_list still contains &connector->head which now points into freed memory (connector is embedded in the freed intel_connector). Every walker dereferences freed memory:
• DRM_IOCTL_MODE_GETRESOURCES (unprivileged) builds the connector id list from that list;
• DRM_IOCTL_MODE_GETCONNECTOR with the stale id resolves via drm_mode_object_find() → the IDR still holds the freed connector's id (only drm_connector_cleanup → drm_mode_object_unregister removes it, drm_connector.c:405) → returns the freed pointer → UAF read/write;
• drm_mode_config_cleanup() at unload does drm_connector_put() on each list entry → refcount write to freed memory → UAF write, guaranteed crash on unload.
• connector->name (kasprintf, drm_connector.c:236-239) and any probed modes leak ( drm_connector_cleanup would have freed both, drm_connector.c:392-396,406).

Trigger

drm_mode_duplicate → drm_mode_create → kzalloc failure: i.e. kernel memory exhaustion during DSI connector init (step 4 or step 5). All other goto err sites (:1811 host init, :1818 vbt init) are before drm_connector_init and are correctly handled.

Distinct from known findings

• DF-1446 covers the leak of dsi_hosts[port] (host + mipi_dsi_device) on the same err: label and on encoder teardown. This finding is a different object class (the drm_connector) and a different impact (use-after-free of globally-linked state vs. a pure allocation leak).

Fix

Dedicated err_connector label calling drm_connector_cleanup(connector) before the encoder cleanup — see fix.diff. drm_connector_cleanup (drm_connector.c:375-422) removes probed modes, unregisters the IDR object, frees the name, and list_dels from connector_list, so the dangling state is fully unwound.

Threat model / impact ceiling

Trigger is OOM-gated (not attacker-chosen timing without memory-pressure influence). After the trigger, ordinary unprivileged DRM ioctls walk/use the freed connector — a genuine UAF surface — but the object is a small driver-owned struct; practical exploitation is constrained. Treated as Low.

DF-4206 VERDICT

Status: untested (Phase V skipped — Low severity, OOM-gated trigger, no Intel GPU on the audit guest). Bug existence: certain, proven from source.

Reproduced?

Not on the guest: the QEMU audit VM has no Intel GPU (i915 never attaches, vlv_dsi_init unreachable), and the trigger requires a kzalloc failure inside drm_mode_duplicate during DSI connector init on real hardware. Source-level trace is complete and unambiguous (below), so bug existence is rated certain; runtime impact untested.

The chain, with citations

• Registration: drm_connector_init puts the connector in the mode-object IDR (drm_connector.c:208 __drm_mode_object_add) and on dev->mode_config.connector_list (drm_connector.c:258 list_add_tail).
• Faulting flow: vlv_dsi.c:1839 (init) → :1848 (attach encoder) → :1851 (intel_dsi_vbt_get_modes, adds PREFERRED mode) → :1852-1857 (second duplicate into fixed_mode) → :1860-1863 goto err when the duplicate fails → :1875-1878 kfree(intel_dsi); kfree(intel_connector) with no drm_connector_cleanup.
• Post-free use (unprivileged): MODE_GETRESOURCES walks connector_list; MODE_GETCONNECTOR resolves the stale IDR id (drm_mode_object_find); drm_mode_config_cleanup at unload does drm_connector_put on the freed entry (refcount write to freed memory).
• Secondary leaks on the same path: connector->name (drm_connector.c:236) and probed modes (drm_connector.c:392-396 would have freed them).

Impact ceiling

Use-after-free of a driver-owned intel_connector reachable through plain DRM ioctls after the OOM-gated trigger fires during attach; guaranteed crash at driver unload (drm_connector_put on freed memory). No escalation chain developed: the trigger cannot be scheduled by an unprivileged user, and the freed object is small driver state. Low severity.

Fix validation

Not performed on the guest (no hardware). By inspection, the err_connector label calling drm_connector_cleanup(connector) exactly undoes steps taken after :1839: IDR unregister (:405), name free (:406), probed-modes free (:392-393), list_del (:409) — leaving the earlier err sites (:1811, :1818) untouched and correct.

Relationship to DF-1446

DF-1446 (same label) is the dsi_hosts host/device leak — a CWE-401 resource leak. DF-4206 is the connector lifetime defect — CWE-416. Different object, different impact, complementary fix (fix.diff adds a label; DF-1446's fix adds dsi_hosts frees).

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.