Saltar al contenido
folhas.io
secure by design para productos conectados· Artículos

Artículos

El resto de la pila: kernel Linux, Python y certificados

La semana de PHP2Shell trajo también correcciones para el kernel Linux, para Python y para el almacén de certificados. Para quien fabrica, la pregunta es la misma en las tres capas: por qué camino, y con qué retraso, llega la corrección a los aparatos ya vendidos.

Publicado

El artículo 09 siguió las correcciones de PHP y de Node.js del 21 oct 2026. La misma semana trajo trabajo para el resto de la pila de un aparato conectado: dos rondas de fallos en el kernel Linux, nuevas versiones de seguridad de Python, con una corrección de tarfile todavía por publicar, y el compromiso de ocho autoridades de certificación intermedias de eMudhra, que obligó a tocar los almacenes de certificados de navegadores, sistemas operativos y lenguajes.

Este texto es un registro defensivo, escrito desde el lado de quien fabrica: qué es cada caso, a quién afecta, qué versiones lo corrigen y qué verificar en el producto. Los detalles de explotación quedan fuera. Los estados citados son los del 23 oct 2026, y algunos van a cambiar en los próximos días.

La pila de un aparato conectado en cuatro capas, con lo que salió en octubre de 2026 y quién entrega la corrección. Aplicación y agente de actualización: tarfile y ssl de Python, con correcciones publicadas entre el 30 de septiembre y el 21 de octubre y la CVE-2026-114583 todavía sin versión corregida el 23 de octubre; la versión corregida viene de CPython, y la parte que corresponde a la aplicación es del propio fabricante: server_hostname, filter='data' y firma verificada antes de extraer. Runtimes Python, Node.js y PHP: Python 3.10 en fin de vida desde el 1 de octubre, 3.11 y 3.12 sin pip nuevo; la corrección viene del proyecto de origen, a través de la distribución o del sistema de build. Almacén de certificados grabado en el firmware: raíz emSign ECC G3 retirada en NSS 3.131.1 y en certifi 2026.10.19, intermedias de eMudhra revocadas; la corrección viene de Mozilla, de certifi y de las distribuciones, y solo llega al aparato con una actualización. Kernel Linux del BSP del proveedor del SoC: PwnEscape corregido el 15 de octubre, Infinity Core con exploits públicos el 16 de octubre y correcciones en el kernel estable desde el 27 de agosto; la corrección viene del proveedor del SoC a partir de kernel.org, con la pregunta de qué rama y con qué retraso. Debajo, la actualización del fabricante es el único camino hasta los aparatos ya vendidos, en cualquier capa.
Cada capa tiene su propio camino de corrección, y el del kernel suele pasar por el BSP del proveedor del SoC.

PwnEscape: el kernel del anfitrión

La CVE-2026-99999, conocida como PwnEscape, fue publicada el 15 oct 2026 por la CNA del kernel Linux con el título «ipv4: validate checksum_start before completing checksum». Es un fallo en la pila IPv4: un paquete con metadatos de checksum no válidos puede llevar al kernel a corromper la cabecera de red. El mensaje del commit describe la corrección como defensa en profundidad y dice que una validación más completa a la entrada todavía necesita trabajo. Según la CNA, el fallo existe desde Linux 2.6.27, de 2008.

Lo encontró Paulos Yibelo (PWNAI Research), en el desafío que Vercel lanzó el 18 ago 2026 sobre su servicio de sandboxes. Vercel dice que fue el hallazgo más grave del programa y distingue qué se vio y dónde: la fuga continua de memoria del anfitrión se demostró contra sandboxes de producción, mientras que la caída del anfitrión y la ejecución de comandos con privilegios de administrador solo se demostraron en máquinas del investigador, configuradas como el servicio. Ningún informe mostró acceso a datos de clientes.

El kernel que hay que actualizar es el del anfitrión. AWS pide actualizar y reiniciar los anfitriones KVM de quien gestiona sus propias máquinas virtuales con virtio-net, incluido Firecracker, dice que EC2, Lambda y Fargate no están afectados y que no hay solución alternativa. Red Hat admite dos tipos de atacante, una máquina virtual invitada no confiable o un atacante local, y tampoco conoce ninguna mitigación que cumpla sus criterios. La CNA subraya que no se trata de una ruta de recepción desde Internet.

