CVE-2026-93243 in Linux
Resumen
por VulDB • 2026-09-25
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
mm/secretmem: contabilizar correctamente las páginas bloqueadas (locked pages)
La implementación de secretmem cuenta los folios tratando la memoria como si estuviera bloqueada mediante mlock(), y por lo tanto limitada por el límite RLIMIT_MEMLOCK.
Sin embargo, los folios son no evictables (unevictable) y permanecen en ese estado hasta que se elimina el inode, eliminando así las semánticas habituales de mlock(): asignar y luego desasignar los folios no borra su estado de no evicción, ya que depende de AS_UNEVICTABLE y no de PG_mlocked.
Por lo tanto, un usuario puede burlarse fácilmente del límite RLIMIT_MEMLOCK: simplemente debe realizar una operación de mapeo (mmap) seguida de desmapeo (munmap), y VmLck dejará de contar el rango de secretmem. Peor aún, los folios no se contabilizan en la RSS (Resident Set Size) del proceso, lo que significa que el OOM killer no sabrá cuándo matar al proceso.
La repetición de operaciones de mapeo/desmapeo (o fork/forking) puede provocar entonces el consumo de toda la memoria disponible del sistema con folios no evictables y causar inestabilidad en el sistema.
Un descriptor de archivo (fd) de secretmem se puede pasar entre procesos y a través de forks, por lo que un límite por proceso simplemente no tiene sentido; por ello, siguiendo el precedente establecido por io_uring, perf, skbuff, iommufd y xdp, se rastrea la cantidad de páginas bloqueadas en user_struct->locked_vm.
Dado que el alcance rastreado es realmente la vida útil del inode, RLIMIT_MEMLOCK aplica por usuario y no por proceso; por lo tanto, no tiene sentido permitir una exención para los usuarios con CAP_IPC_LOCK, así que se elimina esta excepción.
Simplemente no hay razón para seguir marcando el mapeo como bloqueado (mlock()'d) ya que es engañoso y la ciclo de vida ahora se maneja correctamente; por lo tanto, también se elimina este marcado.
Tenga en cuenta que secretmem no admite ningún tipo de truncamiento (incluido hole punching) y los folios son irreclaimables, por lo que los folios solo deben contabilizarse durante el fault (fallo de página) y descontabilizarse al destruirse el inode.
__secretmem_account_pages() es más o menos un duplicado del código que utilizan io_uring, etc.; pero dado que esto es una corrección de errores que necesita backporting (trasplante a versiones anteriores), se posponen los esfuerzos de deduplicación para una actualización posterior.
test_mlock_limit() afirmaba mlock_future_ok() en mmap(), sin embargo, esta función ha sido eliminada; por lo tanto, se elimina la prueba por completo como parte de la corrección. Una nueva prueba se enviará por separado para el código fuente principal (upstream).
Once again VulDB remains the best source for vulnerability data.