0.0
NA
CVE-2024-26639
Apache HTTP Server Remote Code Execution
Description

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

INFO

Published Date :

March 18, 2024, 11:15 a.m.

Last Modified :

June 20, 2024, 9:15 a.m.

Source :

416baaa9-dc9f-4396-8d5f-8c081fb06d67

Remotely Exploitable :

No

Impact Score :

Exploitability Score :

Public PoC/Exploit Available at Github

CVE-2024-26639 has a 1 public PoC/Exploit available at Github. Go to the Public Exploits tab to see the list.

Affected Products

The following products are affected by CVE-2024-26639 vulnerability. Even if cvefeed.io is aware of the exact versions of the products that are affected, the information is not represented in the table below.

ID Vendor Product Action
1 Linux linux_kernel
: Total Affected Vendor : 1 | Products : 1

We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).

Profile Photo
NaInSec/CVE-LIST

Ini adalah repository kumpulan CVE v.5

allcve cve cvelist newcve

Updated: 1 month, 3 weeks ago
2 stars 0 fork 0 watcher
Born at : March 24, 2024, 3:01 p.m. This repo has been linked 1214 different CVEs too.

Results are limited to the first 15 repositories due to potential performance issues.

The following list is the news that have been mention CVE-2024-26639 vulnerability anywhere in the article.

