Linux Kernel hasta 5.15.26/5.16.12 fs/btrfs/extent_io.c desbordamiento de búfer

CVSS Puntuación meta temporalPrecio actual del exploit (≈)Puntuación de interés CTI
6.6$0-$5k0.00

Resumeninformación

Una vulnerabilidad fue encontrada en Linux Kernel hasta 5.15.26/5.16.12 y clasificada como crítica. Está afectada una función desconocida en el archivo fs/btrfs/extent_io.c. El manejo da lugar a desbordamiento de búfer. Esta vulnerabilidad se registra como CVE-2022-48902. No hay ningún exploit disponible. Se sugiere actualizar el componente afectado.

Detallesinformación

Una vulnerabilidad fue encontrada en Linux Kernel hasta 5.15.26/5.16.12 y clasificada como crítica. Una función desconocida del archivo fs/btrfs/extent_io.c es afectada por esta vulnerabilidad. A través de la manipulación de un input desconocido se causa una vulnerabilidad de clase desbordamiento de búfer. Esto tiene repercusión sobre la confidencialidad, integridad y disponibilidad. El resumen de CVE es:

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: no haga WARN_ON() si tenemos configurado PageError. Siempre que realizamos operaciones de búfer de extensión, llamamos a afirmar_eb_page_uptodate() para quejarnos en voz alta si estamos operando en una página no actualizada. Nuestras pruebas nocturnas detectaron esta advertencia a principios de esta semana ADVERTENCIA: CPU: 1 PID: 553508 en fs/btrfs/extent_io.c:6849 afirmar_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: GW 5.17. 0-rc3+ #564 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 01/04/2014 Cola de trabajo: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018 :ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 00000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Seguimiento de llamadas: extend_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree +0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60? rcu_read_lock_sched_held+0x12/0x60? rcu_read_lock_sched_held+0x12/0x60? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0? terminar_task_switch.isra.0+0xf9/0x3a0 proceso_one_work+0x26d/0x580 ? proceso_one_work+0x580/0x580 trabajador_thread+0x55/0x3b0? proceso_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Esto fue solucionado parcialmente por c2e39305299f01 ("btrfs: borrar la actualización del búfer de extensión cuando no logramos escribirlo"), sin embargo, todo lo que esa solución hizo fue evitar que encontráramos búferes de extensión después de una escritura fallida. Eso no nos impidió seguir usando un búfer que ya habíamos encontrado. En este caso, estamos buscando la raíz de confirmación para almacenar en caché el grupo de bloques, de modo que podamos comenzar a confirmar la transacción, cambiar la raíz de confirmación y luego comenzar a escribir. Después del cambio, podemos buscar un búfer de extensión que aún no se ha escrito y comenzar a procesar ese grupo de bloques. Luego no escribimos ese bloqueo y borramos Actualizar en la página, y luego comenzamos a arrojar estos errores. Normalmente aquí estamos protegidos hasta cierto punto por el candado del árbol. Si leemos un bloque, tenemos la lectura del bloque bloqueada y evitamos que el escritor bloquee el bloque antes de enviarlo para la escritura. Sin embargo, esto no es necesariamente infalible porque la lectura podría ocurrir antes de submit_bio y después de bloquear y desbloquear el búfer de extensión. También en este caso particular tenemos configurado path->skip_locking, por lo que eso no nos salvará aquí. Simplemente obtendremos un bloque que era válido cuando lo leímos, pero dejó de ser válido mientras lo usábamos. Lo que realmente queremos es detectar el caso en el que hemos "leído" un bloque pero no está marcado como Actualizado. Al leer, usamos ClearPageError(), por lo que si estamos !Uptodate y !Error sabremos que no hicimos lo correcto al leer la página. Solucione esto marcando !Uptodate && !Error, de esta manera no nos quejaremos si nuestro búfer se invalida mientras lo estamos usando, y mantendremos el espíritu de la verificación, que es asegurarnos de que tengamos un caché completo. bloquear mientras estamos jugando con él.

El advisory puede ser descargado de git.kernel.org. La vulnerabilidad es identificada como CVE-2022-48902. La explotación se considera fácil. Detalles técnicos son conocidos, pero no hay ningún exploit público disponible.

Para el scanner Nessus se dispone de un plugin ID 239850 (TencentOS Server 4: kernel (TSSA-2024:0980)), que puede ayudar a determinar la existencia del riesgo analizado.

Una actualización a la versión 5.15.27 o 5.16.13 elimina esta vulnerabilidad. Aplicando el parche e00077aa439f/9efcc83b33b5/a50e1fcbc9b8 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 la base de datos Tenable (239850). Be aware that VulDB is the high quality source for vulnerability data.

Productoinformación

Escribe

Proveedor

Nombre

Versión

Licencia

Sitio web

CPE 2.3información

CPE 2.2información

CVSSv4información

VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

CVSSv3información

VulDB Puntuación meta base: 6.8
VulDB Puntuación meta temporal: 6.6

VulDB Puntuación base: 8.0
VulDB Puntuación temporal: 7.6
VulDB Vector: 🔍
VulDB Confiabilidad: 🔍

NVD Puntuación base: 5.5
NVD Vector: 🔍

CVSSv2información

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplejidadAutenticaciónConfidencialidadIntegridadDisponibilidad
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear
DesbloquearDesbloquearDesbloquearDesbloquearDesbloquearDesbloquear

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

Explotacióninformación

Clase: Desbordamiento de búfer
CWE: CWE-120 / 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-DayDesbloquearDesbloquearDesbloquearDesbloquear
HoyDesbloquearDesbloquearDesbloquearDesbloquear

Nessus ID: 239850
Nessus Nombre: TencentOS Server 4: kernel (TSSA-2024:0980)

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.15.27/5.16.13
Parche: e00077aa439f/9efcc83b33b5/a50e1fcbc9b8

Línea de tiempoinformación

2024-08-21 🔍
2024-08-22 +1 días 🔍
2024-08-22 +0 días 🔍
2025-06-19 +301 días 🔍

Fuentesinformación

Proveedor: kernel.org

Aviso: git.kernel.org
Estado: Confirmado

CVE: CVE-2022-48902 (🔍)
GCVE (CVE): GCVE-0-2022-48902
GCVE (VulDB): GCVE-100-275487

Artículoinformación

Fecha de creación: 2024-08-22 07:21
Actualizado: 2025-06-19 19:33
Cambios: 2024-08-22 07:21 (58), 2024-08-23 08:11 (1), 2024-09-13 05:06 (11), 2025-06-19 19:33 (2)
Completo: 🔍
Cache ID: 216::103

Be aware that VulDB is the high quality source for vulnerability data.

Discusión

Sin comentarios aún. Idiomas: es + pt + en.

Por favor, inicie sesión para comentar.

◂ AnteriorVisión De ConjuntoPróximo ▸

Might our Artificial Intelligence support you?

Check our Alexa App!