Linux kernel 7.1: novidades para servidores

O que há de novo no Linux kernel 7.1

O Linux kernel 7.1 foi lançado em 14 de junho de 2026, nove semanas depois da versão 7.0. Para um utilizador de VPS (virtual private server), as alterações relevantes distribuem-se por quatro áreas: armazenamento e sistemas de ficheiros, rede, gestão de memória e controlo de processos e contentores. O restante lançamento consiste sobretudo em alterações para desktops e gráficos que um servidor headless nunca carrega.

Há uma segunda resposta que precisa de conhecer primeiro. É quase certo que o 7.1 não está em execução no seu servidor e isso não acontecerá durante muito tempo. O kernel.org não lista o 7.1 como uma versão longterm. Em 11 de agosto de 2026, as linhas longterm são 6.18, 6.12, 6.6, 6.1, 5.15 e 5.10, e todas as principais distribuições de servidores são baseadas numa delas ou numa linha que mantêm por conta própria. “Novo no kernel” e “novo no seu servidor” estão separados por anos, por isso este guia aborda as duas situações.

Qual kernel está a ser executado pelo seu VPS neste momento

uname -r
uname -srm
systemd-detect-virt

uname -r apresenta a versão do kernel em execução. No Ubuntu 24.04, o resultado tem o formato 6.8.0-79-generic. A parte anterior ao primeiro hífen corresponde à linha do upstream. Tudo o que aparece depois é o número de compilação próprio da sua distribuição e não acompanha o upstream. O 6.8.0-79 da Canonical inclui milhares de correções retroportadas de kernels posteriores, pelo que não corresponde ao código identificado por Linus como 6.8 em março de 2024. Por isso, dizer que «o meu kernel é antigo» transmite menos informação do que parece. As funcionalidades são antigas. Normalmente, as correções de segurança não são.

systemd-detect-virt indica se pode alterar o kernel. Apresenta kvm numa máquina virtual completa, em que arranca a sua própria imagem de kernel e uma atualização é uma atualização efetiva. Apresenta lxc ou openvz em virtualização baseada em contentores, em que o kernel do host é partilhado. Num plano com contentores, uname -r mostra o kernel do fornecedor; instalar um pacote de kernel não altera nada que possa arrancar, e nenhuma funcionalidade desta versão fica disponível até o fornecedor reiniciar o host com um kernel mais recente. Execute esta verificação antes de planear qualquer operação no kernel.

[
  {
    "distro": "Ubuntu 26.04 LTS (7.0)",
    "releases_behind_7_1": 1,
    "notes": "GA kernel, shipped with the April 2026 release"
  },
  {
    "distro": "Ubuntu 24.04 LTS, HWE (6.17)",
    "releases_behind_7_1": 4,
    "notes": "6.17 came with 24.04.4; 7.0 is rolling out ahead of 24.04.5 on 27 August 2026"
  },
  {
    "distro": "Debian 13 trixie (6.12)",
    "releases_behind_7_1": 9,
    "notes": "upstream longterm line, kernel.org projected EOL December 2028"
  },
  {
    "distro": "RHEL 10 and its rebuilds (6.12)",
    "releases_behind_7_1": 9,
    "notes": "Red Hat backports fixes into its own frozen 6.12 stream"
  },
  {
    "distro": "Ubuntu 24.04 LTS, GA (6.8)",
    "releases_behind_7_1": 13,
    "notes": "the default unless you install the HWE stack"
  },
  {
    "distro": "Ubuntu 22.04 LTS, GA (5.15)",
    "releases_behind_7_1": 26,
    "notes": "upstream longterm line, kernel.org projected EOL December 2026"
  }
]

São 6 plataformas, e nenhuma arranca com 7.1. A mais recente é Ubuntu 26.04 LTS (7.0), que está 1 versões upstream atrás. A mais antiga que ainda tem suporte está 26 versões atrás. O kernel GA predefinido do Ubuntu 24.04 está 13 versões atrás, enquanto o Debian 13 e o RHEL 10 estão 9 versões atrás na linha longterm 6.12. Contar versões é uma medida aproximada, porque ignora tudo o que as distribuições retroportam, mas mostra a dimensão da diferença. Se estiver a decidir qual destas opções utilizar, a comparação entre LTS e uma versão intermédia num servidor é a decisão subjacente a estes números.

