// For flags

CVE-2022-48714

bpf: Use VM_MAP instead of VM_ALLOC for ringbuf

Severity Score

2.3
*CVSS v3

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track
*SSVC
Descriptions

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

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: use VM_MAP en lugar de VM_ALLOC para ringbuf Después del commit 2fd3fb0be1d1 ("kasan, vmalloc: despoisone las páginas VM_ALLOC después del mapeo"), los mapeos que no sean VM_ALLOC se marcarán como accesibles en __get_vm_area_node( ) cuando KASAN está habilitado. Pero ahora el indicador para el área ringbuf es VM_ALLOC, por lo que KASAN se quejará del acceso fuera de los límites después de que regrese vmap(). Debido a que el área ringbuf se crea asignando páginas asignadas, use VM_MAP en su lugar. Después del cambio, la información en /proc/vmallocinfo también cambia de [inicio]-[fin] 24576 ringbuf_map_alloc+0x171/0x290 usuario vmalloc a [inicio]-[fin] 24576 ringbuf_map_alloc+0x171/0x290 usuario vmap

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

*Credits: N/A
CVSS Scores
Attack Vector
Local
Attack Complexity
Low
Privileges Required
High
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
Low
Attack Vector
Local
Attack Complexity
Low
Authentication
Multiple
Confidentiality
None
Integrity
None
Availability
Partial
* Common Vulnerability Scoring System
SSVC
  • Decision:Track
Exploitation
None
Automatable
No
Tech. Impact
Partial
* Organization's Worst-case Scenario
Timeline
  • 2024-06-20 CVE Reserved
  • 2024-06-20 CVE Published
  • 2024-12-19 CVE Updated
  • 2025-03-30 EPSS Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.8 < 5.10.99
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.8 < 5.10.99"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.8 < 5.15.22
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.8 < 5.15.22"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.8 < 5.16.8
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.8 < 5.16.8"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 5.8 < 5.17
Search vendor "Linux" for product "Linux Kernel" and version " >= 5.8 < 5.17"
en
Affected