Corrupción de memoria: desbordamientos, use-after-free y más
Guía en castellano sobre corrupción de memoria: desbordamiento de búfer, lecturas fuera de límites, use-after-free y desbordamiento de enteros.
Qué es
Los lenguajes como C y C++ dejan en manos del programador la gestión de la memoria: cuánto reservar, dónde escribir y cuándo liberarla. Un error en cualquiera de esos pasos hace que el programa lea o escriba donde no debe. A esto se le llama corrupción de memoria.
Según el caso, el resultado va de un simple cierre del programa a la lectura de datos de otros usuarios o la ejecución de código del atacante.
Tipos más comunes
- Desbordamiento de búfer (buffer overflow): se escriben más datos de los que caben en un espacio reservado, en la pila o en el montón (heap), y se pisan datos vecinos.
- Lectura fuera de límites (out-of-bounds read): se lee más allá del final de un búfer y se filtra memoria del proceso. Heartbleed, en OpenSSL, es el ejemplo más conocido.
- Uso tras liberar (use-after-free): el programa sigue usando memoria que ya liberó y que puede haberse reutilizado para otra cosa.
- Desbordamiento de enteros: un cálculo de tamaño da la vuelta y se reserva mucha menos memoria de la necesaria.
- Doble liberación y punteros nulos, que suelen acabar en cierres del programa.
Dónde aparece
- Analizadores de formatos: imágenes, vídeo, documentos, archivos comprimidos y protocolos de red.
- Navegadores, intérpretes de lenguajes, librerías de sistema y software embebido.
- Cualquier código que procese datos externos sin validar longitudes.
Cómo se busca
- Fuzzing: generar millones de entradas modificadas y ver cuáles hacen fallar el programa. Herramientas como AFL++ o libFuzzer lo automatizan.
- Compilar con detectores como AddressSanitizer, que señalan el acceso incorrecto exacto en lugar de un cierre genérico.
- Revisar el código en busca de copias sin comprobar el tamaño (
memcpy,strcpy) y cálculos de longitudes.
Cómo se evita
- Lenguajes con gestión segura de memoria (Rust, Go, Java…) para el código nuevo que procese datos externos.
- Funciones con límite de tamaño y comprobaciones explícitas de longitudes y desbordamientos de enteros.
- Fuzzing continuo en las librerías críticas.
- Protecciones del sistema (ASLR, pilas no ejecutables, canaries) que no eliminan el fallo pero dificultan explotarlo.
Al reportarlo
Incluye el fichero o la entrada que provoca el fallo, la salida del sanitizador y la versión exacta. Si solo provoca un cierre, dilo: la severidad cambia mucho según se pueda leer memoria o controlar la ejecución.
Casos reales de Corrupción de memoria
Ver los 8 →MariaDB Connector/C: lectura fuera de límites en unpack_fields() con metadatos de columna truncados
Un servidor malicioso podía enviar al cliente un campo de metadatos de columna de menos de 12 bytes y provocar que unpack_fields() leyera memoria fuera del búfer, con fuga limitada de memoria o caída del proceso.
4 min
curl: use-after-free en el pool de conexiones compartido al recibir un HTTP/2 server push (CVE-2026-18924)
Si una aplicación comparte conexiones con CURLSH y acepta un server push de HTTP/2, libcurl libera una conexión que sigue enlazada en el pool compartido y después vuelve a leerla.
5 min
CVE-2026-80229: uso tras liberación en libcurl con OpenSSL 3.x al reutilizar conexiones TLS con CURLOPT_SSLENGINE
libcurl liberaba el contexto de librería de OpenSSL al limpiar un handle, aunque una conexión TLS guardada en el pool seguía apuntando a él; reutilizarla desde otro handle provocaba un use-after-free.
3 min
Desbordamiento de pila en ST_GeomFromGeoJSON de MariaDB: un usuario autenticado tumba todo el servidor
La función ST_GeomFromGeoJSON de MariaDB no limitaba la recursión al procesar GeometryCollection anidadas. Un GeoJSON muy profundo agotaba la pila y hacía caer el proceso mysqld entero.
4 min
Desbordamiento de pila en MariaDB permite tumbar el servidor con un solo SET
Un identificador de charset o colación demasiado largo desbordaba un búfer de pila en MariaDB, permitiendo a cualquier usuario autenticado colgar todo el proceso mariadbd con una sola sentencia SQL.
2 min
Use-after-free en el índice BTREE de tablas MEMORY de MariaDB por un key_version que nunca se incrementa
heap_update() nunca marca como cambiada la key_version de las tablas MEMORY, así que los cursores HANDLER siguen usando punteros de árbol ya liberados. Un usuario autenticado puede provocar un use-after-free y leer memoria arbitraria del servidor.
5 min