Armazenamento e sistemas de ficheiros na versão 7.1

A versão 7.1 permite gerar e verificar T10 PI (informações de proteção) dentro do sistema de ficheiros, em vez de apenas na camada de blocos, além de oferecer suporte flexível ao alinhamento T10. O T10 PI consiste em bytes adicionais associados a cada bloco. Esses bytes contêm uma soma de verificação e uma etiqueta que identifica a que bloco pertencem os dados. Assim, uma escrita direcionada para o bloco errado ou interrompida é detetada, em vez de ser devolvida como dados válidos. Para um utilizador de VPS, a limitação é o hardware. Os metadados de integridade têm de ser expostos pelo dispositivo, e um disco virtual normalmente não os expõe.

ls /sys/block/vda/integrity/

Na maioria dos discos de VPS, isto devolve No such file or directory, porque a camada de blocos só cria o diretório integrity quando o dispositivo regista suporte de integridade. Neste caso, esse erro é a resposta normal, não uma falha. Se quiser saber qual é realmente o tipo do seu disco antes de analisar outras funcionalidades de armazenamento, comece por verificar se o disco da VPS é realmente NVMe. A explicação sobre a diferença entre NVMe e um SSD SATA numa VPS mostra por que motivo a resposta altera os seus valores.

O Btrfs recebe correções para a amplificação de operações copy-on-write sob pressão de memória, além de uma alteração que acelera a limpeza da primeira extent num intervalo monitorizado. O pedido de merge indica um aumento de 10% no throughput da carga de trabalho usada no teste. A operação de encerramento deixou de estar marcada como experimental. O XFS melhora a limpeza de intervalos preenchidos com zeros e as pesquisas através de iomap. Também adiciona um ponteiro de escrita à geometria dos grupos de tempo real, preparando o suporte para dispositivos zoned. O NTFS foi completamente reescrito nesta versão. Passa a ter suporte total de escrita e uma conversão para iomap. Isto é relevante se alguma vez montar no seu servidor uma imagem de disco proveniente de uma máquina Windows.

Entre os itens menores de armazenamento, vale conhecer estes: ublk, o controlador de blocos em espaço de utilizador, passou a ter I/O sem cópia; o io_uring passou a aceitar comandos SCSI passthrough; o suporte para unidades self-encrypting SED-OPAL recebeu o comando STACK_RESET e o modo de utilizador único estendido; existe um novo controlador de caracteres fs-dax para dispositivos de acesso direto; e o VFS aumentou inode->i_ino de unsigned long para u64, removendo o limite do número de inode nas compilações de 32 bits. Nos sistemas de ficheiros de rede, o servidor NFS integrado no kernel pode agora assinar os seus file handles através de uma opção de montagem sign_fh, e o cliente CIFS passou a reconhecer O_TMPFILE.

Rede: concessão de filas e o que isso oferece a um contentor

A principal alteração na rede é a concessão de filas de hardware. Um dispositivo de rede virtual pode agora obter uma concessão de uma fila associada a uma fila real de um dispositivo de rede físico e atuar como seu proxy. O objetivo são os contentores. Até agora, um contentor que precisasse de AF_XDP (address family express data path, o tipo de socket que entrega pacotes em bruto ao espaço do utilizador sem os copiar através da pilha de rede) tinha de receber algo próximo do dispositivo inteiro. Com uma fila concedida, recebe uma fila de hardware, executa AF_XDP e fornecedores de memória à velocidade nativa, e o host mantém o restante da NIC. Esta alteração surge juntamente com o suporte de AF_XDP no caminho de cópia zero de io_uring.

Na utilização normal, os sockets em sockfs aceitam agora atributos estendidos user.*. Um socket AF_UNIX baseado num caminho já herdava o suporte de xattr do sistema de ficheiros subjacente, mas um socket existente apenas em sockfs não tinha esse suporte. Agora um processo pode atribuir uma etiqueta a um socket, e um programa eBPF pode filtrar com base nessa etiqueta.

