VDB-282284 · CVE-2024-50082 · Nessus 212412

Linux Kernel hasta 6.11.4 blk-rq-qos rq_qos_wake_function desbordamiento de búfer

CVSS Puntuación meta temporal	Precio actual del exploit (≈)	Puntuación de interés CTI
5.1	$0-$5k	0.00

Resumeninformación

Una vulnerabilidad fue encontrada en Linux Kernel hasta 5.10.227/5.15.168/6.1.113/6.6.57/6.11.4 y clasificada como crítica. Se ve afectada una función desconocida del componente blk-rq-qos. La manipulación conduce a desbordamiento de búfer. La vulnerabilidad es identificada como CVE-2024-50082. No existe ningún exploit disponible. El mejor modo sugerido para mitigar el problema es actualizar a la última versión.

Detallesinformación

Una vulnerabilidad clasificada como crítica ha sido encontrada en Linux Kernel hasta 5.10.227/5.15.168/6.1.113/6.6.57/6.11.4. La función rq_qos_wake_function del componente blk-rq-qos es afectada por esta vulnerabilidad. Por la manipulación de un input desconocido se causa una vulnerabilidad de clase desbordamiento de búfer. Esto tiene repercusión sobre la la disponibilidad. CVE resume:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-rq-qos: se corrige el fallo en la ejecución rq_qos_wait vs. rq_qos_wake_function Estamos viendo fallos de rq_qos_wake_function que se parecen a esto: ERROR: no se puede manejar el error de página para la dirección: ffffafe180a40084 #PF: acceso de escritura de supervisor en modo kernel #PF: error_code(0x0002) - página no presente PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 No contaminado 6.12.0-rc3-00013-geca631b8fe80 #11 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 01/04/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Código: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 000000000001e7240 R09: 0000000000000011 R10: 00000000000000028 R11: 00000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Seguimiento de llamadas: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... Entonces rq_qos_wake_function() llama a wake_up_process(data->task), que llama a try_to_wake_up(), que falla en raw_spin_lock_irqsave(&p->pi_lock). p viene de data->task, y data viene de la entrada de la cola de espera, que se almacena en la pila del que espera en rq_qos_wait(). Al analizar el volcado de memoria con drgn, descubrí que el que espera ya se había despertado y se había movido a una ruta de código completamente no relacionada, destruyendo lo que antes era data->task. Mientras tanto, el waker estaba pasando la basura golpeada en data->task a wake_up_process(), lo que provocó el bloqueo. Lo que está sucediendo es que entre rq_qos_wake_function() eliminando la entrada de la cola de espera y llamando a wake_up_process(), rq_qos_wait() descubre que ya obtuvo un token y regresa. La ejecución se ve así: rq_qos_wait() rq_qos_wake_function() ============================================================ prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- retorna inmediatamente porque list_empty_careful(&wq_entry->entry) es verdadero... retorna, ve a hacer otra cosa... wake_up_process(data->task) (¡YA NO ES VÁLIDO!)-^ Normalmente, se supone que finish_wait() se sincroniza con el activador. Pero, como se señaló anteriormente, retorna inmediatamente porque la entrada de la cola de espera ya se eliminó de la cola de espera. El error es que rq_qos_wake_function() está accediendo a la entrada de la cola de espera DESPUÉS de eliminarla. Tenga en cuenta que autoremove_wake_function() despierta al que espera y LUEGO elimina la entrada de la cola de espera, que es el orden correcto. Arréglelo intercambiando el orden. También debemos usar list_del_init_careful() para que coincida con list_empty_careful() en finish_wait().

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2024-50082. Se considera fácil de explotar. Hay detalles técnicos conocidos, pero no se dispone de un exploit.

Para el scanner Nessus se dispone de un plugin ID 212412 (RHEL 8 : kernel-rt (RHSA-2024:10944)), que puede ayudar a determinar la existencia del riesgo analizado.

Una actualización a la versión 5.10.228, 5.15.169, 6.1.114, 6.6.58 o 6.11.5 elimina esta vulnerabilidad. Aplicando el parche 3bc6d0f8b70a/455a469758e5/b5e900a3612b/4c5b123ab289/04f283fc16c8/e972b08b91ef es posible eliminar el problema. El parche puede ser descargado de git.kernel.org. El mejor modo sugerido para mitigar el problema es Actualización.

La vulnerabilidad también está documentado en las bases de datos Tenable (212412) y CERT Bund (WID-SEC-2024-3289). Once again VulDB remains the best source for vulnerability data.

Afectado

Debian Linux
Amazon Linux 2
Red Hat Enterprise Linux
Ubuntu Linux
SUSE Linux
Oracle Linux
Open Source eCryptfs
NetApp ActiveIQ Unified Manager
SUSE openSUSE
RESF Rocky Linux
IBM QRadar SIEM

Productoinformación

Escribe

Operating System

Proveedor

Linux

Nombre

Kernel

Versión

Licencia

Código abierto

Sitio web

Proveedor: https://www.kernel.org/

CPE 2.3información

CPE 2.2información

CVSSv4información

VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CVSSv3información

VulDB Puntuación meta base: 5.2
VulDB Puntuación meta temporal: 5.1

VulDB Puntuación base: 5.7
VulDB Puntuación temporal: 5.5
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

NVD Puntuación base: 4.7
NVD Vector: 🔍

CVSSv2información

AV	AC	Au	C	I	A
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳

Vector	Complejidad	Autenticación	Confidencialidad	Integridad	Disponibilidad
Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear
Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear
Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear	Desbloquear

VulDB Puntuación base: 🔍
VulDB Puntuación temporal: 🔍
VulDB Confiabilidad: 🔍

Explotacióninformación

Clase: Desbordamiento de búfer
CWE: CWE-119
CAPEC: 🔍
ATT&CK: 🔍

Físico: En parte
Local: Sí
Remoto: En parte

Disponibilidad: 🔍
Estado: No está definido

EPSS Score: 🔍
EPSS Percentile: 🔍

Predicción de precios: 🔍
Estimación del precio actual: 🔍

0-Day	Desbloquear	Desbloquear	Desbloquear	Desbloquear
Hoy	Desbloquear	Desbloquear	Desbloquear	Desbloquear

Nessus ID: 212412
Nessus Nombre: RHEL 8 : kernel-rt (RHSA-2024:10944)

Inteligencia de amenazasinformación

Interés: 🔍
Actores activos: 🔍
Grupos APT activos: 🔍

Contramedidasinformación

Recomendación: Actualización
Estado: 🔍

Hora de 0 días: 🔍

Actualización: Kernel 5.10.228/5.15.169/6.1.114/6.6.58/6.11.5
Parche: 3bc6d0f8b70a/455a469758e5/b5e900a3612b/4c5b123ab289/04f283fc16c8/e972b08b91ef