Las evaluaciones divergen. La CNA del kernel le da 9,3 en CVSS 3.1 (crítica) y Red Hat 8,8 en la misma escala (importante), una diferencia que, según Red Hat, está solo en los privilegios requeridos. Ubuntu le asigna prioridad media.

Las versiones estables corregidas salieron todas el 15 oct 2026: 7.2.11, 6.18.57, 6.12.113, 6.6.159, 6.1.190, 5.15.223 y 5.10.272. En la línea principal, la corrección está en la 7.3, del 18 oct. En las distribuciones, a 23 oct, Debian ya la había corregido en trixie (16 oct) y en bookworm (17 oct), y Red Hat en RHEL 10 (19 oct) y en RHEL 9 (20 oct). El kernel principal de RHEL 8 seguía sin corrección, y Ubuntu todavía no había publicado un paquete corregido.

Para un fabricante, la pregunta es si el producto ejecuta código de terceros en máquinas virtuales sobre Linux, como una pasarela que aloja cargas de trabajo de clientes. Un aparato de función única, sin máquinas virtuales, queda fuera del escenario que describe la CNA. Red Hat habla también de un atacante local y lo puntúa con privilegios bajos (PR:L), sin describir qué acceso concreto hace falta. Para un producto que permite instalar aplicaciones de terceros, esa es una pregunta que hay que plantear al proveedor del kernel. Puede quedar dentro del escenario la infraestructura del propio fabricante: la nube que recibe los aparatos y los servidores de build, si ejecutan máquinas virtuales o microVM autogestionadas.

Infinity Core: exploits para correcciones con semanas

El 16 oct 2026, terminado el embargo acordado con la lista linux-distros, Hyunwoo Kim publicó en oss-security el conjunto al que llamó Infinity Core: seis fallos en los subsistemas Timer, Signal, MM, Futex, Scheduler y SLAB del kernel, que según el autor sirven para escalar privilegios en servidores Linux y en Android y para salir de contenedores. En el repositorio público del investigador, cinco de los seis tienen una prueba de concepto que lleva una cuenta sin privilegios a root; el sexto (SLAB) solo tiene un disparador que detiene el kernel. El fallo de Timer se usó también para obtener root en un Samsung Galaxy S26 Ultra desde una aplicación sin permisos adicionales. Ese exploit no se ha publicado, pero el investigador dice que lo publicará cuando los Galaxy estén corregidos, o antes, si un tercero publica uno. El boletín de seguridad de Android de octubre, del 5 oct, no incluye ninguno de los seis.

Lo que hace el caso relevante para quien fabrica es el calendario. Las correcciones estaban en parte de las ramas estables de kernel.org mucho antes de la divulgación:

FalloCVEAfecta desdePrimeras versiones estables corregidasDías hasta el 16 oct
FutexCVE-2026-807756.176.18.47, 7.1.11, 7.2.1 (27 ago)50
MMCVE-2026-897547.0 (y 6.18.21 a 6.18.49; 6.19.11 y siguientes, rama sin mantenimiento y sin corrección)6.18.50, 7.2.4 (7 sep)39
SLABCVE-2026-979417.27.2.7 (21 sep)25
TimerCVE-2026-982605.76.18.54, 7.2.8 (25 sep); 6.6.158, 6.12.112 (3 oct)21
SignalCVE-2026-982566.156.18.54, 7.2.8 (25 sep)21
SchedulerCVE-2026-983857.27.2.9 (3 oct)13

Los seis registros CVE ya eran públicos antes del 16 oct (el último, el de Scheduler, el 12 oct), con títulos de commit que no hablan de escalada de privilegios. Quien aplicaba las versiones estables completas de las ramas 6.6, 6.12, 6.18 y 7.2 ya tenía las correcciones antes de que los exploits fueran públicos. En las ramas 6.1, 5.15 y 5.10, a las que el fallo de Timer también afecta, la corrección todavía no había salido el 23 oct.

Las distribuciones no estaban todas en el mismo punto. Debian corrigió el fallo de Timer en trixie el 16 oct y en bookworm el 17 oct, y los otros cinco no existen en el código de sus versiones estables. Red Hat corrigió Timer y Signal en RHEL 10 el 19 oct y Timer en RHEL 9 el 20 oct; el de Futex seguía sin corrección en el kernel de RHEL 10. Ubuntu 26.04, en cuyo kernel el investigador probó cuatro de las pruebas de concepto, no tenía el 23 oct aviso de seguridad publicado para ninguno de los cuatro fallos que le afectan, solo el estado «en curso». La rama 7.0 en la que se basa ese kernel ya no se mantiene en kernel.org (la última versión, 7.0.14, salió el 27 jun 2026), y por eso cada corrección depende de que Canonical haga el backport. Ninguno de los seis figura en el catálogo KEV de la CISA (versión del 21 oct).