Há duas remoções. UDP-Lite foi removido por não ter utilizadores. O IPv6 já não pode ser compilado como módulo carregável: se quiser IPv6, este é compilado diretamente no kernel. A segunda alteração não é visível em nenhum kernel de distribuição, porque as distribuições de servidor comuns já compilam o IPv6 diretamente no kernel.

Gestão de memória: a tabela de swap está concluída

A reformulação do swap chega à sua terceira fase, que remove o mapa estático de swap. A contagem de swap passa agora a ficar diretamente na tabela de swap. A poupança indicada é de cerca de 30% dos metadados estáticos de swap. Essa memória é mantida pelo kernel proporcionalmente ao tamanho do dispositivo de swap, independentemente de existir ou não conteúdo em swap. Em termos absolutos, a poupança é pequena num ficheiro de swap pequeno e aumenta com o tamanho de swap configurado.

O MGLRU (multi-generational least recently used, o algoritmo mais recente de recuperação de páginas) pode agora verificar o sinalizador young das páginas em lotes, em vez de verificar uma página de cada vez. O valor publicado com esta alteração indica uma melhoria superior a 60% num servidor Arm64 com 32 cores. O processamento em lotes produz mais ganhos quando o custo por página é maior. É por isso que esse valor foi obtido numa máquina Arm de grande dimensão. Se executar uma VPS Arm em vez de uma VPS x86, esta é a alteração do 7.1 com maior probabilidade de aparecer nas suas próprias medições, embora não nessa escala num sistema com dois ou quatro cores.

Também foram incluídas transferências a partir de cgroups de memória em processo de eliminação, análises do khugepaged com menor consumo de CPU e uma grande refatoração da gestão de nós grandes na maple tree. Nenhuma destas alterações exige configuração. O efeito será apenas uma ligeira redução do tempo de sistema.

Agendadores: subagendadores sched_ext e FRED ativado por predefinição

sched_ext, a classe de agendamento extensível que permite escrever um agendador de CPU como um programa BPF e carregá-lo em tempo de execução, foi introduzida na versão 6.12. A versão 7.1 adiciona a estrutura principal para subagendadores, para que um grupo de controlo possa futuramente executar com o seu próprio agendador. Leia esta frase com atenção. A implementação não está concluída na versão 7.1 e, em particular, falta o caminho de enfileiramento. Isto é uma base para uma versão posterior, não algo que possa ativar atualmente.

O Intel FRED (flexible return and event delivery) passa a estar ativado por predefinição no hardware que o suporta. O FRED substitui o caminho legado de entrega de eventos do x86 por uma implementação mais simples e está no kernel desde a versão 6.9, atrás do argumento de arranque fred=on. Ativá-lo por predefinição indica que o hardware comercial foi suficientemente testado. As medições publicadas até agora, entre 4% e 7% em cargas de trabalho intensivas em E/S, resultam de testes do Phoronix em hardware cliente. Por isso, não conte com esse ganho num servidor sem medir primeiro a sua própria carga de trabalho.

A execução por procuração passou a suportar a migração do doador para acelerar o proprietário remoto de um lock, o EEVDF recebeu correções relacionadas com atrasos negativos e o núcleo dos temporizadores de alta resolução foi substancialmente reescrito. Estas alterações melhoram a latência, mas não são expostas por nenhum ficheiro de configuração.

Novos controlos de processos e contentores em clone3()

Foram adicionadas três flags a clone3(), e cada uma elimina uma limitação que os supervisores têm contornado manualmente há anos. CLONE_AUTOREAP faz com que o processo filho recolha o seu próprio estado ao terminar, para que nunca se torne um zombie à espera de um processo pai que pode nunca chamar wait(). CLONE_NNP define no_new_privs no processo filho no momento da criação. Isto elimina a janela entre a clonagem e o momento em que o processo filho define a flag por si próprio. CLONE_PIDFD_AUTOKILL associa o tempo de vida do processo filho ao pidfd devolvido ao processo pai: ao fechar o pidfd, o processo filho é terminado. Assim, um supervisor que termine não deixa processos órfãos em execução.

