No dia 3 de Outubro de 2026 (dois dias antes do aniversário do Linux) foi lançada a versão 0.8.15 do toybox, o shell do Linux utilizado no Android (desde a versão 7), no Tyzen e que foi inclusive portado para o FreeBSD.
Desta vez apenas um novo comando, o ucsicontrol para definir e controlar recursos avançados das portas USB. O comando find recebeu a opção %h-printf e o comando unicode analisa U+XXXX para exibir caráteres unicode com correspondência utf8. Estando em pendente, o comando getty recebeu a opção --show-issue, agora o shell possui os comandos command, type e umask builtin, expansão de variáveis ${x@P}, conversão de case ${X@UuL}, melhor verificações de variáveis readonly e uma nova macrto "tst" que leva apenas 3 argumento.
Houveram como sempre várias correções de bugs e limpezas. Poucas coisas desta vez, mas que valem muito a pena a versificação.
No dia 25 de Agosto de 1991 Linus Torvalds publicou a seguinte mensagem no Newsgroups comp.os.minix intitulada "O que você mais gostaria de ver no minix?" e com o sumário "Uma pequena enquete sobre o meu novo sistema operacional":
" Olá a todos aí fora utilizando minix -
Estou fazendo um sistema operacional (livre) (apenas um hobby, não vai ser grande ou profissional como o gnu) para clones AT 386(486). Ele vem se formando desde Abril e está começando a ficar pronto. Eu gostaria de feedback de coisas que as pessoas gostam e não gostam no minix já que meu OS se assemelha a ele de alguma forma (mesmo layout físico do file-system devido a razões práticas entre outras coisas).
Atualmente eu portei bash(1.08) e gcc(1.40) e as coisas aparentam funcionar. Isso significa que eu terei algo prático dentro de alguns meses e eu gostaria de saber quais recursos a maioria das pessoas querem. Quaisquer sugestões são bem vindas, mas eu não vou prometer que vou implementa-las :-)
Linus (torvalds@kruuna.helsinki.fi)
OBS. Sim - ele é livre de qualquer código do minix e possui um fs multi-threaded. Ele NÃO é portável (utiliza 386 task switching etc) e provavelmente nunca possua suporte a qualquer coisa além de disco rígido AT já que é tudo o que eu tenho :-(."
Esta foi provavelmente a terceira ou quarta mensagem enviada por Linus e não se tratou do lançamento do Linux já que, em suas próprias palavras, o Linux "está começando a ficar pronto", que "as coisas aparentam funcionar" e que "significa que eu terei algo prático dentro de alguns meses". A segunda evidência pode ser lida no Oral History of Linus Torvalds de 27 de Julho de 2008 para o Computer History Museum na página 15 quando Grady Booch lhe pergunta:
"Houve o anuncio de Agosto em 1991. Esse foi o anuncio ou foi um subsequente?"
A que Linus lhe responde:
"Eu acho que o anuncio de Agosto foi realmente um pré-anuncio. Esse foi o anuncio no que eu estava trabalhando. Eu não havia realmente feito um lançamento ainda, se eu me lembro corretamente."
"Julgando pelo post, o 0.01 ainda não havia sido lançado na verdade, mas estava próximo. Eu imagino que a primeira versão foi lançada em meados de Setembro de 91."
E a ultima está no próprio https://www.nic.funet.fi, local onde Linux foi disponibilizado pela primeira vez e que está ativo até os dias de hoje contendo a seguinte mensagem:
"Linux foi disponibilizado pela primeira vez ao mundo a partir daqui no dia 17/09/1991"
Logicamente não se trata mais do mesmo hardware da época, sendo hoje um muito mais potente possuindo dois processadores de 20 núcleos, 786GB de RAM, mais 80TB de storage NFS da NetApp e 2 conexões de 25Gbit/s (informações disponíveis no rodapé do próprio site).
Então, como o aniversário do Linux pode ser comemorado no dia 25 de Agosto já que sua primeira versão (0.01) só foi lançada no dia 17 de Setembro? Pois é, quase um mês após a publicação da mensagem que vocês leram no início deste artigo. Você comemora o nascimento de uma criança antes de ela nascer? Qual o sentido disso?
OK. Isso significa então que o aniversário do Linux é no dia 17 de Setembro, certo? ERRADO! Neste mesmo link da universidade de Carnegie Mellon, Linus descreve que:
"Os códigos do 0.01 não eram na verdade executáveis: Eles eram apenas um gesto simbólico para arl, que provavelmente tinha começado a perder a esperança de conseguir qualquer coisa. Essa próxima mensagem deve ter sido de apenas algumas semanas antes daquele lançamento."
"Era somente o código fonte para pessoas interessadas em saber como era o Linux"
"Ele não era nada bonito, não tinha driver para floppy e não conseguia fazer quase nada. Eu não acredito que alguém jamais tenha compilado aquela versão. Mas, a essa altura, eu já estava fisgado e não queria parar até conseguir me livrar do Minix."
A versão 0.01 foi apenas uma versão embrionária, uma espécia de ultrassom do Linux. O lançamento oficial do Linux ocorreu no dia 5 de Outubro de 1991 às 05:41:06 GMT na versão 0.02 com a mensagem contendo título "Códigos do kernel livre parecido com o minix para 386-AT":
"Você anseia os bons tempos do Minix 1.1, quando homens eram homens e escreviam seus próprios device drivers? Você está sem um bom projeto e morrendo para dar os primeiros passos em um OS que você possa modificar para as suas necessidades? Você está achando frustrante quando tudo funciona no minix? Chega de passar a noite em claro para fazer um programa bacana funcionar. Então esta mensagem pode ser para você :-)
Como eu mencionei um atrás (?), eu estou trabalhando em uma versão livre de um similar ao minix para computadores AT-386. Ele finalmente alcançou o estágio onde está utilizável (embora possa não estar dependendo do que você queira) e eu estou disposto a disponibilizar o código-fonte para uma distribuição mais ampla. Ele ainda está na versão 0.02 (+1 (bem pequeno) patch pronto), mas eu consegui rodar bash/gcc/gnu-make/gnu-sed/compress e etc nele.
Os códigos fonte para esse projeto meu podem ser encontrados no nic.funet.fi (128.214.6.100) dentro do diretório /pub/OS/Linux. O diretório também possui alguns arquivos README e alguns binários para funcionar sob o linux (bash, update e gcc, o que mais você poderia querer :-). O código completo do kernel é fornecido, já que nenhum código do minix é utilizado. códigos da biblioteca são parcialmente livres, então ela não pode ser distribuída atualmente. O sistema é capaz de compilar "tal como está" e é de conhecimento por funcionar. Heh. Códigos fonte para os binários (bash e gcc) podem ser encontrados no mesmo lugar em /pub/gnu.
ALERTA! AVISO! NOTA! Esses códigos fonte ainda necessitam do minix-386 para serem compilados (e gcc-1.40, possivelmente 1.37.1, não foi testado), e você precisa do minix para configurá-lo se quiser rodá-lo, então ele não é um standalone ainda para aqueles de vocês ainda sem o minix. Eu estou trabalhando nisso. Você também precisa ser algo como um hacker para configurá-lo (?), então para queles esperando por uma alternativa ao minix-386, por favor me ignorem. Atualmente, ele é destinado para hackers interessados em sistemas operacionais e em máquinas 386, com acesso ao Minix.
O sistema precisa de um disco rígido compatível com padrão AT (IDE está bom) e EGA/VGA. Se ainda estiverem interessados, por favor ftp os README/RELNOTES, e/ou me enviem e-mail para obter informações adicionais.
Eu consigo (bem, quase) ouvir vocês se perguntando "por que"?. O Hurd vai ser lançado em um ano (ou dois, ou no mês que vem, quem sabe?), e eu já tenho o minix. Esse é um programa para hackers por um hacker. Eu me diverti desenvolvendo ele e alguém pode se divertir olhando para ele e até mesmo modificando-o para suas próprias necessidades. Ele ainda é pequeno o suficiente para para entender, utilizar e modificar e eu estou com expectativa de quaisquer comentários que você possa ter.
Também estou interessado em ouvir qualquer um que tenha escrito quaisquer utilidades ou funções de biblioteca para o minix. Se seus esforços são distribuíveis livremente (sob copyright ou mesmo domínio público), eu gostaria de ouvir você, assim eu consigo adicioná-las ao sistema. Estou utilizando Earl Chews estdio agora mesmo (obrigado pelo bom e funcional sistema Earl), e trabalhos similares serão muito bem vindo. Seus (C)'s serão mantidos intactos é claro. Deixe-me uma linha se você estiver disposto a me deixar utilizar o seu código.
Linus
PS. para PHIL NELSON! Não consigo te contatar, e continuar conseguindo "encaminhar erro - strawberry unknown domain" ou algo.
Resumidamente, o aniversário do Linux é no dia 05 de Outubro pois esta é a verdadeira data do seu lançamento, o lançamento que garantiu funcionamento mínimo para quem quisesse utilizá-lo e que não era garantido na versão 0.01. E a partir da versão 0.12 (que eu já expliquei que foi onde surgiu o suporte a memória virtual e a migração da licença da convenção de Berna do século XVIII para a GPLv2) começaram a surgir as primeiras distribuições Linux:
Daí para frente, a história do Linux é pura evolução e eu aconselho a assistir as minhas palestras A Evolução do Linux e Linux domina o mundo, mas por que? que podem ser assistidas logo abaixo:
Para todos os o que chegaram aqui, eu tenho uma surpresa para vocês. Para que possamos juntos comemorar o aniversário do Linux, eu disponibilizei vagas gratuitas do meu curso. É só clicar no link abaixo e aproveitar :) Mas aproveite, porque estas vagas são por tempo limitado (validas somente até o final do mês).
A ideia é construir uma versão otimizada do kernel Linux utilizando as bases de configurações originadas do kernel do Manjaro (que já são utilizadas pelo BigCommunity), correções desenvolvidas pela própria comunidade BigLinux e recursos de terceiros que oferecem ganhos. Os recursos em questão são o BORE CPU scheduler, o POC idle CPU selector, ADIOS I/O scheduler, os pacthes enviados pelo Tales e o compilador LLVM/Clang com suporte a ThinLTO e AutoFDO. Todas as configurações do Manjaro necessárias para desktops são mantidas sendo apenas adicionados os recursos mencionados além dos patches desenvolvidos pela própria comunidade BigLinux.
O objetivo é oferecer um kernel com máximo desempenho possível. O que eu particularmente acho interessante em um projeto como este é que, desta forma, a comunidade BigLinux pode disponibilizar para sua base de usuário todas as melhorias feitas muito antes de serem disponibilizadas em outros projetos. Como é o caso desta correção do driver de vídeo da Intel que só estará disponível a partir da versão 7.4 e os usuários de BigLinux já usufruíam deste benefício desde o kernel 7.2.
O processo de instalação, seja via repositório ou construção manual e como atualizar o kernel estão todas descritas na própria documentação do projeto. O pacote Linux-Big está disponível sob licença MIT; já os patches estão disponível sob licença GPLv2
No dia 08 de Setembro foi lançada a versão 2.2.12 da linguagem Nim, a sexta patch release da versão estável que trás um total de 142 commits contendo 55 correções de bugs e melhorias. Todas as mudanças podem ser conferidas clicando no link abaixo:
Aproveitem também para assistir a NimConf 2026 que contem duas playlists. A primeira se chama NimConf 2026 - social & workflow track e a segunda NimConf 2026 - project track.
Mega Man X Regenesis é um novo fan game desenvolvido por Justin Ross (aka: mmxregenesis) com a grande ajuda de um grupo de talentosos artistas e lançado no dia 17 de Agosto (trabalho que levou dois anos). O jogo foi desenvolvido em Godot adicionado melhorias e modernizações gráficas, efeitos de iluminação, trilhas sonoras originais (o total de 25), reformulações de fases, fases externas e contando com oito chefes principais.
A TRAMA
O jogo se passa em uma linha do tempo alternativa seguindo eventos do Mega Man X onde Sigma venceu, X foi derrotado e a humanidade está a beira da extinção. Bem quando toda esperança parece perdida, Dr. Cain revela sua ultima contingencia, o Project Regenesis. Dada uma ultima chance para reescrever a história, X deve se levantar mais uma vez e lutar para salvar o que restou da humanidade.
COMPATIBILIDADE E RECURSOS
Mega Man X Regenesis é compatível com Linux, Windows, MacOSX, Android(que não deixa de ser Linux porém, com diferente user-space que não contem programas sob licença GPL) e esperam em breve estar disponível para Steamdeck. Vale a ressalva de suporte total a joystick. Além de uma história autoral, os oitos chefões são novos, novas armas, upgrades de armadura.
Em Julho de 2026, o engenheiro de software da equipe BigLinux, Tales Mendonça que também é um dos autores do livro Shell Linux – Do Aprendiz ao Administrador (que eu em particular possuo um exemplar deste autografado pelo próprio Tales e pode ser conferido clicando aqui), descobriu um bug no driver de vídeo do kernel XE da Intel. Em depoimento, o Tales me disse o seguinte:
"Em Março eu comprei um computador da Asus que foi lançado em Fevereiro deste ano e resolvi utilizar o driver XE mantido pela Intel. Este driver estava bem ruim, cheio de bugs que levavam meu computador a travar várias vezes ao dia. Eu fui aos poucos consertando as coisas; mesmo assim, passados dois ou três dias, meu computador travava novamente e era necessário reiniciá-lo. Então eu escrevi alguns patches de correções, entrei para a lista do driver XE, conversei com um dos engenheiros da Intel e enviei meus patches. Hoje, depois destas atualizações, meu computador fica ligado por vários dias sem a mínima necessidade de reinicialização e não apresenta mais nenhum dos problemas conhecidos. Ainda fiz mais algumas correções que me foram solicitadas pelos engenheiros do kernel."
Foram enviados mais de doze patches para a Intel; alguns foram aceitos no kernel e outros não e serão disponibilizados em breve dentro da versão do 7.1. Graças a este trabalho, agora o Tales faz parte da equipe para continuar o desenvolvimento do driver XE. "vou conseguir resolver mais um bug que a Intel tem" me informou Tales.
Esta não é a única contribuição significativa já feita pela comunidade BigLinux; a equipe já enviou patches para outros projetos e distribuições além de possuir vários recursos próprios. Vou finalizar este artigo por aqui, mas vou deixar uma live do pessoal do BigLinux que eles participaram no canal. Forte abraço e até a próxima:
O FreeBSD 16 ainda não foi lançado (previsto para Dezembro de 2027), mas vários sites como FOSS Force, FOSSLinux, Slashdot e Phoronix veem publicando desde o dia 14 de Julho que o FreeBSD 16 conta com um dos seus principais destaques, ter removido completamente todo código fonte que seja regido sob a licença GPL da base do sistema operacional. No dia 21 de Fevereiro foi aberto o ticket D55424 intitulado "Retire dialog" que descreve:
"Esse é o ultimo restante de software GPL na base do sistema. O instalador fez transição para o bsddialog quatro anos atrás e o ultimo consumidor de dialog restante, o dpv, foi desligado mais de dois anos atrás. Aposentem o dpv, libdpv, libfigpar (utilizado apenas pelo dpv), e o próprio dialog."
"Com o diff e cdialog do GNU removidos, isso agora é apenas uma casca vazia."
Com esse commit, foi concluída a remoção completa da subtree do GNU da arvore de código fonte do FreeBSD (inclusive até das notas do arquivo README) tendo todos eles entrado para obsoletefiles.inc.
bsddialog
A equipe do FreeBSD vem fazendo este pesado trabalho ao longo de um bom tempo. Duas soluções que o FreeBSD adotou eu já apresentei aqui no meu blog, sendo elas o comando bc de autoria de Gavin Howard e que é utilizado também no Android como dependencia para compilar seu kernel (e que já reportei um bug) e o pacote libarchive que contem comandos como tar, minitar, cpio e unzip.
Migrar para alternativas sob outras licenças open-source ou remover todo código sob alguma GPL se tornou um processo natural, coisa tal que já foi feito no próprio Android há muito tempo. Nas notas de rodapé do about do toybox é descrito:
"Desde que o Android não era "GNU/Linux" de jeito nenhum, nós precisávamos limpar todos os vestígios de software gnu de sua compilação para obter um sistema auto-suficiente limpo."
Como mostro no artigo É possível que um dia Linux saia da GPL? a popularidade da GPL vem caindo cada vez mais desde de 2007 tanto para novos projetos quanto para projetos já consolidados que migraram para outras licenças. No próprio Android explicitamente se desencoraja o uso das licenças GPL e LGPL em seus produtos e gradativamente reimplementaram componentes (como sua pilha bluetooth) que estavam sob tais licenças por outros sob licença Apache (sim para quem não acreditam, o Android é uma distribuição Linux open-source). O Android ainda carrega a política de não conter nada sob GPL em seu user space; apenas em seu kernel space utiliza GPL já que que se trata do kernel linux vanilla onde não removem e nem modificam nada do kernel, apenas adicionando o que necessitam.
Já a Apple congelou o Xcode nas últimas versões do GPLv2 (GCC 4.2.1 com binutils 2.17) por mais de 5 anos enquanto patrocinava o desenvolvimento de novos projetos (clang/llvm/lld) para substituí-los, implementou um novo servidor SMB do zero para substituir o Samba, substituiu o bash pelo zsh e assim fez com toda a sua pilha de programas da base do MacOS X.
Existem até projetos que mesmo que continuem utilizando GPL em seus projetos, acabam deixando notas autorizando o uso e a promessa de não processar os usuários. Veja como exemplo a FAQ da dietlibc:
"Q: GPL é ruim! Agora eu não posso compilar meus programas BSD com a diet libc!
A: Errado. você pode compilá-los e utilizá-los. Você só não pode redistribuir os binários. Dito isso: Eu não vou processar ninguém por distribuir binários de programas BSD linkados à dietlibc, contanto que o código fonte esteja disponível em algum lugar público."
A própria Linux Foundation fundou a SPDX (System Package Data EXchange: ISO/IEC 5962:2021) para que, de forma simples de explicar, proteger legalmente os projetos evitando que eles tenham conflitos entre as licenças open-source. O toybox por exemplo, sendo regido sob a clausula zero BSD (0BSD) possui um identificador da SPDX que te direciona ao site oficial BSD Zero Clause License | Software Package Data Exchange (SPDX).
Ainda é possível utilizar software licenciado sob GPL no FreeBSD através de instalação separada (o que é algo que ocorre também no Android).
Como eu já disse no passado:
Nem todas as ferramentas que utilizamos nas distribuições Linux são do projeto GNU como alegam. A maioria são do próprio Linux* ou de outros Unix.
As ferramentas do GNU são substituíveis.
Nem toda ferramenta que o projeto GNU alega ser deles é deles de fato.
A maioria do código das ferramentas do projeto GNU é desenvolvido por outros projetos (incluindo o próprio Linux) e outras empresas, menos pelo próprio projeto GNU (foram quando não dão créditos as pessoas).
*Pois é, mentiram para você esse tempo todo alegando que Linux é somente o kernel do sistema operacional.
No dia 22 de Junho de 2026 foi lançada a versão 0.8.14 do shell toybox. A partir desta versão, o toybox foi migrado do Github para o Codeberg e a mailing list agora está sendo hospedada pela OSUOSL.
Não há comandos novos nesta versão e sim adição de novos recursos a comandos já existentes, sejam eles estáveis ou como pendentes e correções de bugs. O comando lsusb recebeu a opção -v, o comando xargs recebeu a opção --process-slot-var; o comando taskset recebeu as opções -c (cpulist que agora sua Test suite permite realizar cálculos não causando overflow ao shell), --all-tasks e --pid; o comando readelf recebeu flags específicas para processador e correção na opção -S; o vi do toybox recebeu a opção ZZ (salvar e sair assim como !wq.) além de correção no bufffer vazio que ficava marcado como maodificado; correção na geração de processo zumbi no dhcp; o comando diff recebeu uma correção de argumento opção em flags movendo arquivos temporários desnecessários para $TMPDIR ou para /tmp ao invés do diretório atual.
Melhorias no toysh
O toysh é um comando de extrema importância para a evolução do toybox pois é através do toysh que os scripts serão executados (assim como através dos comandos sh e bash que também estão presentes no toybox como pendentes) e através dele que conseguirão substituir o Bash (na qual esta é a intenção).
Opções fornecidas pelo toysh
toysh sendo utilizado como shell padrão e exibindo seus comandos comandos internos ao digitar help. Também é possśivel notar que ao digitar o comando uname -a, aparece a palavra toybox ao invés de GNU/Linux (como se gabam)
Como já mostrei há alguns anos, o toysh ainda não está pronto e pode ser conferido no vídeo abaixo. Este comportamento foi reportado aos mantenedores como contribuição.
Apesar disto, esta versão trouxe várias correções e atualizações ao toysh.
A evolução do mkroot
Para quem não o mkroot, esta é uma distribuição Linux desenvolvida por Rob Landley para servir como ambiente de pesquisas, desenvolvimentos e testes do toybox. No passado, seu nome era Aboriginal Linux, mas com o tempo, Rob deecidiu dar fim ao Aboriginal Linux e adotar outro nome como Hermetic e por fim, foi nomeado simplesmente mkroot. Por volta de e2022 A Google passau a financiar o desenvolvimento tanto do toybox quando do mkroot para que ela pudesse utiliza-los em tecnologias internas (para quem acha que a Google vai substituir o Android pelo Fuchsia, só demonstra amadorismo, romantismo e emoção).
O Mkroot também recebeu várias melhorias, correções de bug e atualizações. é possível baixá-lo e utilizá-lo via Qemu. Landley fez uma apresentação no ELC talk a respeito do mkroot (Building the Simplest Possible Linux System) demonstrando os passos e configurações necessárias para se construir e bootar um sistema operacional Linux mínimo até chegar ao prompt de comandos. Depois disso, Rob seguiu com o linux-embedded thread.
Postado no site Linux Journal no dia 21 de Maio de 2026 por George Whittaker, que devido o crescimento de compatibilidade de software com o systemd, especialmente em torno de aplicações desktop, containers e programas de orquestração de container, aplicações flatpak, aplicações proprietárias, agentes de monitoramento, certas ferramentas de jogos e multimídia, AI e ferramentas enterprise começa a surgir uma pressão para que os desenvolvedores da distribuição Alpine Linux se adaptem a nova necessidade.
Apesar de a equipe do Alpine Linux intencionalmente evitar o systemd, trazendo assim vantagens e desvantagens para a distribuição, as desvantagens com as incompatibilidades começaram a ficar muito problemáticas já que as aplicações empregam fortemente a libsystemd, as APIs do systemd e os comportamentos específicos da glibc (sim, no meu artigo Linux: mais do que um Unix eu mostro uma parte considretável de recursos da API do Linux, a LSB (Linux Standard Base), que agrega recursos e funcionalidades ao Linux que nenhum outro Unix ou a API POSIX possui. Estes recursos foram basicamente concentrados dentro da glibc ao ponto que eu relato em meu artigo Muito além do GNU: Os vários sabores de bibliotecas C que a "glibc é escrita com nada além do Linux em mente"; o que eu considero uma extrema burrice terem feito isso pois deveriam ter feito o mesmo em paralelo a outras bibliotecas como alternativas e não deixando o Linux escravo da glibc. Eu tenho artigo intitulado O que falta para a que a musl substitua a GilbC no Linux que já detalha bem o assunto e espero que um dia isso venha realmente acontecer.
Como o ecossistema do Linux em torno do systemd cresce cada vez mais, alguns esforços experimentais para empacotar porções do systemd sem a necessidade de ter o Alpine Linux totalmente com systemd já estão sendo feitas assim como uma versão em paralelo do systemd com suporte a musl (já que compatibilidade da glibc na musl já existe). O que são ideias interessantes demonstrando que o Alpine não está abandonando a sua identidade de manter a distribuição mínima e sim se adaptando e se modernizando. A ideia de compatibilidade é a chave para isso assim como outros projetos no Linux fazem (Wayland com o X11, proton e o Wine com as aplicações Windows e etc).
Vulnerabilidades de Copy Fail, Dirty Frag e Fragnesia no kernel Linux
No dia 19 de Maio a equipe Gentoo Linux postou em seu site oficial que Linux está enfrentando uma série de vulnerabilidades no kernel Linux conhecidas como Copy Fail, Dirty Frag e Fragnesia. Estas vulnerabilidades permitem escalar privilégio de administrador na maioria das distribuições Linux como pode ser conferido no vídeo abaixo criado por Hyunwoo Kim (mais conhecido como v4bel) que é um pesquisador de vulnerabilidades independente, ganhador dos prêmios Pwn2Own Berlin de 2025 e 2026, Google kernelCTF 0-day e Pwnie Awards 2025 e foi quem reportou a vulnerabilidade Dirty Frag:
Vale a ressalva que estas foram as distribuições testadas, mas pode afetar quase todas. Como Dirty Frag é um bug de lógica determinística, esse bug não depende de janela de tempo, não é obrigatória, não é gerado kernel panic quando o exploit falha e a taxa de sucesso é alta.
A primeira vulnerabilidade descoberta é o Copy Fail que mostra que qualquer kernel desenvolvido desde 2017 pode ser afetado necessitado apena um usuário sem privilégio, não necessita de acesso a rede, ou recursos de debug ou outra ferramenta explorando apenas recursos do kernel como a crypto API (AF_ALG) que vem habilitada por padrão:
