Saltar para o conteúdo
folhas.io
secure by design para produtos ligados· Artigos

Artigos

O resto da pilha: kernel Linux, Python e certificados

A semana do PHP2Shell trouxe também correções para o kernel Linux, para o Python e para o repositório de certificados. Para quem fabrica, a pergunta é a mesma nas três camadas: por que caminho, e com que atraso, a correção chega aos aparelhos já vendidos.

Publicado

O artigo 09 acompanhou as correções ao PHP e ao Node.js de 21 out 2026. A mesma semana trouxe trabalho para o resto da pilha de um aparelho ligado: duas rondas de falhas no kernel Linux, novos lançamentos de segurança do Python, com uma correção ao tarfile ainda por lançar, e o comprometimento de oito autoridades de certificação intermédias da eMudhra, que obrigou a mexer nos repositórios de certificados de navegadores, sistemas operativos e linguagens.

Este texto é um registo defensivo, escrito do lado de quem fabrica: o que é cada caso, quem é afetado, que versões corrigem e o que verificar no produto. Detalhes de exploração ficam de fora. Os estados citados são os de 23 out 2026, e alguns vão mudar nos próximos dias.

A pilha de um aparelho ligado em quatro camadas, com o que saiu em outubro de 2026 e quem entrega a correção. Aplicação e agente de atualização: tarfile e ssl do Python, com correções lançadas entre 30 de setembro e 21 de outubro e a CVE-2026-114583 ainda sem versão corrigida a 23 de outubro; a versão corrigida vem do CPython, e a parte que cabe à aplicação é do próprio fabricante: server_hostname, filter='data' e assinatura verificada antes de extrair. Runtimes Python, Node.js e PHP: Python 3.10 em fim de vida desde 1 de outubro, 3.11 e 3.12 sem pip novo; a correção vem do projeto a montante, via distribuição ou sistema de build. Repositório de certificados gravado no firmware: raiz emSign ECC G3 retirada no NSS 3.131.1 e no certifi 2026.10.19, intermédias da eMudhra revogadas; a correção vem da Mozilla, do certifi e das distribuições, e só chega ao aparelho com atualização. Kernel Linux do BSP do fornecedor do SoC: PwnEscape corrigido a 15 de outubro, Infinity Core com exploits públicos a 16 de outubro e correções no kernel estável desde 27 de agosto; a correção vem do fornecedor do SoC a partir de kernel.org, com a pergunta sobre que ramo e com que atraso. Por baixo, a atualização do fabricante é o único caminho até aos aparelhos já vendidos, em qualquer camada.
Cada camada tem o seu caminho de correção, e o do kernel costuma passar pelo BSP do fornecedor do SoC.

PwnEscape: o kernel do anfitrião

A CVE-2026-99999, conhecida como PwnEscape, foi publicada a 15 out 2026 pela CNA do kernel Linux com o título «ipv4: validate checksum_start before completing checksum». É uma falha na pilha IPv4: um pacote com metadados de checksum inválidos pode levar o kernel a corromper o cabeçalho de rede. A mensagem do commit descreve a correção como defesa em profundidade e diz que uma validação mais completa à entrada ainda precisa de trabalho. Segundo a CNA, a falha existe desde o Linux 2.6.27, de 2008.

Encontrou-a Paulos Yibelo (PWNAI Research), no desafio que a Vercel lançou a 18 ago 2026 ao seu serviço de sandboxes. A Vercel diz que foi a descoberta mais grave do programa e separa o que foi visto onde: a fuga contínua de memória do anfitrião foi demonstrada contra sandboxes de produção, enquanto a queda do anfitrião e a execução de comandos com privilégios de administrador só foram demonstradas em máquinas do investigador, configuradas como o serviço. Nenhum relatório mostrou acesso a dados de clientes.

O kernel que tem de ser atualizado é o do anfitrião. A AWS manda atualizar e reiniciar os anfitriões KVM de quem gere as próprias máquinas virtuais com virtio-net, incluindo Firecracker, diz que o EC2, o Lambda e o Fargate não são afetados e que não há solução alternativa. A Red Hat admite dois tipos de atacante, uma máquina virtual convidada não confiável ou um atacante local, e também não conhece mitigação que cumpra os seus critérios. A CNA sublinha que não se trata de um caminho de receção a partir da Internet.