¿Y el kernel del aparato?

En un aparato embebido, el kernel viene muchas veces del BSP del proveedor del SoC, derivado de una rama de kernel.org y con cambios propios. Un estudio presentado en USENIX Security 2026 (Badola et al.), sobre 900 firmwares de 306 equipos de pequeña oficina y hogar, encontró 11 de 40 kernels de SDK de SoC en ramas Linux ya en fin de vida cuando se usaron, y solo en 12 de 174 casos el firmware final tenía un kernel más reciente que el del SDK. Los cinco fabricantes de SoC del estudio usaron todos SDK con kernels que llevaban más de un año en fin de vida. Datos más antiguos sobre Android (USENIX Security 2021) apuntan en el mismo sentido: cerca de la mitad de las CVE solo llegaban corregidas a los aparatos de los fabricantes 200 días o más después de la corrección en origen.

No hemos encontrado avisos públicos de proveedores de SoC sobre las CVE de este texto. Las preguntas quedan del lado del fabricante, y conviene hacerlas por escrito:

  1. ¿De qué rama de kernel.org deriva el kernel del BSP, y hasta qué versión estable está sincronizado?
  2. ¿Con qué retraso integra el proveedor las versiones estables, y por qué canal avisa a los clientes?
  3. ¿Están ya en el BSP las correcciones de la CVE-2026-99999 y de la CVE-2026-98260? En las ramas 6.1, 5.15 y 5.10, la segunda todavía no había salido en kernel.org el 23 oct: para la 6.1 estaba en la cola de revisión estable desde el 3 oct, para la 5.15 y la 5.10 ni eso.
  4. ¿Qué pasa con el BSP cuando la rama llegue al fin de vida? En kernel.org, la 5.10 y la 5.15 terminan en diciembre de 2026, la 6.1 y la 6.6 en diciembre de 2027, la 6.12 y la 6.18 en diciembre de 2028.

El número de versión no basta para responder a la tercera. La CNA del kernel solo asigna CVE a las versiones que mantiene el equipo estable, deja al usuario la decisión sobre la aplicabilidad y recomienda aplicar versiones estables completas en lugar de correcciones sueltas. Los intervalos «afectado» de los registros no describen, por tanto, un kernel de proveedor fuera de esas ramas. Y los backports trastocan la numeración en los dos sentidos. El fallo MM solo existe en la línea principal a partir de la 7.0, pero un backport lo llevó a la 6.18, de la 6.18.21 a la 6.18.49, y a la 6.19, a partir de la 6.19.11; RHEL 9, con kernel base 5.14, tenía el de Futex, que en origen solo existe desde la 6.17. Conviene que la SBOM del artículo 01 registre la rama y los parches aplicados, y el estado de cada CVE en el producto puede comunicarse en VEX.

Cuando el fin de vida de la rama cae antes del final del período de soporte que declara el fabricante, hace falta otra vía. Civil Infrastructure Platform, de la Linux Foundation, mantiene kernels SLTS para uso industrial, con fin de vida previsto para enero de 2031 (5.10), agosto de 2033 (6.1) y junio de 2035 (6.12). Las alternativas son migrar de rama durante la vida del producto o contratar ese soporte al proveedor.

Python: el ssl de la conexión a la nube y el tarfile de las actualizaciones

Dos módulos de Python tocan directamente lo que un aparato hace por sí solo: ssl, debajo de muchas conexiones a la nube, y tarfile, que muchos agentes de actualización usan para abrir paquetes.

Entre el 30 sep y el 1 oct 2026 salieron las versiones 3.10.22, 3.11.17, 3.12.15, 3.13.16 y 3.14.8. La 3.10.22, del 1 oct, es la última de la rama 3.10, que llegó al fin de vida ese día y no tendrá más correcciones de seguridad. Por el lado de ssl, dos correcciones interesan a quien fabrica.

