In the Linux kernel, the following vulnerability has been resolved:
media: cec: Serialize exclusive follower delivery
cec_receive_notify() reads the exclusive follower pointer without the
adapter lock. Serialize the no-follower check and message delivery
against mode changes and release.
CVSS Vector: CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.5
AV:A - cec_receive_notify() runs from cec_received_msg_ts() on HDMI-CEC frames a peer places on the shared CEC line. HDMI-CEC is a multi-drop bus among TVs, AVRs, streaming sticks, and conference or automotive HDMI sources, matching CAN/Bluetooth adjacent-segment scoring rather than Internet-routable Network.
AC:H - The use-after-free requires cec_release() to kfree the exclusive-follower cec_fh after the unlocked pointer load in cec_receive_notify(). A CEC peer can flood receive but cannot close that filehandle, so success depends on concurrent local teardown the attacker cannot initiate.
PR:N - HDMI-CEC has no authentication. Any device on the same CEC bus can emit frames that the adapter delivers into cec_received_msg_ts() with no Linux account, capability, or user-namespace check on the host.
UI:N - Once the adapter is configured and receiving, which is normal for TVs, Android HDMI-CEC, SBCs, and automotive head units that claim a logical address at boot, RX delivery and any concurrent follower close run without a mount, prompt, or other interactive victim step.
S:U - The use-after-free is of the kmalloc'd struct cec_fh inside the host kernel CEC core and does not cross a VM, IOMMU, or other separate security-authority boundary.
C:H - After cec_release() kfree()s the exclusive follower, cec_queue_msg_fh() still locks and walks lists on the dangling cec_fh. That kernel heap use-after-free enables disclosure of reused object contents.
I:H - cec_queue_msg_fh() writes the freed filehandle via mutex operations, list_add_tail of a new cec_msg_entry, and wake_up_interruptible, a heap use-after-free write and control-flow hijack primitive.
A:H - Using a freed cec_fh from the receive path causes a kernel oops or panic even when not fully exploited for code execution, taking down the host.
| Attack Vector |
Adjacent Network |
Scope |
Unchanged |
| Attack Complexity |
High |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:A - cec_receive_notify() runs from cec_received_msg_ts() on HDMI-CEC frames a peer places on the shared CEC line. HDMI-CEC is a multi-drop bus among TVs, AVRs, streaming sticks, and conference or automotive HDMI sources, matching CAN/Bluetooth adjacent-segment scoring rather than Internet-routable Network.
AC:H - The use-after-free requires cec_release() to kfree the exclusive-follower cec_fh after the unlocked pointer load in cec_receive_notify(). A CEC peer can flood receive but cannot close that filehandle, so success depends on concurrent local teardown the attacker cannot initiate.
PR:N - HDMI-CEC has no authentication. Any device on the same CEC bus can emit frames that the adapter delivers into cec_received_msg_ts() with no Linux account, capability, or user-namespace check on the host.
UI:N - Once the adapter is configured and receiving, which is normal for TVs, Android HDMI-CEC, SBCs, and automotive head units that claim a logical address at boot, RX delivery and any concurrent follower close run without a mount, prompt, or other interactive victim step.
S:U - The use-after-free is of the kmalloc'd struct cec_fh inside the host kernel CEC core and does not cross a VM, IOMMU, or other separate security-authority boundary.
C:H - After cec_release() kfree()s the exclusive follower, cec_queue_msg_fh() still locks and walks lists on the dangling cec_fh. That kernel heap use-after-free enables disclosure of reused object contents.
I:H - cec_queue_msg_fh() writes the freed filehandle via mutex operations, list_add_tail of a new cec_msg_entry, and wake_up_interruptible, a heap use-after-free write and control-flow hijack primitive.
A:H - Using a freed cec_fh from the receive path causes a kernel oops or panic even when not fully exploited for code execution, taking down the host.
CVSS 3.1