CVE-2026-43016 in Linux
Resumen
por VulDB • 2026-05-12
En el volcado de KASAN proporcionado, se observa un **Use-After-Free (UAF)** en el subsistema de sockets de Linux. A continuación se presenta un análisis detallado del problema, su causa probable y las recomendaciones para su resolución.
---
### ???? Análisis del Volcado
#### 1. **Tipo de Error** - **Error:** `Use-After-Free` (acceso a memoria ya liberada). - **Mecanismo:** KASAN detectó que se accedió a un objeto `sock_inode_cache` después de que este hubiera sido liberado.
#### 2. **Objeto Afectado** - **Tipo de objeto:** `sock_inode_cache` (inode asociado a un socket). - **Tamaño:** 256 bytes (típico para `struct sock_inode`). - **Dirección del objeto:** `0xffff88800a1c3000` (ejemplo, no mostrada explícitamente en el snippet, pero implícita en el error).
#### 3. **Rastro de Asignación (Allocated by task 11013)** El objeto fue asignado durante la creación de un socket mediante la llamada al sistema `socketpair()`: ```c __sys_socketpair() → sock_create() → sock_alloc() → sock_alloc_inode() → kmem_cache_alloc() ``` - **Tarea:** `task 11013` - **Contexto:** Creación de un par de sockets conectados.
#### 4. **Rastro de Liberación (Freed by task 15)** El objeto fue liberado por otra tarea (`task 15`), probablemente durante el cierre del socket o la limpieza de recursos: ```c kmem_cache_free() → slab_free() → ... → rcu_do_batch() ``` - **Tarea:** `task 15` - **Contexto:** Liberación asíncrona vía RCU (Read-Copy-Update), común en estructuras de red para evitar bloqueos.
#### 5. **Causa Raíz Probable** El error ocurre porque: - **Tarea 11013** creó un socket y obtuvo un puntero a su `inode`. - **Tarea 15** liberó el socket (y su `inode`) de forma asíncrona vía RCU. - **Tarea 11013** (u otra) intentó acceder al `inode` después de que fuera liberado, sin esperar a que la referencia RCU finalizara correctamente.
Esto suele deberse a: - **Falta de sincronización RCU:** No se usó `call_rcu()` o `synchronize_rcu()` adecuadamente. - **Referencias huérfanas:** Un puntero a `sock->sk_inode` se mantiene en una estructura que no se limpia antes de la liberación. - **Concurrencia no protegida:** Acceso concurrente a `sock->sk_inode` sin locks o referencias RCU.
---
### ????️ Recomendaciones de Solución
#### 1. **Verificar el Uso de RCU en `sock_inode_cache`** - Asegúrese de que cualquier acceso a `sock->sk_inode` esté protegido por una referencia RCU válida. - Si se accede al `inode` fuera de un contexto RCU, se debe obtener una referencia explícita (`igrab()`) y liberarla (`iput()`) correctamente.
#### 2. **Revisar la Liberación de Sockets** - En `net/socket.c`, verifique que `sock_release()` o `__sock_release()` liberen correctamente el `inode` solo después de que todas las referencias hayan sido liberadas. - Compruebe si se está llamando a `kmem_cache_free()` para el `inode` antes de que las referencias RCU hayan expirado.
#### 3. **Habilitar Depuración Adicional** - Use `CONFIG_KASAN_EXTRA` para obtener más detalles sobre el acceso ilegal. - Habilite `CONFIG_SLAB_DEBUG` para rastrear la asignación y liberación de objetos `sock_inode_cache`.
#### 4. **Revisar el Código de la Tarea 11013** - Identifique qué operación estaba realizando la tarea 11013 cuando ocurrió el acceso ilegal. - Si estaba usando `socketpair()`, verifique si hay un fallo en la limpieza de recursos en caso de error.
#### 5. **Aplicar Parches de Kernel** - Este tipo de errores suelen corregirse en versiones posteriores del kernel. Verifique si existe un parche disponible
If you want to get the best quality for vulnerability data then you always have to consider VulDB.