As avaliações divergem. A CNA do kernel dá-lhe 9,3 em CVSS 3.1 (crítica) e a Red Hat 8,8 na mesma escala (importante), uma diferença que, segundo a Red Hat, está só nos privilégios exigidos. O Ubuntu atribui-lhe prioridade média.

As versões estáveis corrigidas saíram todas a 15 out 2026: 7.2.11, 6.18.57, 6.12.113, 6.6.159, 6.1.190, 5.15.223 e 5.10.272. Na linha principal, a correção está no 7.3, de 18 out. Nas distribuições, a 23 out, o Debian já a tinha corrigido no trixie (16 out) e no bookworm (17 out), e a Red Hat no RHEL 10 (19 out) e no RHEL 9 (20 out). O kernel principal do RHEL 8 continuava sem correção, e o Ubuntu ainda não tinha publicado pacote corrigido.

Para um fabricante, a pergunta é se o produto corre código de terceiros em máquinas virtuais sobre Linux, como um gateway que aloja cargas de trabalho de clientes. Um aparelho de função única, sem máquinas virtuais, fica fora do cenário que a CNA descreve. A Red Hat fala também de um atacante local e pontua-o com privilégios baixos (PR:L), sem descrever que acesso concreto é preciso. Para um produto que deixa instalar aplicações de terceiros, essa é uma pergunta a pôr ao fornecedor do kernel. Pode ficar dentro do cenário a infraestrutura do próprio fabricante: a cloud que recebe os aparelhos e os servidores de build, se correrem máquinas virtuais ou microVMs autogeridas.

Infinity Core: exploits para correções com semanas

A 16 out 2026, terminado o embargo acordado com a lista linux-distros, Hyunwoo Kim publicou na oss-security o conjunto a que chamou Infinity Core: seis falhas nos subsistemas Timer, Signal, MM, Futex, Scheduler e SLAB do kernel, que segundo o autor servem para escalar privilégios em servidores Linux e em Android e para sair de contentores. No repositório público do investigador, cinco das seis têm prova de conceito que leva uma conta sem privilégios a root; a sexta (SLAB) tem apenas um gatilho que faz o kernel parar. A falha do Timer foi também usada para obter root num Samsung Galaxy S26 Ultra a partir de uma aplicação sem permissões adicionais. Esse exploit não foi publicado, mas o investigador diz que o publica quando os Galaxy forem corrigidos, ou antes disso, se um terceiro publicar um. O boletim de segurança do Android de outubro, de 5 out, não inclui nenhuma das seis.

O que torna o caso relevante para quem fabrica é o calendário. As correções estavam em parte dos ramos estáveis de kernel.org bem antes da divulgação:

FalhaCVEAfeta desdePrimeiras versões estáveis corrigidasDias até 16 out
FutexCVE-2026-807756.176.18.47, 7.1.11, 7.2.1 (27 ago)50
MMCVE-2026-897547.0 (e 6.18.21 a 6.18.49; 6.19.11 e seguintes, ramo sem manutenção e sem correção)6.18.50, 7.2.4 (7 set)39
SLABCVE-2026-979417.27.2.7 (21 set)25
TimerCVE-2026-982605.76.18.54, 7.2.8 (25 set); 6.6.158, 6.12.112 (3 out)21
SignalCVE-2026-982566.156.18.54, 7.2.8 (25 set)21
SchedulerCVE-2026-983857.27.2.9 (3 out)13

Os seis registos CVE já eram públicos antes de 16 out (o último, o do Scheduler, a 12 out), com títulos de commit que não falam em escalada de privilégios. Quem aplicava as versões estáveis inteiras dos ramos 6.6, 6.12, 6.18 e 7.2 já tinha as correções antes de os exploits serem públicos. Nos ramos 6.1, 5.15 e 5.10, que a falha do Timer também afeta, a correção ainda não tinha saído a 23 out.

As distribuições não estavam todas no mesmo ponto. O Debian corrigiu a falha do Timer no trixie a 16 out e no bookworm a 17 out, e as outras cinco não existem no código das suas versões estáveis. A Red Hat corrigiu Timer e Signal no RHEL 10 a 19 out e o Timer no RHEL 9 a 20 out; a do Futex continuava sem correção no kernel do RHEL 10. O Ubuntu 26.04, em cujo kernel o investigador testou quatro das provas de conceito, não tinha a 23 out aviso de segurança publicado para nenhuma das quatro que o afetam, só o estado «em curso». O ramo 7.0 em que esse kernel assenta já não é mantido em kernel.org (a última versão, 7.0.14, saiu a 27 jun 2026), e por isso cada correção depende de a Canonical a retroportar. Nenhuma das seis consta do catálogo KEV da CISA (versão de 21 out).