La CVE-2026-19553 afecta a clientes. SSLContext.wrap_bio() no exigía server_hostname cuando check_hostname estaba activo, y en ese caso la verificación del nombre en el certificado se omitía en silencio; quien pasa un server_hostname no vacío no está afectado. La PSF la clasifica como alta, con 7,6 en CVSS 4.0. La corrección no es igual en todas las ramas: en la 3.10, la 3.11 y la 3.12, la omisión pasa solo a generar un aviso de obsolescencia, por compatibilidad, y solo a partir de la 3.13 da error. En esas ramas, actualizar Python no basta. La mitigación oficial es pasar siempre un server_hostname válido a wrap_bio(), a asyncio.create_connection() y a loop.start_tls().

La CVE-2026-19445 afecta a servidores. Un cliente TLS remoto, sin autenticación, puede hacer caer el proceso, o llevarlo a usar memoria ya liberada, cuando el sni_callback cambia de contexto y nada más mantiene vivo el contexto original. La PSF la clasifica como crítica, con 9,2 en CVSS 4.0. Interesa, por ejemplo, a un aparato que sirva una interfaz local por HTTPS desde Python, elija el certificado según el nombre solicitado con sni_callback y cree el contexto con ese callback en cada conexión, o lo sustituya con conexiones abiertas. Un servidor que envuelve el socket de escucha con ese contexto no está afectado. La mitigación es mantener una referencia a cada SSLContext que define sni_callback durante toda la vida del servidor.

Por el lado de tarfile, las mismas versiones cerraron tres fallos en los filtros de extracción (CVE-2026-82049, CVE-2026-87910 y CVE-2026-19672); la CVE-2026-87910 solo llegó a la rama 3.14 con la 3.14.9, del 21 oct. El 22 oct, la PSF anunció uno más, la CVE-2026-114583: el filtro tar podía eludirse mediante entradas de enlace manipuladas en un archivo malicioso y escribir ficheros fuera del directorio de destino, dentro de los permisos del proceso. La PSF le da gravedad media, con 6,9 en CVSS 4.0. El 23 oct, la corrección estaba integrada en la rama principal y en las ramas 3.15 y 3.14, los backports para la 3.13, la 3.12 y la 3.11 esperaban integración, y ninguna versión publicada la incluía. La 3.10 no está en la lista.

La documentación oficial recomienda el filtro data. Desde la 3.14 es el filtro por defecto; antes, la extracción confiaba totalmente en el archivo, y para la 3.13 y anteriores se recomienda definir filter='data' explícitamente. Al propio filtro data se le corrigieron este año otras formas de eludirlo, en junio (la CVE-2026-7774, equivalente a la CVE-2026-114583 en el filtro data) y en estas versiones, y solo protege en una versión que ya incluya esas correcciones. Ningún filtro bloquea todas las funcionalidades peligrosas, y los archivos de fuentes no confiables no se extraen sin inspección. En un agente de actualización, esto se traduce en un orden de operaciones: verificar la firma del paquete antes de extraer nada. Así, quien no tiene la clave de firma no consigue hacer llegar un archivo suyo al código que extrae.

La rama también cuenta. La 3.10 ya no recibe correcciones de ningún tipo. La 3.11 tiene correcciones de seguridad hasta octubre de 2027, la 3.12 hasta octubre de 2028 y la 3.13 hasta octubre de 2029, y en las ramas solo de seguridad las versiones son, por regla general, solo de código fuente. Un producto que declare en 2026 cinco años de período de soporte con Python 3.11 dentro tendrá que cambiar de rama a mitad del período, o asumir las correcciones por su cuenta.

Los certificados grabados en el firmware

El 17 oct 2026, un investigador de la comunidad comunicó a los programas de certificados raíz de Apple, Google, Microsoft y Mozilla que las claves privadas de ocho autoridades de certificación intermedias de eMudhra se habían generado con aleatoriedad insuficiente; eMudhra fue informada el mismo día. Según Google, eso permitía a cualquiera falsificar certificados HTTPS de confianza para cualquier sitio web, ante clientes que todavía confiaran en esas intermedias. Seis se destinan a TLS y dos a firma de código. Chrome y Firefox las bloquearon el mismo día mediante sus propios mecanismos (CRLSet y OneCRL), y eMudhra revocó las ocho el 18 oct.

