CVE-2021-47604
published 2024-06-19CVE-2021-47604: In the Linux kernel, the following vulnerability has been resolved: vduse: check that offset is within bounds in get_config() This condition checks "len" but…
PriorityP430high7.1CVSS 3.1
AVLACLPRLUINSUCHINAH
EPSS
0.21%
11.5th percentile
In the Linux kernel, the following vulnerability has been resolved:
vduse: check that offset is within bounds in get_config()
This condition checks "len" but it does not check "offset" and that
could result in an out of bounds read if "offset > dev->config_size".
The problem is that since both variables are unsigned the
"dev->config_size - offset" subtraction would result in a very high
unsigned value.
I think these checks might not be necessary because "len" and "offset"
are supposed to already have been validated using the
vhost_vdpa_config_validate() function. But I do not know the code
perfectly, and I like to be safe.
Affected
8 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.15.15-1 (bookworm) | linux 5.15.15-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= c8a6153b6c59d95c0e091f053f6f180952ade91e < ebbbc5fea3f648175df1aa3f127c78eb0252cc2a | ebbbc5fea3f648175df1aa3f127c78eb0252cc2a |
| linux | linux | >= c8a6153b6c59d95c0e091f053f6f180952ade91e < dc1db0060c02d119fd4196924eff2d1129e9a442 | dc1db0060c02d119fd4196924eff2d1129e9a442 |
| linux | linux_kernel | >= 0 < 5.15.15-1 | 5.15.15-1 |
| linux | linux_kernel | >= 0 < 5.15.15-1 | 5.15.15-1 |
| linux | linux_kernel | >= 0 < 5.15.15-1 | 5.15.15-1 |
| linux | linux_kernel | >= 5.15 < 5.15.11 | 5.15.11 |
CVSS provenance
nvdv3.17.1HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
osv7.1HIGH
vendor_debian7.1HIGH
vendor_redhat7.1HIGH
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: vduse: check that offset is within bounds in get_config()
vendor_redhat·2024-06-19·CVSS 7.1
CVE-2021-47604 [HIGH] CWE-125 kernel: vduse: check that offset is within bounds in get_config()
kernel: vduse: check that offset is within bounds in get_config()
In the Linux kernel, the following vulnerability has been resolved:
vduse: check that offset is within bounds in get_config()
This condition checks "len" but it does not check "offset" and that
could result in an out of bounds read if "offset > dev->config_size".
The problem is that since both variables are unsigned the
"dev->config_size - offset" subtraction would result in a very high
unsigned value.
I think these checks might not be necessary because "len" and "offset"
are supposed to already have been validated using the
vhost_vdpa_config_validate() function. But I do not know the code
perfectly, and I like to be safe.
Package: kernel (Red Hat Enterprise Linux 6) - Not affected
Package: kernel (Red Hat Enterprise Linu
Debian
CVE-2021-47604: linux - In the Linux kernel, the following vulnerability has been resolved: vduse: chec...
vendor_debian·2021·CVSS 7.1
CVE-2021-47604 [HIGH] CVE-2021-47604: linux - In the Linux kernel, the following vulnerability has been resolved: vduse: chec...
In the Linux kernel, the following vulnerability has been resolved: vduse: check that offset is within bounds in get_config() This condition checks "len" but it does not check "offset" and that could result in an out of bounds read if "offset > dev->config_size". The problem is that since both variables are unsigned the "dev->config_size - offset" subtraction would result in a very high unsigned value. I think these checks might not be necessary because "len" and "offset" are supposed to already have been validated using the vhost_vdpa_config_validate() function. But I do not know the code perfectly, and I like to be safe.
Scope: local
bookworm: resolved (fixed in 5.15.15-1)
bullseye: resolved
forky: resolved (fixed in 5.15.15-1)
sid: resolved (fixed in 5.15.15-1)
trixie: resolved (fixed i
GHSA
GHSA-5583-qmch-62x6: In the Linux kernel, the following vulnerability has been resolved:
vduse: check that offset is within bounds in get_config()
This condition checks
ghsa_unreviewed·2024-06-19
CVE-2021-47604 [HIGH] CWE-125 GHSA-5583-qmch-62x6: In the Linux kernel, the following vulnerability has been resolved:
vduse: check that offset is within bounds in get_config()
This condition checks
In the Linux kernel, the following vulnerability has been resolved:
vduse: check that offset is within bounds in get_config()
This condition checks "len" but it does not check "offset" and that
could result in an out of bounds read if "offset > dev->config_size".
The problem is that since both variables are unsigned the
"dev->config_size - offset" subtraction would result in a very high
unsigned value.
I think these checks might not be necessary because "len" and "offset"
are supposed to already have been validated using the
vhost_vdpa_config_validate() function. But I do not know the code
perfectly, and I like to be safe.
OSV
CVE-2021-47604: In the Linux kernel, the following vulnerability has been resolved: vduse: check that offset is within bounds in get_config() This condition checks "l
osv·2024-06-19·CVSS 7.1
CVE-2021-47604 [HIGH] CVE-2021-47604: In the Linux kernel, the following vulnerability has been resolved: vduse: check that offset is within bounds in get_config() This condition checks "l
In the Linux kernel, the following vulnerability has been resolved: vduse: check that offset is within bounds in get_config() This condition checks "len" but it does not check "offset" and that could result in an out of bounds read if "offset > dev->config_size". The problem is that since both variables are unsigned the "dev->config_size - offset" subtraction would result in a very high unsigned value. I think these checks might not be necessary because "len" and "offset" are supposed to already have been validated using the vhost_vdpa_config_validate() function. But I do not know the code perfectly, and I like to be safe.
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2024-06-19
Published