E o kernel do aparelho?

Num aparelho embebido, o kernel vem muitas vezes do BSP do fornecedor do SoC, derivado de um ramo de kernel.org e com alterações próprias. Um estudo apresentado no USENIX Security 2026 (Badola et al.), sobre 900 firmwares de 306 equipamentos de pequeno escritório e casa, encontrou 11 de 40 kernels de SDK de SoC em ramos Linux já em fim de vida quando foram usados, e só em 12 de 174 casos o firmware final tinha um kernel mais recente do que o do SDK. Os cinco fabricantes de SoC do estudo usaram todos SDK com kernels em fim de vida há mais de um ano. Dados mais antigos sobre Android (USENIX Security 2021) apontam no mesmo sentido: cerca de metade das CVE só chegava corrigida aos aparelhos dos fabricantes 200 dias ou mais depois da correção a montante.

Não encontrámos avisos públicos de fornecedores de SoC sobre as CVE deste texto. As perguntas ficam do lado do fabricante, e convém fazê-las por escrito:

  1. De que ramo de kernel.org deriva o kernel do BSP, e até que versão estável está sincronizado?
  2. Com que atraso o fornecedor integra as versões estáveis, e por que canal avisa os clientes?
  3. As correções da CVE-2026-99999 e da CVE-2026-98260 já estão no BSP? Nos ramos 6.1, 5.15 e 5.10, a segunda ainda não tinha saído em kernel.org a 23 out: para o 6.1 estava na fila de revisão estável desde 3 out, para o 5.15 e o 5.10 nem isso.
  4. O que acontece ao BSP quando o ramo chegar ao fim de vida? Em kernel.org, o 5.10 e o 5.15 terminam em dezembro de 2026, o 6.1 e o 6.6 em dezembro de 2027, o 6.12 e o 6.18 em dezembro de 2028.

O número de versão não chega para responder à terceira. A CNA do kernel só atribui CVE às versões que a equipa estável suporta, deixa ao utilizador a decisão sobre a aplicabilidade e recomenda aplicar versões estáveis inteiras em vez de correções avulsas. Os intervalos «afetado» dos registos não descrevem, portanto, um kernel de fornecedor fora desses ramos. E as retroportagens baralham a numeração nos dois sentidos. A falha MM só existe na linha principal a partir do 7.0, mas uma retroportagem levou-a para o 6.18, do 6.18.21 ao 6.18.49, e para o 6.19, a partir do 6.19.11; o RHEL 9, com kernel de base 5.14, tinha a do Futex, que a montante só existe desde o 6.17. Convém que a SBOM do artigo 01 registe o ramo e os patches aplicados, e o estado de cada CVE no produto pode comunicar-se em VEX.

Quando o fim de vida do ramo cai antes do fim do período de suporte que o fabricante declara, é preciso outra via. O Civil Infrastructure Platform, da Linux Foundation, mantém kernels SLTS para uso industrial, com fim de vida projetado para janeiro de 2031 (5.10), agosto de 2033 (6.1) e junho de 2035 (6.12). As alternativas são migrar de ramo durante a vida do produto ou contratar esse suporte ao fornecedor.

Python: o ssl da ligação à cloud e o tarfile das atualizações

Dois módulos do Python tocam diretamente o que um aparelho faz sozinho: o ssl, por baixo de muitas ligações à cloud, e o tarfile, que muitos agentes de atualização usam para abrir pacotes.

Entre 30 set e 1 out 2026 saíram o 3.10.22, o 3.11.17, o 3.12.15, o 3.13.16 e o 3.14.8. O 3.10.22, de 1 out, é o último do ramo 3.10, que chegou ao fim de vida nesse dia e não terá mais correções de segurança. Do lado do ssl, duas correções interessam a quem fabrica.

