CVE-2022-50412 in Linux
Summary
by MITRE • 09/18/2025
In the Linux kernel, the following vulnerability has been resolved:
drm: bridge: adv7511: unregister cec i2c device after cec adapter
cec_unregister_adapter() assumes that the underlying adapter ops are callable. For example, if the CEC adapter currently has a valid physical address, then the unregistration procedure will invalidate the physical address by setting it to f.f.f.f. Whence the following kernel oops observed after removing the adv7511 module:
Unable to handle kernel execution of user memory at virtual address 0000000000000000 Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP
Call trace: 0x0 adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511]
cec_adap_unconfigure+0x44/0x90 [cec]
__cec_s_phys_addr.part.0+0x68/0x230 [cec]
__cec_s_phys_addr+0x40/0x50 [cec]
cec_unregister_adapter+0xb4/0x118 [cec]
adv7511_remove+0x60/0x90 [adv7511]
i2c_device_remove+0x34/0xe0 device_release_driver_internal+0x114/0x1f0 driver_detach+0x54/0xe0 bus_remove_driver+0x60/0xd8 driver_unregister+0x34/0x60 i2c_del_driver+0x2c/0x68 adv7511_exit+0x1c/0x67c [adv7511]
__arm64_sys_delete_module+0x154/0x288 invoke_syscall+0x48/0x100 el0_svc_common.constprop.0+0x48/0xe8 do_el0_svc+0x28/0x88 el0_svc+0x1c/0x50 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x15c/0x160 Code: bad PC value ---[ end trace 0000000000000000 ]---
Protect against this scenario by unregistering i2c_cec after unregistering the CEC adapter. Duly disable the CEC clock afterwards too.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 12/12/2025
The vulnerability described in CVE-2022-50412 affects the Linux kernel's display subsystem, specifically within the advanced video processing pipeline involving the adv7511 bridge driver and CEC (Consumer Electronics Control) communication protocols. This issue manifests as a kernel oops during module removal operations, representing a critical flaw in the kernel's device management and cleanup procedures. The problem occurs when the adv7511 module is unloaded, triggering a sequence of operations that leads to memory access violations and system instability.
The technical root cause stems from improper ordering of cleanup operations within the driver's removal procedure. When cec_unregister_adapter() is called, it expects all underlying adapter operations to remain functional and accessible. However, during the removal of the adv7511 device, the i2c CEC device is still registered but in a state where its operations may have been partially invalidated or deallocated. This creates a scenario where the CEC adapter's unregistration process attempts to call methods on an i2c device that may no longer be properly initialized or accessible. The kernel's memory management system detects this invalid memory access pattern, resulting in a page fault that manifests as the observed oops condition.
The operational impact of this vulnerability extends beyond simple system crashes, potentially exposing systems to denial of service conditions and compromising the stability of embedded display environments. The vulnerability affects systems utilizing the adv7511 bridge chip in display configurations where CEC functionality is enabled, particularly in digital video processing applications that rely on proper device cleanup sequences. Attackers could potentially exploit this timing issue to cause system instability, though the direct exploitation pathway is limited to scenarios involving module removal operations and kernel-level device management.
This vulnerability aligns with CWE-1217, which addresses improper cleanup of resources during device removal, and relates to the broader ATT&CK technique of privilege escalation through kernel exploitation. The fix implemented addresses this by reordering the cleanup sequence to unregister the i2c CEC device before unregistering the CEC adapter itself, ensuring that all underlying resources remain accessible during the adapter's unregistration process. Additionally, the patch includes disabling the CEC clock after unregistering the adapter to prevent potential race conditions or lingering hardware references that could cause further issues during system operation.
The mitigation strategy involves updating to kernel versions that contain the patched implementation, where the proper ordering of device cleanup operations prevents the invalid memory access pattern. System administrators should prioritize applying these kernel updates, particularly in embedded systems or embedded display environments where the adv7511 bridge driver is actively used. The fix represents a defensive programming approach that ensures proper resource management during device removal, aligning with established kernel development practices for maintaining system stability during dynamic hardware configuration changes and module loading/unloading operations.