Según eMudhra, solo una estaba en producción y ninguna emitió certificados de entidad final; la empresa dice no conocer indicios de que las claves débiles se hayan recuperado o explotado antes de la divulgación. Hasta el 19 oct, según Mozilla, los registros de Certificate Transparency tampoco mostraban certificados de estas intermedias. La página del incidente recuerda que las claves podían recuperarse a partir de los certificados desde que estos se crearon, en abril de 2025, y que no se sabe si alguien lo hizo contra clientes que no exigen Certificate Transparency. Mozilla considera probable el abuso de las claves a corto plazo. Los navegadores exigen Certificate Transparency. Muchos clientes fuera de los navegadores no la exigen ni consultan revocaciones, y para ellos la protección llega con una actualización de software.

Esa actualización es la retirada de confianza en el almacén. NSS 3.131.1, del 20 oct, retira tres raíces emSign, una de ellas por el incidente: la «emSign ECC Root CA - G3», a la que las intermedias encadenan mediante una firma cruzada (las emitieron otras dos raíces de eMudhra, que Mozilla no incluye), y Chrome la retira de su almacén en una versión prevista para el 27 oct. A quien mantiene almacenes sin forma de dejar de confiar en intermedias concretas, Mozilla le recomienda que considere retirar tres raíces (AAA Certificate Services, emSign Root TLS CA - G3 y emSign ECC Root CA - G3), aunque algunos servidores legítimos dejen de ser accesibles. El 20 oct, Debian (DSA-6572-1) bloqueó en ca-certificates la emSign ECC Root CA - G3 y la AAA Certificate Services, y Ubuntu retiró la emSign ECC Root CA - G3 y, en las versiones 14.04 a 20.04, también la AAA, que ya no figuraba en las versiones 22.04 y posteriores. Red Hat publicó el boletín RHSB-2026-012 el 21 oct y una actualización para RHEL 10 el 22 oct (RHSA-2026:88455).

Los ecosistemas de lenguaje traen almacenes propios, y cada uno necesitó corrección:

  • Python. certifi 2026.10.19 y pip 26.2.2 salieron el 20 oct, y las versiones 3.15.1, 3.14.9 y 3.13.17, del 21 oct, pasaron a incluir ese pip. Christian Heimes, desarrollador del núcleo de CPython, recuerda que pip carga siempre el certifi que lleva integrado, además del almacén del sistema, por lo que retirar la confianza solo en el sistema operativo no basta. La 3.11 y la 3.12 no van a recibir el pip nuevo; en esas ramas se actualiza a mano, entorno por entorno. CPython prepara además, como defensa en profundidad, una lista de bloqueo de las claves de estas intermedias en el módulo ssl, con backport solicitado hasta la 3.11; el 23 oct todavía no estaba integrada.
  • Node.js. Las versiones de seguridad del 21 oct, tratadas en el artículo 09, incluyen la actualización de los certificados raíz.
  • Go. Las versiones 1.27.3 y 1.26.10 añaden a crypto/x509 una lista de bloqueo para estas intermedias (CVE-2026-111943). Como la lista vive en la biblioteca estándar, un binario Go solo la obtiene cuando se recompila.

Para quien fabrica, la pregunta concreta es de dónde vienen los almacenes de certificados grabados en el firmware y cómo se actualizan. Las raíces emSign entraron en el ca-certificates de Debian en 2020, y el aviso de certifi da como afectadas todas las versiones desde 2019, así que un firmware construido desde entonces con un almacén derivado del de Mozilla tiene probablemente la raíz ahora retirada. Las ocho intermedias tienen también firma cruzada de Sectigo, de mayo de 2025, bajo la raíz AAA Certificate Services, que estuvo muchos años en los almacenes derivados del de Mozilla y sigue en los de Apple y Microsoft. Un firmware con uno de esos almacenes que no consulte revocaciones confía probablemente en estas claves, sea cual sea la fecha en que se construyó. En un almacén antiguo, retirar solo la emSign ECC Root CA - G3 no basta: o se pasa al almacén actual completo, o se retiran las tres raíces que indica Mozilla. Si el almacén solo cambia con una imagen de firmware nueva, cada retirada de una raíz obliga a un ciclo completo de actualización.

El almacén entra en la SBOM como componente, con origen y fecha, y necesita un camino de actualización, propio o dentro de cada actualización OTA. En la conexión a la nube del propio fabricante, el aparato puede confiar solo en las autoridades que usa esa conexión, siempre que quede previsto cómo sustituirlas; un incidente en una autoridad que la conexión no usa deja entonces de pesar sobre ella. Falta el lado del build: la PSF recomienda reconstruir las imágenes de contenedor sin caché de capas y actualizar pip en todos los entornos virtuales, lo que vale también para las imágenes que construyen el firmware.

