Summary

sil164_detect() declares u8 reg9; uninitialized, calls sil164_readb(dvo, SIL164_REG9, &reg9) without checking the boolean return, then tests (reg9 & SIL164_9_HTPLG). On any I2C transfer failure the function reads an uninitialized stack byte and returns a connector status derived from it. This is an inconsistency with sil164_dpms (dvo_sil164.c:216-218) and sil164_get_hw_state (dvo_sil164.c:234-236), both of which correctly check the return value and bail out. No memory-corruption or privilege impact; at most a misreported connector status (and, in theory, a 1-bit stale-stack signal) gated on an I2C hardware fault.

Root cause

• dvo_sil164.c:176 declares u8 reg9; with no initializer.
• dvo_sil164.c:178 calls sil164_readb(dvo, SIL164_REG9, &reg9); and discards the return value. sil164_readb (dvo_sil164.c:68-103) only writes *ch on the success path (line 94); on failure (i2c_transfer != 2) it returns false and leaves *ch untouched.
• dvo_sil164.c:180 then evaluates reg9 & SIL164_9_HTPLG on the uninitialized byte.

Contrast with the correct pattern at dvo_sil164.c:216-218 (ret = sil164_readb(...); if (ret == false) return;) and dvo_sil164.c:234-236.

Threat model & preconditions

• Attacker position: unprivileged local user holding /dev/drm access.
• Privileges gained or impact: none — at most a misreported connector status. No memory corruption, no privilege change, no meaningful info disclosure (1 noisy bit of a recent call frame, not secrets/key material).
• Required config or capabilities: an I2C transfer to the Sil164 chip that fails (hardware fault, disconnected/transiently-unresponsive chip, or an attacker who can influence the I2C bus — which needs physical access or root).
• Reachability: DRM connector-probe ioctl path: intel_dvo_detect (intel_dvo.c:298-305) → dev_ops->detect → sil164_detect, invoked through drm_helper_probe_single_connector_modes (intel_dvo.c:348).

Proof of concept

Not a memory-corruption primitive; no exploit chain is possible. To demonstrate the defect (logic only):

1. Build the standard i915-equipped DragonFlyBSD kernel.
2. Arrange for the DVO I2C read to fail (e.g. on hardware where the Sil164 is absent/broken, or by instrumenting i2c_transfer to return <2 once).
3. Issue DRM_IOCTL_MODE_GETCONNECTOR / force a connector probe from an unprivileged process via libdrm: drmModeGetConnector(...).
4. Observe that the returned connector status flips between connected/disconnected nondeterministically based on stack residue rather than on the HTPLG bit — proving the uninitialized read.

This is a logic/robustness demonstration only; there is no path to code execution, privilege escalation, or kernel memory disclosure.

Impact

Pure correctness/robustness defect with negligible security consequence.

Recommended fix

Check the sil164_readb return value and propagate failure as connector_status_unknown, matching the bail-out pattern already used in sil164_dpms and sil164_get_hw_state.

--- a/sys/dev/drm/i915/dvo_sil164.c
+++ b/sys/dev/drm/i915/dvo_sil164.c
@@ -174,7 +174,9 @@ static enum drm_connector_status sil164_detect(struct intel_dvo_device *dvo)
 {
    u8 reg9;

-   sil164_readb(dvo, SIL164_REG9, &reg9);
+   if (!sil164_readb(dvo, SIL164_REG9, &reg9))
+       return connector_status_unknown;

    if (reg9 & SIL164_9_HTPLG)
        return connector_status_connected;

References

• sys/dev/drm/i915/dvo_sil164.c:216-218,234-236 — siblings that correctly check the return.

Timeline

• 2026-07-25 Discovered during automated audit.
• 2026-07-25 Reported to DragonFlyBSD security contact.