In the Linux kernel, the following vulnerability has been resolved:
media: i2c: ov7740: fix use-after-destroy in remove
The ov7740_remove() function had a severe teardown order bug where it
destroyed the driver's mutex before freeing the V4L2 control handler
which relies on that mutex, leading to a use-after-destroy kernel panic.
Furthermore, the driver explicitly called v4l2_ctrl_handler_free() and
mutex_destroy() sequentially, but then called ov7740_free_controls()
which invokes both of them a second time, resulting in a double-free.
This patch fixes the issue by unregistering the subdevice first, and
relying exclusively on ov7740_free_controls() to safely tear down the
mutex and control handler in the correct order.
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 7.8
AV:L - The UAF is in ov7740_remove() for the onboard OmniVision OV7740 I2C/CSI camera sensor, reached via local I2C teardown (sysfs unbind, i2c delete_device, rmmod) and V4L2 ioctls on /dev/v4l-subdev (V4L2_SUBDEV_FL_HAS_DEVNODE). No network, Bluetooth, or USB packet path exists.
AC:L - ov7740_remove() deterministically mutex_destroy()s ov7740->mutex then v4l2_ctrl_handler_free() locks that same mutex and kvfree()s all v4l2_ctrl objects while the subdev is still registered. An attacker holding the node and driving teardown needs no uncontrollable race or rare debug config.
PR:L - VIDIOC_G/S_CTRL on the subdev node have no capable() check; udev typically grants /dev/v4l-subdev to the video group or Android camera UID on SAMA5/embedded boards shipping CONFIG_VIDEO_OV7740. Per CNA driver-removal UAF and media i2c unbind precedent this is PR:L, not init-namespace root.
UI:N - The attacker opens the V4L2 subdev node and initiates or coordinates driver teardown themselves (unbind/rmmod/maintenance). CNA driver-removal UAFs score UI:N; no separate victim action such as mounting a filesystem is required.
S:U - The UAF corrupts host kernel heap (struct v4l2_ctrl, v4l2_ctrl_ref, and handler buckets) within the same OS security authority. It is not a VM escape, IOMMU/DMA isolation bypass, or sandbox breakout.
C:H - v4l2_ctrl_handler_free() kvfree()s each v4l2_ctrl while open fds still hold vfh->ctrl_handler and issue VIDIOC_G_CTRL/G_EXT_CTRLS through dangling ctrl lists. Per kernel UAF guidance this enables arbitrary kernel disclosure, so confidentiality is High.
I:H - struct v4l2_ctrl embeds ops and type_ops function pointers; VIDIOC_S_CTRL on a sprayed freed object yields control-flow hijack. Kernel UAF guidance scores this High integrity.
A:H - mutex_lock of the destroyed mutex and later walks of freed ctrl lists after handler_free oops or panic the kernel even when the UAF is not fully turned into a write primitive, so availability is High.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The UAF is in ov7740_remove() for the onboard OmniVision OV7740 I2C/CSI camera sensor, reached via local I2C teardown (sysfs unbind, i2c delete_device, rmmod) and V4L2 ioctls on /dev/v4l-subdev (V4L2_SUBDEV_FL_HAS_DEVNODE). No network, Bluetooth, or USB packet path exists.
AC:L - ov7740_remove() deterministically mutex_destroy()s ov7740->mutex then v4l2_ctrl_handler_free() locks that same mutex and kvfree()s all v4l2_ctrl objects while the subdev is still registered. An attacker holding the node and driving teardown needs no uncontrollable race or rare debug config.
PR:L - VIDIOC_G/S_CTRL on the subdev node have no capable() check; udev typically grants /dev/v4l-subdev to the video group or Android camera UID on SAMA5/embedded boards shipping CONFIG_VIDEO_OV7740. Per CNA driver-removal UAF and media i2c unbind precedent this is PR:L, not init-namespace root.
UI:N - The attacker opens the V4L2 subdev node and initiates or coordinates driver teardown themselves (unbind/rmmod/maintenance). CNA driver-removal UAFs score UI:N; no separate victim action such as mounting a filesystem is required.
S:U - The UAF corrupts host kernel heap (struct v4l2_ctrl, v4l2_ctrl_ref, and handler buckets) within the same OS security authority. It is not a VM escape, IOMMU/DMA isolation bypass, or sandbox breakout.
C:H - v4l2_ctrl_handler_free() kvfree()s each v4l2_ctrl while open fds still hold vfh->ctrl_handler and issue VIDIOC_G_CTRL/G_EXT_CTRLS through dangling ctrl lists. Per kernel UAF guidance this enables arbitrary kernel disclosure, so confidentiality is High.
I:H - struct v4l2_ctrl embeds ops and type_ops function pointers; VIDIOC_S_CTRL on a sprayed freed object yields control-flow hijack. Kernel UAF guidance scores this High integrity.
A:H - mutex_lock of the destroyed mutex and later walks of freed ctrl lists after handler_free oops or panic the kernel even when the UAF is not fully turned into a write primitive, so availability is High.
CVSS 3.1