¿Obliga esto a notificar?

El artículo 14 del CRA obliga a notificar dos cosas: las vulnerabilidades aprovechadas activamente presentes en el producto (apartado 1) y los incidentes graves que repercutan en la seguridad del producto (apartado 3). El producto incluye sus soluciones de procesamiento remoto de datos (artículo 3, punto 1), y las orientaciones de la Comisión de 27 jul 2026, C(2026) 5252, que no son vinculantes, les aplican también el artículo 14 (punto 178). El mismo documento deja fuera de ese concepto los pipelines de CI/CD y la distribución de actualizaciones de seguridad (punto 182). Un compromiso de los servidores de build o de actualización capaz de introducir código malicioso en el producto es, aun así, un incidente grave (artículo 14, apartado 5, letra b)), con notificación de alerta temprana en 24 horas y notificación de incidente en 72 horas.

A 23 oct 2026, ninguna de las CVE citadas en este texto figura en el catálogo KEV de la CISA (versión del 21 oct). En el registro de PwnEscape, la evaluación de la CISA del 16 oct indica que no hay explotación conocida. Red Hat escribe que sigue el fallo como caso KEV de explotación activa, sin indicar la fuente y sin que haya entrada en el catálogo de la CISA. La demostración contra sandboxes de producción que relata Vercel se hizo en el desafío que lanzó la propia Vercel, con autorización. El CRA solo considera aprovechada activamente una vulnerabilidad cuando hay pruebas fiables de que un agente malintencionado la ha aprovechado sin autorización del propietario del sistema (artículo 3, punto 42), y no hemos encontrado ninguna fuente primaria que relate una explotación de ese tipo. Para un producto que esté en el escenario descrito en la sección de PwnEscape, esa divergencia es materia para el triaje.

Los exploits públicos de Infinity Core muestran que los fallos pueden explotarse, pero no son, por sí solos, prueba de que un agente malintencionado los haya explotado. En el caso de eMudhra, la empresa dice no conocer indicios de explotación antes de la divulgación, Mozilla considera probable el abuso de las claves a corto plazo, y la página del incidente dice que no se sabe si hubo explotación contra clientes que no exigen Certificate Transparency.

Según las mismas orientaciones (punto 218), si el código vulnerable de un componente no es alcanzable en el producto, o si no ha habido explotación en él, no hay notificación obligatoria para ese fabricante. En ese caso, el fabricante puede aun así notificar de forma voluntaria (artículo 15). Para el triaje, la explotación del mismo componente en otros sistemas es una señal que hay que tener en cuenta. Si el triaje concluye que ha habido explotación en el producto, se abre el calendario del artículo 14: notificación de alerta temprana en 24 horas, notificación de vulnerabilidad en 72 horas e informe final, a través de la plataforma única de notificación. El artículo 02 describe el circuito.

Nota de rigor. El estado de explotación descrito aquí es el que indicaban las fuentes citadas el 23 oct 2026, y puede cambiar. Las orientaciones C(2026) 5252 no son vinculantes. La decisión sobre si ha habido explotación activa en un producto concreto corresponde al fabricante, a partir de su propio triaje, y este texto no sustituye esa evaluación ni el asesoramiento jurídico.

Por dónde empezar

Esta semana, la SBOM tiene que responder a tres preguntas: qué kernel hay en el aparato, de qué rama y con qué parches; qué Python y qué pip, en el aparato y en las imágenes de build; qué almacenes de certificados hay en el firmware (el del sistema y los integrados, como el certifi de las aplicaciones Python, el de Node.js o la lista de bloqueo compilada en los binarios Go), y de cuándo son. Si la SBOM todavía no tiene estas respuestas, completarla es el primer paso.

Después, para cada corrección que se aplique, la pregunta es cómo llega a los aparatos ya vendidos. Kernel nuevo del proveedor, Python corregido o almacén de certificados actualizado, todos necesitan el mismo camino: una actualización firmada, por OTA o local, disponible durante todo el período de soporte declarado. Al proveedor del SoC se le hacen las cuatro preguntas de la sección del kernel, por escrito y con fecha.

En la mayor parte de los casos de este mes, la corrección en origen ya existe. El tramo que falta, entre el fabricante y el aparato, solo puede recorrerlo el fabricante.

Fuentes