Os mount namespaces receberam o mesmo tratamento. CLONE_EMPTY_MNTNS para clone3() e UNSHARE_EMPTY_MNTNS para unshare() criam um mount namespace vazio, em vez da cópia completa habitual dos mounts do processo pai, que o runtime teria depois de desmontar. FSMOUNT_NAMESPACE permite que fsmount() coloque um filesystem diretamente num namespace novo. Os runtimes de contentores montam esta configuração manualmente há uma década. Fazê-lo numa única chamada significa que um runtime já não começa com um namespace cheio dos mounts do host.

Na área da virtualização, guest_memfd passou a suportar userfaultfd, permitindo que um hypervisor trate page faults do guest a partir do espaço de utilizador. O KVM protegido em Arm passou a suportar memória anónima, embora o próprio merge indique que esta funcionalidade ainda não está pronta para produção.

Quando o kernel 7.1 chega ao seu servidor

O Fedora já o inclui. O repositório de atualizações do Fedora 44 passou para a série 7.1 durante julho e agosto de 2026, porque o Fedora atualiza o kernel para novas séries estáveis durante o ciclo de uma versão. O Arch e o openSUSE Tumbleweed também o incluem pelo mesmo motivo. Essas máquinas servem para testes, não para executar os seus serviços.

Todo o resto espera, e a espera é intencional. O Debian 13 foi lançado com o 6.12 e permanece no 6.12 durante todo o ciclo da versão, com as correções integradas nessa versão. O RHEL 10 foi lançado com o 6.12.0 e faz o mesmo. O Ubuntu 26.04 LTS foi lançado com o 7.0 em abril de 2026. O Ubuntu 24.04 LTS tem uma stack de habilitação de hardware, que obtém um kernel mais recente de versões posteriores do Ubuntu e o disponibiliza no LTS. Essa stack está no 6.17 a partir da versão pontual 24.04.4 e está programada para passar ao 7.0 com a versão 24.04.5, em 27 agosto 2026.

É aqui que as pessoas se enganam. Uma stack HWE passa para o kernel incluído na versão intermédia mais recente, por isso pode saltar completamente uma série do upstream. O 7.0 está num Ubuntu LTS. O 7.1 pode nunca ser a base de um LTS, porque a versão intermédia seguinte terá uma série posterior. O que chega ao seu LTS a partir do 7.1 são as correções, integradas na série que estiver a utilizar. As funcionalidades ficam, na sua maioria, na versão original.

Se quiser mesmo um kernel mais recente num servidor estável, as opções suportadas são poucas.

# Ubuntu 24.04 LTS: install the hardware enablement stack
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

# Debian 13, with trixie-backports enabled in your apt sources
apt-cache policy linux-image-amd64
sudo apt install -t trixie-backports linux-image-amd64
sudo reboot

Depois do reboot, confirme qual kernel foi efetivamente iniciado:

uname -r
dpkg -l 'linux-image-*' | grep ^ii
ls /var/run/reboot-required

uname -r deve agora mostrar a nova série, e dpkg -l mostra todas as imagens de kernel que continuam instaladas. Se uname -r mostrar a versão antiga enquanto dpkg -l listar a nova, o pacote foi instalado, mas o valor predefinido do bootloader não mudou: verifique as entradas do GRUB. A existência de /var/run/reboot-required significa que um pacote atualizou o kernel e que não foi feito nenhum reboot desde então. Esta é a razão mais comum para um servidor corrigido continuar a executar o código vulnerável.

Você deve correr atrás do 7.1 em um VPS de produção

Não. E o motivo não é cautela por si só. O kernel de uma distribuição faz parte de um contrato de suporte. Canonical, Red Hat, SUSE e Debian fazem backport de correções de segurança para a sua linha estável e testam-nas com o user space que distribuem com ela. Um kernel mainline de um arquivo de terceiros ou compilado manualmente oferece os recursos, mas elimina esse trabalho, porque ninguém faz backport das correções para a sua compilação. Você passa a ser o mantenedor de um kernel.

