CVE-2024-35790

What it actually does

NULL pointer dereference in DisplayPort altmode driver when sysfs reads occur before typec_altmode_set_drvdata completes, dereferencing dp->hpd or dp->lock.

Why it matters to the business

Systems using USB Type-C DisplayPort altmode can experience crashes or denial of service during device probing, increasing downtime risk on affected kernels.

How an attack unfolds

An attacker with local access reads DisplayPort sysfs nodes during the brief window before driver data is initialized, triggering the NULL dereference and potential kernel panic.

How to fix it

Update to fixed kernel versions that register sysfs attributes via default device attribute group instead of manual creation; apply the referenced commit 18500fa313a9f1ee1be48aa111c0eeea001010fa or equivalent backports.

How to confirm the fix worked

Confirm sysfs nodes are created only after driver data initialization and test probe paths under concurrent sysfs access; verify absence of NULL dereference in hpd_show and pin_assignment_show.

Typical attack path

1. Gain local shell access on affected Linux system
2. Trigger or wait for DisplayPort altmode probe via USB-C connection
3. Read hpd_show or pin_assignment_show sysfs attributes before set_drvdata completes
4. Cause NULL dereference leading to kernel crash or instability

How to detect it

Review kernel logs for NULL pointer dereference traces referencing hpd_show, pin_assignment_show, or dp_altmode_probe; inspect for unexpected DisplayPort altmode sysfs activity during device attach.

• typec_altmode_set_drvdata
• hpd_show
• pin_assignment_show
• dp_altmode_probe

What your security team should do

• Prioritize kernel updates on systems exposing USB-C DisplayPort functionality
• Monitor for kernel oops or panic logs involving typec or displayport altmode
• Restrict unprivileged local access until patched