CVE-2026-98998 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: th1520-dw-hdmi: Fix remove() callback
This driver stores struct th1520_hdmi * in platform drvdata, but th1520_dw_hdmi_remove() was reading it back as struct dw_hdmi * and passing it to dw_hdmi_remove(), so teardown runs on the wrong pointer.
Retrieve struct th1520_hdmi * from platform drvdata and pass hdmi->dw_hdmi to dw_hdmi_remove().
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The Linux kernel driver for the TH1520 DisplayPort-to-HDMI bridge contains a critical type mismatch in its device removal callback, specifically within the th1520_dw_hdmi_remove function. This vulnerability stems from an incorrect casting of data retrieved from the platform device's drvdata field. The driver correctly stores a pointer to struct th1520_hdmi during initialization, which is a composite structure that typically encapsulates or contains a reference to the underlying dw_hdmi core structure. However, when the system initiates the unloading process for this kernel module, the remove callback erroneously retrieves this drvdata and casts it directly as a pointer to struct dw_hdmi instead of the correct struct th1520_hdmi type. This fundamental error in data typing leads to a severe memory safety violation where the teardown logic operates on an incorrectly interpreted memory address rather than the intended object instance.
The operational impact of this flaw is significant, particularly during module unloading or system shutdown sequences when resources are being released. Because the remove function passes the misinterpreted pointer directly to dw_hdmi_remove(), the kernel attempts to access members and perform cleanup operations based on the layout of struct dw_hdmi rather than struct th1520_hdmi. Depending on the relative sizes and memory layouts of these two structures, this can result in reading out-of-bounds memory, corrupting heap metadata, or triggering a null pointer dereference if the offset calculation fails to align with valid data regions. Such errors typically manifest as kernel panics, system crashes, or unpredictable behavior that compromises system stability. In worst-case scenarios involving exploitable memory corruption patterns, this could potentially be leveraged by local attackers to escalate privileges or cause denial of service conditions against critical display subsystem components.
From a vulnerability classification perspective, this issue aligns with CWE-823, which covers the use of pointers to incorrect types, and more broadly falls under CWE-119, representing improper restriction of operations within memory boundaries due to type confusion leading to out-of-bounds access or corruption. In terms of attack vector mapping according to MITRE ATT&CK techniques, this defect relates to T1055, specifically Process Injection via Memory Corruption, although in the context of kernel drivers it primarily serves as a stability and integrity flaw rather than an active exploitation path for remote code execution unless combined with other vulnerabilities. The root cause is a classic programming error where the developer failed to maintain type consistency between storage retrieval and usage, ignoring the structural hierarchy that defines how platform driver data should be accessed safely through proper casting or member accessors.
To mitigate this vulnerability, developers must ensure strict adherence to correct pointer casting conventions when interacting with platform device drvdata fields. The fix involves retrieving the original struct th1520_hdmi * from the drvdata and then explicitly accessing the embedded dw_hdmi structure via its designated member variable before passing it to the generic removal function. This ensures that memory offsets are calculated correctly relative to the actual allocated object base address rather than an assumed or incorrect type boundary. Additionally, implementing static analysis tools capable of detecting type mismatches in pointer casts during compilation can help prevent similar issues across other kernel drivers. Regular code reviews focusing on platform driver lifecycle management and strict typing practices further reduce the risk of such memory safety violations persisting in production kernels.