The following table lists the changes that have been made to the CVE-2024-26639 vulnerability over time.

Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.

  • CVE Rejected by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Jun. 20, 2024

    Action Type Old Value New Value
  • CVE Translated by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Jun. 20, 2024

    Action Type Old Value New Value
    Removed Translation Title: kernel de Linux Description: En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm, kmsan: corrige la recursividad infinita debido a la sección crítica de RCU Alexander Potapenko escribe en [1]: "Para cada acceso a memoria en el código instrumentado por KMSAN llamamos kmsan_get_metadata() para obtener los metadatos de la memoria a la que se accede. Para la memoria virtual, los punteros de metadatos se almacenan en la `página de estructura` correspondiente, por lo tanto, necesitamos llamar a virt_to_page() para obtenerlos. De acuerdo con el comentario en arch/x86/include/asm/page .h, virt_to_page(kaddr) devuelve un puntero válido si virt_addr_valid(kaddr) es verdadero, por lo que KMSAN también necesita llamar a virt_addr_valid(). Para evitar la recursividad, kmsan_get_metadata() no debe llamar al código instrumentado, por lo tanto ./arch/x86/ include/asm/kmsan.h bifurca partes de arch/x86/mm/physaddr.c para verificar si una dirección virtual es válida o no, pero la introducción de rcu_read_lock() a pfn_valid() agregó llamadas API de RCU instrumentadas a virt_to_page_or_null() , que es llamado por kmsan_get_metadata(), por lo que ahora hay una recursividad infinita. No creo que sea correcto detener esa recursividad haciendo kmsan_enter_runtime()/kmsan_exit_runtime() en kmsan_get_metadata(): eso evitaría que las funciones instrumentadas llamadas desde el tiempo de ejecución rastreen los valores ocultos, lo que podría introducir falsos positivos. problema al cambiar pfn_valid() a la variante _sched() de rcu_read_lock/unlock(), que no requiere llamar a RCU. Dado que la sección crítica en pfn_valid() es muy pequeña, esta es una compensación razonable (con RCU interrumpible ). Además, KMSAN debe tener cuidado de suprimir las llamadas al programador, lo que sería otra fuente de recursividad. Esto se puede hacer envolviendo la llamada a pfn_valid() en preempt_disable/enable_no_resched(). La desventaja es que esto sacrifica la interrupción de la programación. garantías; sin embargo, un kernel compilado con KMSAN ya ha renunciado a cualquier garantía de rendimiento debido a que está fuertemente instrumentado. Tenga en cuenta que el código KMSAN ya deshabilita el seguimiento a través de Makefile y, dado que mmzone.h está incluido, no es necesario usar la variante notrace, que generalmente se prefiere en todos los demás casos.
  • CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Jun. 20, 2024

    Action Type Old Value New Value
    Changed Description In the Linux kernel, the following vulnerability has been resolved: mm, kmsan: fix infinite recursion due to RCU critical section Alexander Potapenko writes in [1]: "For every memory access in the code instrumented by KMSAN we call kmsan_get_metadata() to obtain the metadata for the memory being accessed. For virtual memory the metadata pointers are stored in the corresponding `struct page`, therefore we need to call virt_to_page() to get them. According to the comment in arch/x86/include/asm/page.h, virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) is true, so KMSAN needs to call virt_addr_valid() as well. To avoid recursion, kmsan_get_metadata() must not call instrumented code, therefore ./arch/x86/include/asm/kmsan.h forks parts of arch/x86/mm/physaddr.c to check whether a virtual address is valid or not. But the introduction of rcu_read_lock() to pfn_valid() added instrumented RCU API calls to virt_to_page_or_null(), which is called by kmsan_get_metadata(), so there is an infinite recursion now. I do not think it is correct to stop that recursion by doing kmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): that would prevent instrumented functions called from within the runtime from tracking the shadow values, which might introduce false positives." Fix the issue by switching pfn_valid() to the _sched() variant of rcu_read_lock/unlock(), which does not require calling into RCU. Given the critical section in pfn_valid() is very small, this is a reasonable trade-off (with preemptible RCU). KMSAN further needs to be careful to suppress calls into the scheduler, which would be another source of recursion. This can be done by wrapping the call to pfn_valid() into preempt_disable/enable_no_resched(). The downside is that this sacrifices breaking scheduling guarantees; however, a kernel compiled with KMSAN has already given up any performance guarantees due to being heavily instrumented. Note, KMSAN code already disables tracing via Makefile, and since mmzone.h is included, it is not necessary to use the notrace variant, which is generally preferred in all other cases. Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
    Removed Reference kernel.org https://git.kernel.org/stable/c/dc904345e3771aa01d0b8358b550802fdc6fe00b
    Removed Reference kernel.org https://git.kernel.org/stable/c/6335c0cdb2ea0ea02c999e04d34fd84f69fb27ff
    Removed Reference kernel.org https://git.kernel.org/stable/c/5a33420599fa0288792537e6872fd19cc8607ea6
    Removed Reference kernel.org https://git.kernel.org/stable/c/f6564fce256a3944aa1bc76cb3c40e792d97c1eb
  • CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    May. 29, 2024

    Action Type Old Value New Value
  • CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    May. 14, 2024

    Action Type Old Value New Value
  • CVE Modified by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Apr. 04, 2024

    Action Type Old Value New Value
    Added Reference kernel.org https://git.kernel.org/stable/c/f6564fce256a3944aa1bc76cb3c40e792d97c1eb [No types assigned]
  • CVE Received by 416baaa9-dc9f-4396-8d5f-8c081fb06d67

    Mar. 18, 2024

    Action Type Old Value New Value
    Added Description In the Linux kernel, the following vulnerability has been resolved: mm, kmsan: fix infinite recursion due to RCU critical section Alexander Potapenko writes in [1]: "For every memory access in the code instrumented by KMSAN we call kmsan_get_metadata() to obtain the metadata for the memory being accessed. For virtual memory the metadata pointers are stored in the corresponding `struct page`, therefore we need to call virt_to_page() to get them. According to the comment in arch/x86/include/asm/page.h, virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) is true, so KMSAN needs to call virt_addr_valid() as well. To avoid recursion, kmsan_get_metadata() must not call instrumented code, therefore ./arch/x86/include/asm/kmsan.h forks parts of arch/x86/mm/physaddr.c to check whether a virtual address is valid or not. But the introduction of rcu_read_lock() to pfn_valid() added instrumented RCU API calls to virt_to_page_or_null(), which is called by kmsan_get_metadata(), so there is an infinite recursion now. I do not think it is correct to stop that recursion by doing kmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): that would prevent instrumented functions called from within the runtime from tracking the shadow values, which might introduce false positives." Fix the issue by switching pfn_valid() to the _sched() variant of rcu_read_lock/unlock(), which does not require calling into RCU. Given the critical section in pfn_valid() is very small, this is a reasonable trade-off (with preemptible RCU). KMSAN further needs to be careful to suppress calls into the scheduler, which would be another source of recursion. This can be done by wrapping the call to pfn_valid() into preempt_disable/enable_no_resched(). The downside is that this sacrifices breaking scheduling guarantees; however, a kernel compiled with KMSAN has already given up any performance guarantees due to being heavily instrumented. Note, KMSAN code already disables tracing via Makefile, and since mmzone.h is included, it is not necessary to use the notrace variant, which is generally preferred in all other cases.
    Added Reference kernel.org https://git.kernel.org/stable/c/dc904345e3771aa01d0b8358b550802fdc6fe00b [No types assigned]
    Added Reference kernel.org https://git.kernel.org/stable/c/6335c0cdb2ea0ea02c999e04d34fd84f69fb27ff [No types assigned]
    Added Reference kernel.org https://git.kernel.org/stable/c/5a33420599fa0288792537e6872fd19cc8607ea6 [No types assigned]
EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. Following chart shows the EPSS score history of the vulnerability.
CWE - Common Weakness Enumeration

While CVE identifies specific instances of vulnerabilities, CWE categorizes the common flaws or weaknesses that can lead to vulnerabilities. CVE-2024-26639 is associated with the following CWEs:

Common Attack Pattern Enumeration and Classification (CAPEC)

Common Attack Pattern Enumeration and Classification (CAPEC) stores attack patterns, which are descriptions of the common attributes and approaches employed by adversaries to exploit the CVE-2024-26639 weaknesses.

NONE - Vulnerability Scoring System
: