In the Linux kernel, the following vulnerability has been resolved:
drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl()
vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to
obtain a struct vidi_context pointer. However, drm_dev->dev is the
exynos-drm master device, and the driver_data contained therein is not
the vidi component device, but a completely different device.
This can lead to various bugs, ranging from null pointer dereferences and
garbage value accesses to, in unlucky cases, out-of-bounds errors,
use-after-free errors, and more.
To resolve this issue, we need to store/delete the vidi device pointer in
exynos_drm_private->vidi_dev during bind/unbind, and then read this
exynos_drm_private->vidi_dev within ioctl() to obtain the correct
struct vidi_context pointer.
CVSS
7.8 HIGH (v3.1, CNA)CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
from cf67cc9a29ac19c98bc4fa0e6d14b0c1f592d322 before 2987642c5213508c6c9e718324c0d5289a92c474; from cf67cc9a29ac19c98bc4fa0e6d14b0c1f592d322 before 65d1213baffa363f2eb1117b1dc7acc573b890f8; from cf67cc9a29ac19c98bc4fa0e6d14b0c1f592d322 before 875fa28690e93ed5296c31d3344556c6bb867234; from cf67cc9a29ac19c98bc4fa0e6d14b0c1f592d322 before 21ca24ba51a2c28bcc4df9d7e5a40b0eb66ab76d; from cf67cc9a29ac19c98bc4fa0e6d14b0c1f592d322 before e1aed617eb80b49eac2f8c7bb7a0990f641dd59b; from cf67cc9a29ac19c98bc4fa0e6d14b0c1f592d322 before b5fc86d753dd4c281a943b92f0eef02d31af03d7; from cf67cc9a29ac19c98bc4fa0e6d14b0c1f592d322 before a540f767642f75240a6c35f6a65b69e44cfcea9d; from cf67cc9a29ac19c98bc4fa0e6d14b0c1f592d322 before d3968a0d85b211e197f2f4f06268a7031079e0d0
from 4.3 before 5.10.253; from 5.11 before 5.15.203; from 5.16 before 6.1.167; from 6.2 before 6.6.130; from 6.7 before 6.18.14; from 6.19 before 6.19.4
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.
Printed from infosecsignals.com. Every record links back to the agency that published it.
Your cookie choices
We use essential cookies to run this site, and, only with your consent, an advertising cookie from Google to measure whether our ads lead to sign-ups and subscriptions. See our for details.