A CVE-2026-19553 afeta clientes. O SSLContext.wrap_bio() não exigia server_hostname quando check_hostname estava ativo, e nesse caso a verificação do nome no certificado era omitida em silêncio; quem passa um server_hostname não vazio não é afetado. A PSF classifica-a como alta, com 7,6 em CVSS 4.0. A correção não é igual em todos os ramos: no 3.10, no 3.11 e no 3.12 a omissão passa só a gerar um aviso de descontinuação, por compatibilidade, e só a partir do 3.13 dá erro. Nesses ramos, atualizar o Python não chega. A mitigação oficial é passar sempre um server_hostname válido ao wrap_bio(), ao asyncio.create_connection() e ao loop.start_tls().

A CVE-2026-19445 afeta servidores. Um cliente TLS remoto, sem autenticação, pode fazer cair o processo, ou levá-lo a usar memória já libertada, quando o sni_callback troca de contexto e nada mais mantém vivo o contexto original. A PSF classifica-a como crítica, com 9,2 em CVSS 4.0. Interessa, por exemplo, a um aparelho que sirva uma interface local por HTTPS a partir de Python, escolha o certificado pelo nome pedido com sni_callback e crie o contexto com esse callback a cada ligação, ou o substitua com ligações abertas. Um servidor que embrulha o socket de escuta com esse contexto não é afetado. A mitigação é manter uma referência a cada SSLContext que define sni_callback durante toda a vida do servidor.

Do lado do tarfile, os mesmos lançamentos fecharam três falhas nos filtros de extração (CVE-2026-82049, CVE-2026-87910 e CVE-2026-19672); a CVE-2026-87910 só chegou ao ramo 3.14 com o 3.14.9, de 21 out. A 22 out, a PSF anunciou mais uma, a CVE-2026-114583: o filtro tar podia ser contornado por entradas de ligação manipuladas num arquivo malicioso e escrever ficheiros fora do diretório de destino, dentro das permissões do processo. A PSF dá-lhe gravidade média, com 6,9 em CVSS 4.0. A 23 out, a correção estava integrada no ramo principal e nos ramos 3.15 e 3.14, as retroportagens para 3.13, 3.12 e 3.11 esperavam integração, e nenhuma versão lançada a incluía. O 3.10 não está na lista.

A documentação oficial recomenda o filtro data. Desde o 3.14 é o filtro por omissão; antes disso, a extração confiava totalmente no arquivo, e para o 3.13 e anteriores recomenda-se definir filter='data' explicitamente. O próprio filtro data teve contornos corrigidos este ano, em junho (a CVE-2026-7774, equivalente à CVE-2026-114583 no filtro data) e nestes lançamentos, e só protege numa versão que já inclua essas correções. Nenhum filtro bloqueia todas as funcionalidades perigosas, e arquivos de fontes não confiáveis não se extraem sem inspeção. Num agente de atualização, isto traduz-se numa ordem de operações: verificar a assinatura do pacote antes de extrair o que quer que seja. Assim, quem não tem a chave de assinatura não consegue fazer chegar um arquivo seu ao código que extrai.

O ramo também conta. O 3.10 já não recebe correções de nenhum tipo. O 3.11 tem correções de segurança até outubro de 2027, o 3.12 até outubro de 2028 e o 3.13 até outubro de 2029, e nos ramos só de segurança os lançamentos são, em regra, apenas de código-fonte. Um produto que declare em 2026 cinco anos de período de suporte com Python 3.11 lá dentro terá de mudar de ramo a meio, ou de assumir as correções por conta própria.

Os certificados gravados no firmware

A 17 out 2026, um investigador da comunidade comunicou aos programas de raízes da Apple, da Google, da Microsoft e da Mozilla que as chaves privadas de oito autoridades de certificação intermédias da eMudhra tinham sido geradas com aleatoriedade insuficiente; a eMudhra foi informada no mesmo dia. Segundo a Google, isso permitia a qualquer pessoa forjar certificados HTTPS de confiança para qualquer site, perante clientes que ainda confiassem nessas intermédias. Seis destinam-se a TLS e duas a assinatura de código. O Chrome e o Firefox bloquearam-nas no mesmo dia pelos seus mecanismos próprios (CRLSet e OneCRL), e a eMudhra revogou as oito a 18 out.

