Summary

intel_hpd_irq_storm_reenable_work() and i915_hpd_poll_init_work() dereference intel_connector->encoder->hpd_pin without first checking that encoder is non-NULL, unlike the sibling iterators in the same file (intel_hpd_irq_storm_disable at lines 179-181 and i915_hotplug_work_func at line 359). Non-MST connectors briefly have encoder == NULL between drm_connector_init() (which adds them to dev->mode_config.connector_list under connector_list_lock) and intel_connector_attach_encoder(). If either worker iterates the list during that window it takes a kernel NULL page fault → local DoS panic.

Root cause

Two sites in intel_hotplug.c lack the NULL guard that the file's other two iterators implement.

Site 1 — intel_hpd_irq_storm_reenable_work (intel_hotplug.c:227-233):

drm_for_each_connector_iter(connector, &conn_iter) {
    struct intel_connector *intel_connector = to_intel_connector(connector);
    /* Don't check MST ports, they don't have pins */
    if (!intel_connector->mst_port &&
        intel_connector->encoder->hpd_pin == pin) {   /* <-- NULL deref */

The MST filter excludes MST connectors (which never get intel_connector->encoder set via intel_connector_attach_encoder), but does NOT exclude non-MST connectors that are mid-init. The worker runs without dev->mode_config.mutex (only irq_lock is held, line 217) so it can race against connector registration.

Site 2 — i915_hpd_poll_init_work (intel_hotplug.c:555-566):

if (intel_connector->mst_port)
    continue;
if (!connector->polled && I915_HAS_HOTPLUG(dev_priv) &&
    intel_connector->encoder->hpd_pin > HPD_NONE) {   /* <-- NULL deref */

This one holds mode_config.mutex (line 550), but drm_connector_init / intel_connector_attach_encoder (e.g. in intel_hdmi_init_connector, intel_hdmi.c:2365 vs 2396) do NOT acquire mode_config.mutex, so the race window still exists.

The correct pattern, used by the file's other two iterators:

/* intel_hpd_irq_storm_disable, intel_hotplug.c:179-181 */
intel_encoder = intel_connector->encoder;
if (!intel_encoder)
    continue;
pin = intel_encoder->hpd_pin;

/* i915_hotplug_work_func, intel_hotplug.c:359 */
if (!intel_connector->encoder)
    continue;

Threat model & preconditions

• Attacker position: local user with physical access to the GPU's HPD signals (via USB-C dock / DP / HDMI adapter), OR root (to manipulate the HPD storm threshold via debugfs).
• Privileges gained or impact: kernel panic / local DoS. Page 0 is not mappable on DFly; the deref only reads an enum, not a function pointer, so no code-exec primitive was identified.
• Required config or capabilities: device i915 KMS loaded, Intel gen4+ GPU with has_hotplug=1, plus a window in which a non-MST connector is on connector_list with encoder == NULL (driver reload, MST topology reprobe racing a non-MST port, or runtime suspend/resume of the connector init path).
• Reachability:
• storm_reenable worker: scheduled HPD_STORM_REENABLE_DELAY = 2*60*1000 ms after a HPD storm is detected (intel_hotplug.c:114, 202). Triggerable by a faulty/malicious DP/HDMI/USB-C adapter, or via root writing to /sys/kernel/debug/dri/0/i915_hpd_storm_ctl to drop the threshold then issuing DRM ioctls that produce HPD pulses.
• poll_init worker: no storm precondition. Scheduled by intel_hpd_init (line 526) and intel_hpd_poll_init (line 614); runtime suspend/resume cycles exercise this path. Race is narrower because mode_config.mutex is held.

Proof of concept

PoC source: findings/poc/DF-1832/hpd_panic.c

Build & run

cc hpd_panic.c -o hpd_panic
# Drop the HPD storm threshold (requires root) and hammer DRM ioctls to
# generate HPD detect pulses. Then reload i915 inside the 2-minute
# HPD_STORM_REENABLE_DELAY window so the reenable worker races against
# intel_hdmi_init_connector.
sudo sh -c 'echo 1 > /sys/kernel/debug/dri/0/i915_hpd_storm_ctl'
sudo ./hpd_panic &
sudo kldunload i915 && kldload i915

Expected output

Fatal trap 12: page fault while in kernel mode
fault virtual address    = 0x<small offset>
instruction pointer      = 0x..<intel_hpd_irq_storm_reenable_work+...>
...
calltrap() at 0x...
intel_hpd_irq_storm_reenable_work+0x... at 0x...
process_one_work+0x... at 0x...

Impact

Local denial of service via kernel panic on DFly systems running i915 KMS. Triggerable by physical-access attackers (faulty USB-C dock), or root with debugfs write access to i915_hpd_storm_ctl. No confidentiality or integrity impact demonstrated; the dereference only reads an enum offset.

Recommended fix

Add the same NULL-encoder guard used by intel_hpd_irq_storm_disable and i915_hotplug_work_func. Two hunks, both pure defensive additions; no behavioural change for fully-initialised connectors.

--- a/sys/dev/drm/i915/intel_hotplug.c
+++ b/sys/dev/drm/i915/intel_hotplug.c
@@ -227,6 +227,9 @@ static void intel_hpd_irq_storm_reenable_work(struct work_struct *work)
        drm_connector_list_iter_begin(dev, &conn_iter);
        drm_for_each_connector_iter(connector, &conn_iter) {
            struct intel_connector *intel_connector = to_intel_connector(connector);
+
+           if (!intel_connector->encoder)
+               continue;
            /* Don't check MST ports, they don't have pins */
            if (!intel_connector->mst_port &&
                intel_connector->encoder->hpd_pin == pin) {
--- a/sys/dev/drm/i915/intel_hotplug.c
+++ b/sys/dev/drm/i915/intel_hotplug.c
@@ -560,6 +560,9 @@ static void i915_hpd_poll_init_work(struct work_struct *work)
        if (intel_connector->mst_port)
            continue;

+       if (!intel_connector->encoder)
+           continue;
+
        if (!connector->polled && I915_HAS_HOTPLUG(dev_priv) &&
            intel_connector->encoder->hpd_pin > HPD_NONE) {

References

• Sibling NULL-guard pattern in same file: intel_hotplug.c:179-181, 359.
• Window source: drm_connector_init adds to connector_list (drm_connector.c:257-260) before intel_connector_attach_encoder runs (intel_display.c:16224-16228).
• Upstream Linux has the same code shape; this is a long-standing latent defect shared with the i915 driver.

Timeline

• 2026-07-20 Discovered during automated audit.
• 2026-07-20 Reported to DragonFlyBSD security contact (pending).