CVE-2022-48714
published 2024-06-20CVE-2022-48714: In the Linux kernel, the following vulnerability has been resolved: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf After commit 2fd3fb0be1d1 ("kasan, vmalloc…
PriorityP429high7.1CVSS 3.1
AVLACLPRLUINSUCHINAH
EPSS
0.24%
15.0th percentile
In the Linux kernel, the following vulnerability has been resolved:
bpf: Use VM_MAP instead of VM_ALLOC for ringbuf
After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages
after mapping"), non-VM_ALLOC mappings will be marked as accessible
in __get_vm_area_node() when KASAN is enabled. But now the flag for
ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access
after vmap() returns. Because the ringbuf area is created by mapping
allocated pages, so use VM_MAP instead.
After the change, info in /proc/vmallocinfo also changes from
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
to
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
Affected
14 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.16.10-1 (bookworm) | linux 5.16.10-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 457f44363a8894135c85b7a9afd2bd8196db24ab < 6304a613a97d6dcd49b93fbad31e9f39d1e138d6 | 6304a613a97d6dcd49b93fbad31e9f39d1e138d6 |
| linux | linux | >= 457f44363a8894135c85b7a9afd2bd8196db24ab < 5e457aeab52a5947619e1f18047f4d2f3212b3eb | 5e457aeab52a5947619e1f18047f4d2f3212b3eb |
| linux | linux | >= 457f44363a8894135c85b7a9afd2bd8196db24ab < d578933f6226d5419af9306746efa1c693cbaf9c | d578933f6226d5419af9306746efa1c693cbaf9c |
| linux | linux | >= 457f44363a8894135c85b7a9afd2bd8196db24ab < b293dcc473d22a62dc6d78de2b15e4f49515db56 | b293dcc473d22a62dc6d78de2b15e4f49515db56 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.103-1 | 5.10.103-1 |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 0 < 5.16.10-1 | 5.16.10-1 |
| linux | linux_kernel | >= 5.11 < 5.15.22 | 5.15.22 |
| linux | linux_kernel | >= 5.16 < 5.16.8 | 5.16.8 |
| linux | linux_kernel | >= 5.8 < 5.10.99 | 5.10.99 |
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: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf
vendor_redhat·2024-06-20·CVSS 7.1
CVE-2022-48714 [HIGH] CWE-125 kernel: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf
kernel: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf
In the Linux kernel, the following vulnerability has been resolved:
bpf: Use VM_MAP instead of VM_ALLOC for ringbuf
After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages
after mapping"), non-VM_ALLOC mappings will be marked as accessible
in __get_vm_area_node() when KASAN is enabled. But now the flag for
ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access
after vmap() returns. Because the ringbuf area is created by mapping
allocated pages, so use VM_MAP instead.
After the change, info in /proc/vmallocinfo also changes from
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
to
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
Package: kernel (Red Hat Enterprise Linux 6) - Not affec
Debian
CVE-2022-48714: linux - In the Linux kernel, the following vulnerability has been resolved: bpf: Use VM...
vendor_debian·2022·CVSS 7.1
CVE-2022-48714 [HIGH] CVE-2022-48714: linux - In the Linux kernel, the following vulnerability has been resolved: bpf: Use VM...
In the Linux kernel, the following vulnerability has been resolved: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages after mapping"), non-VM_ALLOC mappings will be marked as accessible in __get_vm_area_node() when KASAN is enabled. But now the flag for ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access after vmap() returns. Because the ringbuf area is created by mapping allocated pages, so use VM_MAP instead. After the change, info in /proc/vmallocinfo also changes from [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user to [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
Scope: local
bookworm: resolved (fixed in 5.16.10-1)
bullseye: resolved (fixed in 5.10.103-1)
forky: resolved (fix
GHSA
GHSA-vfq8-59v7-rr9v: In the Linux kernel, the following vulnerability has been resolved:
bpf: Use VM_MAP instead of VM_ALLOC for ringbuf
After commit 2fd3fb0be1d1 ("kasa
ghsa_unreviewed·2024-06-20
CVE-2022-48714 [HIGH] CWE-125 GHSA-vfq8-59v7-rr9v: In the Linux kernel, the following vulnerability has been resolved:
bpf: Use VM_MAP instead of VM_ALLOC for ringbuf
After commit 2fd3fb0be1d1 ("kasa
In the Linux kernel, the following vulnerability has been resolved:
bpf: Use VM_MAP instead of VM_ALLOC for ringbuf
After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages
after mapping"), non-VM_ALLOC mappings will be marked as accessible
in __get_vm_area_node() when KASAN is enabled. But now the flag for
ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access
after vmap() returns. Because the ringbuf area is created by mapping
allocated pages, so use VM_MAP instead.
After the change, info in /proc/vmallocinfo also changes from
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user
to
[start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
OSV
CVE-2022-48714: In the Linux kernel, the following vulnerability has been resolved: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf After commit 2fd3fb0be1d1 ("kasan,
osv·2024-06-20·CVSS 7.1
CVE-2022-48714 [HIGH] CVE-2022-48714: In the Linux kernel, the following vulnerability has been resolved: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf After commit 2fd3fb0be1d1 ("kasan,
In the Linux kernel, the following vulnerability has been resolved: bpf: Use VM_MAP instead of VM_ALLOC for ringbuf After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages after mapping"), non-VM_ALLOC mappings will be marked as accessible in __get_vm_area_node() when KASAN is enabled. But now the flag for ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access after vmap() returns. Because the ringbuf area is created by mapping allocated pages, so use VM_MAP instead. After the change, info in /proc/vmallocinfo also changes from [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user to [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
https://git.kernel.org/stable/c/5e457aeab52a5947619e1f18047f4d2f3212b3ebhttps://git.kernel.org/stable/c/6304a613a97d6dcd49b93fbad31e9f39d1e138d6https://git.kernel.org/stable/c/b293dcc473d22a62dc6d78de2b15e4f49515db56https://git.kernel.org/stable/c/d578933f6226d5419af9306746efa1c693cbaf9chttps://git.kernel.org/stable/c/5e457aeab52a5947619e1f18047f4d2f3212b3ebhttps://git.kernel.org/stable/c/6304a613a97d6dcd49b93fbad31e9f39d1e138d6https://git.kernel.org/stable/c/b293dcc473d22a62dc6d78de2b15e4f49515db56https://git.kernel.org/stable/c/d578933f6226d5419af9306746efa1c693cbaf9c
2024-06-20
Published