Segundo a eMudhra, só uma estava em produção e nenhuma emitiu certificados de entidade final; a empresa diz não conhecer indícios de que as chaves fracas tenham sido recuperadas ou exploradas antes da divulgação. Até 19 out, segundo a Mozilla, os registos de Certificate Transparency também não mostravam certificados destas intermédias. A página do incidente lembra que as chaves podiam ser recuperadas a partir dos certificados desde que estes foram criados, em abril de 2025, e que não se sabe se alguém o fez contra clientes que não exigem Certificate Transparency. A Mozilla considera provável o abuso das chaves a curto prazo. Os navegadores exigem Certificate Transparency. Muitos clientes fora dos navegadores não a exigem nem consultam revogações, e para esses a proteção chega com uma atualização de software.

Essa atualização é a remoção de confiança no repositório. O NSS 3.131.1, de 20 out, retira três raízes emSign, uma delas por causa do incidente: a «emSign ECC Root CA - G3», à qual as intermédias encadeiam por assinatura cruzada (foram emitidas por duas outras raízes da eMudhra, que a Mozilla não inclui), e o Chrome retira-a do seu repositório numa versão prevista para 27 out. A quem mantém repositórios sem forma de desconfiar de intermédias concretas, a Mozilla recomenda que pondere retirar três raízes (AAA Certificate Services, emSign Root TLS CA - G3 e emSign ECC Root CA - G3), mesmo que alguns servidores legítimos deixem de ser alcançáveis. A 20 out, o Debian (DSA-6572-1) bloqueou no ca-certificates a emSign ECC Root CA - G3 e a AAA Certificate Services, e o Ubuntu retirou a emSign ECC Root CA - G3 e, nas versões 14.04 a 20.04, também a AAA, que já não constava das versões 22.04 e seguintes. A Red Hat publicou o boletim RHSB-2026-012 a 21 out e uma atualização para o RHEL 10 a 22 out (RHSA-2026:88455).

Os ecossistemas de linguagem trazem repositórios próprios, e cada um precisou de correção:

  • Python. O certifi 2026.10.19 e o pip 26.2.2 saíram a 20 out, e o 3.15.1, o 3.14.9 e o 3.13.17, de 21 out, passaram a incluir esse pip. Christian Heimes, programador do núcleo do CPython, lembra que o pip carrega sempre o certifi que traz embebido, além do repositório do sistema, pelo que retirar a confiança só ao nível do sistema operativo não basta. O 3.11 e o 3.12 não vão receber o pip novo; nesses ramos atualiza-se à mão, ambiente a ambiente. O CPython prepara ainda, como defesa em profundidade, uma lista de bloqueio das chaves destas intermédias no módulo ssl, com retroportagem pedida até ao 3.11; a 23 out ainda não estava integrada.
  • Node.js. Os lançamentos de segurança de 21 out, tratados no artigo 09, incluem a atualização dos certificados de raiz.
  • Go. O 1.27.3 e o 1.26.10 acrescentam ao crypto/x509 uma lista de bloqueio para estas intermédias (CVE-2026-111943). Como a lista vive na biblioteca padrão, um binário Go só a ganha quando é recompilado.

Para quem fabrica, a pergunta concreta é de onde vêm os repositórios de certificados gravados no firmware e como se atualizam. As raízes emSign entraram no ca-certificates do Debian em 2020, e o aviso do certifi dá como afetadas todas as versões desde 2019, por isso um firmware construído desde então com um repositório derivado do da Mozilla tem provavelmente a raiz agora retirada. As oito intermédias têm também assinatura cruzada da Sectigo, de maio de 2025, sob a raiz AAA Certificate Services, que esteve muitos anos nos repositórios derivados do da Mozilla e continua nos da Apple e da Microsoft. Um firmware com um repositório desses que não consulte revogações confia provavelmente nestas chaves, seja qual for a data em que foi construído. Num repositório antigo, retirar só a emSign ECC Root CA - G3 não chega: ou se passa para o repositório atual inteiro, ou se retiram as três raízes que a Mozilla indica. Se o repositório só muda com uma imagem de firmware nova, cada remoção de raiz obriga a um ciclo completo de atualização.

O repositório entra na SBOM como componente, com origem e data, e precisa de caminho de atualização, próprio ou dentro de cada atualização OTA. Na ligação à cloud do próprio fabricante, o aparelho pode confiar apenas nas autoridades que essa ligação usa, desde que fique previsto como as substituir; um incidente numa autoridade que a ligação não usa deixa então de pesar nela. Falta o lado do build: a PSF recomenda reconstruir as imagens de contentor sem cache de camadas e atualizar o pip em todos os ambientes virtuais, o que vale também para as imagens que constroem o firmware.