As exceções existem, mas são restritas: hardware que o kernel mais antigo não consegue controlar ou uma alteração de desempenho que você mediu na sua própria carga de trabalho e considera suficientemente importante para assumir as consequências. Em um VPS, a primeira situação quase nunca se aplica, porque o hardware que você vê é virtual. Para todo o resto, mantenha o kernel da distribuição atualizado e reinicie quando for solicitado. Se uma atualização da distribuição já estiver na sua lista, migrar do Ubuntu 24.04 para o 26.04 leva você da versão 6.8 para a 7.0 em uma única etapa, um salto maior do que qualquer pacote de kernel isolado oferece.

FAQ

Como verifico qual kernel Linux o meu VPS está a executar?

Execute uname -r. O comando apresenta algo semelhante a 6.8.0-79-generic. O número antes do primeiro hífen é a linha upstream na qual a sua distribuição se baseia. Tudo o que aparece depois é o número de compilação próprio da distribuição, que inclui correções portadas para essa linha. Em seguida, execute systemd-detect-virt. Se apresentar lxc ou openvz, está a usar virtualização por contentores, partilha o kernel do host e não pode alterá-lo. Se apresentar kvm, arranca a sua própria imagem de kernel e é responsável por fazer as atualizações.

O Linux 7.1 é um kernel com suporte de longo prazo?

Não. Em 11 August 2026, as linhas com suporte de longo prazo listadas em kernel.org são 6.18, 6.12, 6.6, 6.1, 5.15 e 5.10, e a versão 7.1 não está entre elas. É uma versão estável normal, e a respetiva linha estável deixa de receber atualizações pouco depois da publicação da versão mainline seguinte. Se pretende um kernel com vários anos de correções já aplicadas e vários anos de correções futuras, é isso que o kernel da sua distribuição já fornece.

Quando é que o Ubuntu ou o Debian vão disponibilizar o kernel 7.1?

Provavelmente nunca como versão predefinida. O Debian 13 mantém-se na versão 6.12 durante todo o ciclo de vida da versão, e o RHEL 10 mantém-se na versão 6.12.0. O Ubuntu 26.04 LTS foi disponibilizado com a versão 7.0, e uma stack de hardware enablement do Ubuntu passa para o kernel incluído na versão interim mais recente, podendo assim ignorar completamente uma linha upstream. Está previsto que o Ubuntu 24.04 LTS passe o seu kernel HWE para a versão 7.0 com a point release 24.04.5, em 27 August 2026. As correções da versão 7.1 chegarão através de backports para uma linha mais antiga. Normalmente, as funcionalidades não chegarão.

O que é que realmente importa no Linux 7.1 num servidor virtual privado?

Quatro itens. O leasing de filas de hardware permite que um contentor utilize uma fila real de uma NIC para AF_XDP à velocidade nativa. A terceira fase da reformulação do swap remove o mapa de swap estático e reduz em 30%, segundo os dados publicados, os metadados que o kernel mantém para o dispositivo de swap. O MGLRU pode verificar em lote os indicadores de páginas recentes, com o maior ganho publicado num servidor Arm com muitos núcleos. E clone3() ganhou CLONE_AUTOREAP, CLONE_NNP e CLONE_PIDFD_AUTOKILL, que tornam mais segura a supervisão de processos filho. Também foi adicionada proteção T10 ao nível do sistema de ficheiros, mas um disco virtual raramente expõe os metadados de integridade de que essa proteção necessita.

A atualização do kernel pode avariar o meu VPS?

As falhas mais comuns ocorrem durante o arranque. Um /boot cheio faz com que update-initramfs falhe com No space left on device durante a instalação, deixando o pacote parcialmente configurado: remova os kernels antigos com sudo apt autoremove --purge e reinstale. Os módulos externos compilados para o kernel antigo deixam de carregar. Por isso, tudo o que for gerido pelo DKMS tem de ser recompilado, e uma recompilação falhada só se torna evidente em runtime, quando o módulo está em falta. Se uname -r continuar a apresentar a versão antiga depois de um reboot, enquanto dpkg -l lista a nova imagem, a instalação não falhou: a predefinição do bootloader não foi alterada.