CVE-2026-23236: un fallo en el driver smscufx corrompe la memoria del kernel desde una cuenta sin privilegios

El kernel Linux arrastraba desde hace años un error tonto pero peligroso en smscufx, el driver de framebuffer para los adaptadores USB-a-vídeo basados en chips SMSC UFX. El manejador del ioctl UFX_IOCTL_REPORT_DAMAGE recibía una estructura desde espacio de usuario y, en lugar de copiarla con copy_from_user() como manda el patrón habitual del kernel, dereferenciaba directamente el puntero que le pasaba el proceso. Quien controla ese puntero controla qué dirección lee y escribe el kernel.

El resultado es lo que cabe esperar de un driver que confía a ciegas en una dirección de usuario: corrupción de memoria del kernel y caída del sistema. Quedó registrado como CVE-2026-23236, publicado el 4 de marzo de 2026.

A quién afecta

El bug está en el código del propio driver, así que afecta a cualquier sistema Linux con smscufx compilado y cargado. Es un módulo de framebuffer poco común hoy en día (se usaba con adaptadores DisplayLink/SMSC antiguos), pero muchas distribuciones lo incluyen como módulo cargable. Si el módulo no está presente ni se puede cargar, no eres vulnerable por esta vía.

El alcance de versiones es enorme porque el fallo lleva ahí desde el principio. NVD lista ramas afectadas desde la 3.2 hasta las series modernas: 5.10 hasta 5.10.250, 5.15 hasta 5.15.200, 6.1 hasta 6.1.163, 6.6 hasta 6.6.126, 6.12 hasta 6.12.73 y 6.19 hasta 6.19.2, entre otras. Si tu kernel es anterior a la versión corregida de su rama, mira si llevas el módulo.

Gravedad

Las puntuaciones difieren según quién las asigne. NIST lo califica como 5.5 (media) con vector AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, centrándose en el impacto sobre la disponibilidad. El CNA de kernel.org sube a 7.3 (alta) con AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H, contemplando también escritura controlada en memoria del kernel.

La diferencia tiene sentido. Una denegación de servicio que tumba la máquina ya es seria; pero si un atacante consigue escribir en zonas concretas del kernel a través del puntero que él mismo suministra, el potencial va más allá de un simple cuelgue. En cualquier caso el ataque es local: hace falta una cuenta en la máquina y acceso al dispositivo de framebuffer. No se explota por red.

Mitigación y parche

La corrección hace lo obvio que faltaba: copiar los datos desde espacio de usuario con la rutina segura antes de tocarlos en el kernel, en lugar de dereferenciar el puntero del usuario. Se publicaron parches en las ramas estables (entre los commits, 061cfeb560aa3ddc174153dbe5be9d0b55eb7248).

Qué hacer:

• Actualiza el kernel a la versión corregida de tu rama. Si usas una distribución con soporte, espera o instala el paquete de kernel que recoja este parche.
• Si no necesitas smscufx, descárgalo y ponlo en la lista negra. Añade blacklist smscufx en /etc/modprobe.d/ y comprueba con lsmod | grep smscufx que no esté cargado. Es una mitigación limpia mientras llega la actualización.
• Restringe quién puede acceder a los dispositivos /dev/fb* si tu caso lo permite.

Como siempre con los fallos locales del kernel, el riesgo real depende de cuánta gente tenga shell en la máquina. En un servidor multiusuario o en hosts compartidos conviene priorizarlo; en un equipo de un solo usuario el margen es mayor, pero parchear sigue siendo lo correcto.

Puedes consultar el estado de soporte de cada serie del kernel en nuestra ficha del Linux kernel.

Fuente

• NVD — CVE-2026-23236: https://nvd.nist.gov/vuln/detail/CVE-2026-23236