Isto obriga a notificar?

O artigo 14.º do CRA obriga a notificar duas coisas: as vulnerabilidades ativamente exploradas existentes no produto (n.º 1) e os incidentes graves com impacto na segurança do produto (n.º 3). O produto inclui as suas soluções de tratamento de dados à distância (artigo 3.º, ponto 1), e as orientações da Comissão de 27 jul 2026, C(2026) 5252, que não são vinculativas, aplicam-lhes também o artigo 14.º (ponto 178). O mesmo documento deixa fora desse conceito os pipelines de CI/CD e a distribuição de atualizações de segurança (ponto 182). Um comprometimento dos servidores de build ou de atualização capaz de introduzir código mal-intencionado no produto é, ainda assim, um incidente grave (artigo 14.º, n.º 5, alínea b)), com notificação de alerta precoce em 24 horas e notificação de incidente em 72 horas.

A 23 out 2026, nenhuma das CVE citadas neste texto consta do catálogo KEV da CISA (versão de 21 out). No registo do PwnEscape, a avaliação da CISA de 16 out indica que não há exploração conhecida. A Red Hat escreve que acompanha a falha como caso KEV de exploração ativa, sem indicar a fonte e sem que haja entrada no catálogo da CISA. A demonstração contra sandboxes de produção que a Vercel relata foi feita no desafio que a própria Vercel lançou, com autorização. O CRA só considera ativamente explorada uma vulnerabilidade com provas fiáveis de exploração por um agente mal-intencionado sem autorização do proprietário do sistema (artigo 3.º, ponto 42), e não encontrámos fonte primária que relate exploração desse tipo. Para um produto que esteja no cenário descrito na secção do PwnEscape, essa divergência é matéria para a triagem.

Os exploits públicos do Infinity Core mostram que as falhas podem ser exploradas, mas não são, por si, prova de que um agente mal-intencionado as explorou. No caso da eMudhra, a empresa diz não conhecer indícios de exploração antes da divulgação, a Mozilla considera provável o abuso das chaves a curto prazo, e a página do incidente diz que não se sabe se houve exploração contra clientes que não exigem Certificate Transparency.

Segundo as mesmas orientações (ponto 218), se o código vulnerável de um componente não é alcançável no produto, ou se não houve exploração nele, não há reporte obrigatório para esse fabricante. Nesse caso, o fabricante pode ainda notificar voluntariamente (artigo 15.º). Para a triagem, a exploração do mesmo componente noutros sistemas é um sinal a ter em conta. Se a triagem concluir que houve exploração no produto, abre-se o calendário do artigo 14.º: notificação de alerta precoce em 24 horas, notificação de vulnerabilidade em 72 horas e relatório final, pela plataforma única de comunicação de informações. O artigo 02 descreve o circuito.

Nota de rigor. O estado de exploração aqui descrito é o que as fontes citadas indicavam a 23 out 2026, e pode mudar. As orientações C(2026) 5252 não são vinculativas. A decisão sobre se houve exploração ativa num produto concreto cabe ao fabricante, com base na sua própria triagem, e este texto não substitui essa avaliação nem aconselhamento jurídico.

Por onde começar

Esta semana, a SBOM tem de responder a três perguntas: que kernel está no aparelho, de que ramo e com que patches; que Python e que pip, no aparelho e nas imagens de build; que repositórios de certificados há no firmware (o do sistema e os embebidos, como o certifi das aplicações Python, o do Node.js ou a lista de bloqueio compilada nos binários Go), e de quando. Se a SBOM ainda não tem estas respostas, completá-la é o primeiro passo.

Depois, para cada correção que se aplique, a pergunta é como chega aos aparelhos já vendidos. Kernel novo do fornecedor, Python corrigido ou repositório de certificados atualizado, todos precisam do mesmo caminho: uma atualização assinada, por OTA ou local, disponível durante todo o período de suporte declarado. Ao fornecedor do SoC fazem-se as quatro perguntas da secção do kernel, por escrito e com data.

Na maior parte dos casos deste mês, a correção a montante já existe. O troço que falta, entre o fabricante e o aparelho, só o fabricante o pode fazer.

Fontes