CVE-2021-47444
published 2024-05-22CVE-2021-47444: In the Linux kernel, the following vulnerability has been resolved: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read In commit e11f5bd8228f…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.22%
13.2th percentile
In the Linux kernel, the following vulnerability has been resolved:
drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid
corruption test") the function connector_bad_edid() started assuming
that the memory for the EDID passed to it was big enough to hold
`edid[0x7e] + 1` blocks of data (1 extra for the base block). It
completely ignored the fact that the function was passed `num_blocks`
which indicated how much memory had been allocated for the EDID.
Let's fix this by adding a bounds check.
This is important for handling the case where there's an error in the
first block of the EDID. In that case we will call
connector_bad_edid() without having re-allocated memory based on
`edid[0x7e]`.
Affected
12 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.14.16-1 (bookworm) | linux 5.14.16-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= e11f5bd8228fc3760c221f940b9f6365dbf3e7ed < a7b45024f66f9ec769e8dbb1a51ae83cd05929c7 | a7b45024f66f9ec769e8dbb1a51ae83cd05929c7 |
| linux | linux | >= e11f5bd8228fc3760c221f940b9f6365dbf3e7ed < 09f3946bb452918dbfb1982add56f9ffaae393dc | 09f3946bb452918dbfb1982add56f9ffaae393dc |
| linux | linux | >= e11f5bd8228fc3760c221f940b9f6365dbf3e7ed < 97794170b696856483f74b47bfb6049780d2d3a0 | 97794170b696856483f74b47bfb6049780d2d3a0 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.84-1 | 5.10.84-1 |
| linux | linux_kernel | >= 0 < 5.14.16-1 | 5.14.16-1 |
| linux | linux_kernel | >= 0 < 5.14.16-1 | 5.14.16-1 |
| linux | linux_kernel | >= 0 < 5.14.16-1 | 5.14.16-1 |
| linux | linux_kernel | >= 5.11 < 5.14.14 | 5.14.14 |
| linux | linux_kernel | >= 5.7 < 5.10.75 | 5.10.75 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
vendor_redhat·2024-05-22·CVSS 5.5
CVE-2021-47444 [MEDIUM] CWE-787 kernel: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
kernel: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
In the Linux kernel, the following vulnerability has been resolved:
drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid
corruption test") the function connector_bad_edid() started assuming
that the memory for the EDID passed to it was big enough to hold
`edid[0x7e] + 1` blocks of data (1 extra for the base block). It
completely ignored the fact that the function was passed `num_blocks`
which indicated how much memory had been allocated for the EDID.
Let's fix this by adding a bounds check.
This is important for handling the case where there's an error in the
first block of the EDID. In that case we will call
connector_bad_edid() w
Debian
CVE-2021-47444: linux - In the Linux kernel, the following vulnerability has been resolved: drm/edid: I...
vendor_debian·2021·CVSS 5.5
CVE-2021-47444 [MEDIUM] CVE-2021-47444: linux - In the Linux kernel, the following vulnerability has been resolved: drm/edid: I...
In the Linux kernel, the following vulnerability has been resolved: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test") the function connector_bad_edid() started assuming that the memory for the EDID passed to it was big enough to hold `edid[0x7e] + 1` blocks of data (1 extra for the base block). It completely ignored the fact that the function was passed `num_blocks` which indicated how much memory had been allocated for the EDID. Let's fix this by adding a bounds check. This is important for handling the case where there's an error in the first block of the EDID. In that case we will call connector_bad_edid() without having re-allocated memory based on `edid[0x7e]`.
Scope: local
bookwor
GHSA
GHSA-969w-fmcp-j8rq: In the Linux kernel, the following vulnerability has been resolved:
drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
In commit e1
ghsa_unreviewed·2024-05-22
CVE-2021-47444 [MEDIUM] GHSA-969w-fmcp-j8rq: In the Linux kernel, the following vulnerability has been resolved:
drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
In commit e1
In the Linux kernel, the following vulnerability has been resolved:
drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid
corruption test") the function connector_bad_edid() started assuming
that the memory for the EDID passed to it was big enough to hold
`edid[0x7e] + 1` blocks of data (1 extra for the base block). It
completely ignored the fact that the function was passed `num_blocks`
which indicated how much memory had been allocated for the EDID.
Let's fix this by adding a bounds check.
This is important for handling the case where there's an error in the
first block of the EDID. In that case we will call
connector_bad_edid() without having re-allocated memory based on
`edid[0x7e]`.
OSV
CVE-2021-47444: In the Linux kernel, the following vulnerability has been resolved: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read In commit e11f
osv·2024-05-22·CVSS 5.5
CVE-2021-47444 [MEDIUM] CVE-2021-47444: In the Linux kernel, the following vulnerability has been resolved: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read In commit e11f
In the Linux kernel, the following vulnerability has been resolved: drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test") the function connector_bad_edid() started assuming that the memory for the EDID passed to it was big enough to hold `edid[0x7e] + 1` blocks of data (1 extra for the base block). It completely ignored the fact that the function was passed `num_blocks` which indicated how much memory had been allocated for the EDID. Let's fix this by adding a bounds check. This is important for handling the case where there's an error in the first block of the EDID. In that case we will call connector_bad_edid() without having re-allocated memory based on `edid[0x7e]`.
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/09f3946bb452918dbfb1982add56f9ffaae393dchttps://git.kernel.org/stable/c/97794170b696856483f74b47bfb6049780d2d3a0https://git.kernel.org/stable/c/a7b45024f66f9ec769e8dbb1a51ae83cd05929c7https://git.kernel.org/stable/c/09f3946bb452918dbfb1982add56f9ffaae393dchttps://git.kernel.org/stable/c/97794170b696856483f74b47bfb6049780d2d3a0https://git.kernel.org/stable/c/a7b45024f66f9ec769e8dbb1a51ae83cd05929c7
2024-05-22
Published