Kernel Live Patching no Linux: Canonical Livepatch, kpatch e KernelCare em 2026

Atualizado: 10 de agosto de 2026

Kernel live patching no Linux é a técnica de aplicar correções de segurança diretamente no kernel em execução, sem exigir reinicialização. Em 2026, três implementações dominam o mercado: Canonical Livepatch (Ubuntu), kpatch (Red Hat / RHEL) e KernelCare da TuxCare (multi-distro). Todas partem do mesmo framework livepatch mainline, mas divergem em cobertura de CVEs, janela de suporte por kernel e modelo de assinatura. Este guia mostra como cada uma funciona por dentro, como habilitar a Livepatch em produção e onde ficam os limites que ninguém coloca no marketing.

• O framework mainline livepatch combina o modelo per-task do kGraft com a verificação de stack trace do kpatch. Quem entrega os patches é a ferramenta de espaço de usuário (Livepatch, kpatch-build ou KernelCare).
• Canonical Livepatch cobre apenas CVEs de severidade alta e crítica e requer reinicialização a cada 13 meses por kernel para manter a janela de suporte deslizante.
• KernelCare da TuxCare cobre praticamente 100% dos CVEs de kernel, oferece lifetime ilimitado por kernel e estende cobertura para glibc e openssl via LibCare.
• Ubuntu 26.04 LTS e Ubuntu Core 26 trouxeram live patching para ARM64, resultado direto de reliable stacktraces upstream que só amadureceram em 2025.
• Livepatch não substitui reboots: atualizações de glibc, microcódigo de CPU, GRUB e mudanças de ABI de kernel continuam exigindo reinicialização.

O que é kernel live patching e como funciona

Live patching é a substituição de funções vulneráveis dentro do kernel em execução, feita por um módulo .ko assinado que é carregado pelo daemon do fornecedor (canonical-livepatch, kpatch, kcare). O módulo registra a nova versão da função na infraestrutura livepatch do kernel, que por sua vez usa ftrace para desviar as chamadas. A instrução NOP deixada por -mfentry no prólogo de cada função é reescrita para saltar ao código corrigido.

Passei seis anos no time de kernel da Canonical trabalhando exatamente com esse pipeline, do backport do fix upstream, passando pela compilação com kpatch-build, até a assinatura e distribuição via snap. Do lado do administrador, o que importa é que o processo é não-destrutivo: nenhum processo é morto, nenhum socket é fechado, nenhuma conexão TCP é derrubada. A latência da transição, em máquinas modernas, fica em poucos milissegundos e em geral não é observável por SLOs de aplicação.

O que não é óbvio: existem três camadas envolvidas. A infraestrutura mainline em kernel/livepatch/, presente desde o Linux 4.0; a ferramenta de build (kpatch-build), que compara .o antes e depois do fix e monta o módulo; e a ferramenta de entrega, que decide política, assinatura e canal de distribuição. É aqui que Livepatch, kpatch e KernelCare divergem, e confundir os três é o erro clássico do primeiro incidente em produção.

Canonical Livepatch, kpatch ou KernelCare: comparativo 2026

Quando um cliente Nórdico me chama para decidir entre as três, a resposta raramente é técnica; é operacional. Todos usam a mesma base upstream. O que diferencia é cobertura de CVEs, janela de suporte, licenciamento e se cobre bibliotecas de usuário. Abaixo, a comparação atualizada para 2026:

Dimensão	Canonical Livepatch	kpatch (Red Hat)	KernelCare (TuxCare)
Distribuições suportadas	Ubuntu LTS 16.04+ e Ubuntu Core	RHEL 7/8/9/10, CentOS Stream	Ubuntu, RHEL, Rocky, Alma, Debian, Amazon Linux, Oracle
Cobertura CVEs kernel	Apenas Alta e Crítica (~5–10%)	~10%, kernels elegíveis por trimestre	Praticamente 100%
Janela de suporte por kernel	13 meses deslizantes	~1 ano por kernel elegível	Ilimitada
Patch de glibc / openssl	Não	Não	Sim, via LibCare
Requer subscrição paga	Sim (grátis até 5 máquinas)	Bundle RHEL	Sim (~US$ 50/host/ano)
Rollout controlado (janelas)	Sim (via Landscape)	Manual	ePortal centralizado
Cobertura ARM64	Sim (Ubuntu 26.04+)	Limitado	Sim

Regra prática: se sua frota é 100% Ubuntu e você já paga Ubuntu Pro, Livepatch é o menor caminho de resistência. Instalação com um comando, integração com unattended-upgrades e gestão via Landscape. Para frotas mistas (parques com Rocky, Debian e Amazon Linux), o TCO do KernelCare compensa por eliminar três pipelines de patching. Honestamente, o kpatch puro só faz sentido para quem tem competência interna de kernel e um punhado de máquinas custom. O esforço para manter kpatch-build em uma organização não trivial é subestimado sistematicamente.

Como habilitar o Livepatch no Ubuntu 24.04 e 26.04

O caminho suportado desde a consolidação do Ubuntu Pro Client em 2023 usa o comando pro. Em Ubuntu 24.04 e 26.04 o cliente já vem instalado, mas convém atualizar antes:

# Confirma versão do Pro Client (v31+ em 2026)
sudo apt update && sudo apt install -y ubuntu-pro-client
pro --version

# Anexa a máquina à sua conta Pro (token do dashboard ubuntu.com/pro)
sudo pro attach C1nH4Q...seuTokenAqui

# Habilita explicitamente o Livepatch (em LTS costuma auto-habilitar)
sudo pro enable livepatch

# Verifica o status agregado dos serviços Pro
sudo pro status

A saída de pro status mostra livepatch yes enabled Canonical Livepatch service. Para o estado detalhado do cliente, incluindo qual patch está aplicado ao kernel corrente e a versão do módulo, use o binário do snap:

# Estado detalhado do Livepatch
sudo canonical-livepatch status --verbose

# Força uma checagem imediata (por padrão roda a cada 30 min)
sudo canonical-livepatch check

# Se precisar reiniciar o daemon (raro; útil após config)
sudo snap restart canonical-livepatch

# Logs em tempo real durante uma janela de manutenção
sudo snap logs -n 100 -f canonical-livepatch

Um detalhe que economiza noites de plantão: o comando pro reboot-required retorna yes-kernel-livepatches-applied quando há atualizações de kernel pendentes em disco mas o Livepatch já cobriu o buraco em memória. Use isso no seu playbook. Não faz sentido acordar o oncall para um reboot que o Livepatch já mitigou. Combinado com hardening de serviços systemd e uma estratégia de auditoria contínua com Lynis e CIS Benchmarks, você reduz drasticamente a janela de exposição de vulnerabilidades sem impacto operacional.

Modelo de consistência: ftrace, per-task e stack unwinding

Para entender por que algumas correções são "livepatchable" e outras não, é preciso entender o modelo de consistência. Quando uma função é substituída em memória, o kernel precisa garantir que nenhuma thread está executando a versão antiga no momento exato do swap. Trocar uma função enquanto ela roda em um contexto (ou pior, enquanto detém locks que a versão nova reordena) é receita para deadlock ou corrupção silenciosa. O mainline resolve isso com um modelo híbrido documentado em kernel/livepatch.

O modelo funciona em três etapas. Primeiro, o Livepatch entra em estado de transição: cada task recebe uma flag indicando se deve executar a versão nova ou a antiga. Segundo, para cada task sleeping, o kernel percorre o stack trace (a chamada de reliable stacktrace, que precisa ser confiável, senão o kernel se recusa a aplicar) e verifica se alguma função patcheada está no caminho de retorno. Se não estiver, a task é marcada como convertida. Se estiver, o kernel espera e tenta de novo depois. Terceiro, quando todas as tasks convergiram, os trampolines ftrace são removidos e a transição termina, normalmente em poucos segundos.

Diferente do stop_machine() original do kpatch, o mainline não pausa todas as CPUs. Diferente do kGraft puro, ele não deixa versões antigas e novas coexistindo indefinidamente para tasks bloqueadas em I/O de longa duração. É o compromisso híbrido que a comunidade fechou em 2016. Consequência prática: patches que exigem mudança sincronizada de múltiplas funções interdependentes, ou que alteram estruturas de dados persistentes, raramente são livepatchables, e nesses casos o vendor emite um patch tradicional que exige reboot.

A regra dos 13 meses e por que reboots ainda existem

A limitação mais mal compreendida do Livepatch é a janela de suporte deslizante de 13 meses introduzida pela Canonical em 2023. Cada revisão de um kernel GA de LTS recebe livepatches por 13 meses; depois disso, você precisa instalar a próxima revisão do kernel e reiniciar para "resetar o relógio" e continuar recebendo patches. Isso é declarado explicitamente na documentação oficial do Livepatch em ubuntu.com/security/livepatch.

A racional por trás disso é sã do ponto de vista de engenharia: cada patch subsequente é cumulativo (contém todos os anteriores), e o custo de manter compatibilidade binária com kernels antigos cresce quadraticamente. Depois de 13 revisões cumulativas, a probabilidade de um patch "não caber" na versão originalmente rodando aumenta ao ponto em que a segurança do sistema fica comprometida por defeitos de aplicação. Reset via reboot é uma escolha operacional deliberada, não incompetência.

Outros itens que continuam exigindo reboot mesmo com Livepatch feliz e verde:

• Atualizações de glibc, libc6, openssl: Livepatch cobre apenas o kernel. Bibliotecas de espaço de usuário são responsabilidade do unattended-upgrades (ou LibCare no caso do KernelCare).
• Microcódigo de CPU (Intel/AMD updates): carregado no boot early, não pode ser trocado a quente com garantias.
• GRUB e bootloader: mudanças só valem no próximo boot.
• Kernels com mudança de ABI: novas ABIs implicam recompilação de módulos out-of-tree (ZFS, DKMS, drivers proprietários) e não são livepatchable por definição.
• Serviços como SSH, nginx, PostgreSQL: patches de openssl exigem restart do serviço. Combine com uma estratégia sólida de hardening de SSH com OpenSSH 10 para minimizar impacto.

Quais CVEs o Livepatch cobre (e quais ficam de fora)

Canonical Livepatch aplica patches para vulnerabilidades classificadas como Alta ou Crítica na escala CVSS 3.1 e na priorização Ubuntu (que difere ocasionalmente da NVD por análise de exploitabilidade real). Bugs de severidade Média e Baixa não recebem livepatch. A lógica é que o risco de introduzir defeito ao aplicar patch a quente supera o benefício marginal de fechar um vetor de baixa exploração.

Isso deixa uma superfície não trivial fora da cobertura. Historicamente, ~5% a 10% dos CVEs anuais de kernel se qualificam para livepatch; o restante fica em fila para o próximo update de pacote convencional. Não é uma falha do produto, é uma escolha explícita sobre risco versus disponibilidade. Para operadores acostumados a "cobertura 100%" de scanners como Trivy e Grype para containers, o número pode assustar. Contexto: containers rodam sobre um kernel do host, e o vetor de kernel é uma superfície separada e menor da árvore de exposição total.

Categorias que tipicamente ganham livepatch rápido:

• Escalação de privilégio local via bugs em eBPF, io_uring, overlayfs ou user namespaces, vetores clássicos de container escape.
• Remote code execution em drivers de rede (WiFi, Bluetooth). Ubuntu preemptivamente livepatcha antes de exploits públicos.
• Race conditions em subsistemas core (mm/, fs/) quando o backport não altera estrutura persistente.

Já não ganham livepatch:

• DoS de baixo impacto que exigem privilégio local não-root.
• Vulnerabilidades em módulos raramente carregados (drivers exóticos, filesystems legacy).
• Fixes que reordenam locks ou mudam layout de struct exportadas.
• Qualquer coisa que exija novos features upstream (Livepatch é sempre bugfix-only).

Live patching em ARM64: a novidade de 2026

A novidade concreta de 2026 é o suporte a ARM64. Live patching em ARM já existia experimentalmente há anos, mas ganhou status GA apenas no Ubuntu 26.04 LTS e Ubuntu Core 26. O gap era técnico: ARM64 upstream não tinha implementação estável de reliable stacktraces, e a toolchain (GCC, objdump, kpatch) não fechava. Segundo o anúncio oficial da Canonical sobre live kernel patching para ARM64, os primeiros patches começaram a rodar em ambiente de teste em fevereiro de 2026.

Para quem opera frotas em Graviton (AWS), Ampere Altra (Oracle Cloud, Hetzner) ou Apple Silicon em labs, isso é a diferença entre "não temos live patching" e "temos paridade com x86_64". Se você está migrando workloads para ARM em 2026, o timing é bom. A base de código está estável, o pipeline de CVE backport da Canonical opera em ambas as arquiteturas e o modelo de subscrição não muda.

Do ponto de vista prático, o comando é idêntico ao x86_64:

# Em uma instância ARM64 Ubuntu 26.04
uname -m                                # arm64
sudo pro enable livepatch
sudo canonical-livepatch status         # deve mostrar Architecture: arm64

Sistemas em ARM64 rodando Ubuntu 22.04 ou 24.04 não recebem retroativamente o suporte: a dependência de reliable stacktraces é kernel 6.8+. Planeje o upgrade de LTS se essa cobertura for parte do compliance requirement.

Operação em produção: rollouts, Landscape e observabilidade

Habilitar Livepatch em uma máquina é trivial. Operar em 500 hosts com política diferenciada por tier de serviço não é. O componente que separa o brinquedo do sistema de produção é o Landscape, plataforma de gestão da Canonical que você usa via Ubuntu Pro Client integrado para orquestrar rollouts.

O padrão que costumo recomendar para clientes com frotas médias (~100 a 2000 hosts):

1. Tier canário (2 a 5% da frota, hosts não-críticos): patches aplicados imediatamente, sem delay. Configure com pro config set livepatch.delay=0.
2. Tier stable (produção normal, ~90%): delay de 24 horas via política do Landscape. Isso dá tempo para o canário revelar problemas.
3. Tier crítico (bancos de dados, jump hosts, sistemas de pagamento): delay de 72 horas e revisão manual do changelog do patch antes de aprovação em ePortal / Landscape.

Observabilidade importa mais do que a maioria dos guias sugere. Emissão de patches gera eventos que você deve ingerir, não apenas contemplar. Um padrão simples: um script no cron parseia canonical-livepatch status --format json e publica em Prometheus via node_exporter textfile collector. Métricas úteis: livepatch_kernel_patch_state (applied, checking, unable), livepatch_last_check_seconds_ago, livepatch_kernel_age_days (para monitorar a proximidade dos 13 meses). Alertar em kernel_age_days > 300 te dá 65 dias para planejar a janela de reboot.

Combine isso com detecção de intrusões via Wazuh e Auditd para correlacionar alertas de tentativa de exploração de CVE com a janela em que o Livepatch já foi aplicado. Em incidentes reais, essa correlação diz se o exploit chegou antes ou depois do fix.

Perguntas frequentes

Ubuntu Livepatch é gratuito?

Sim, para até 5 máquinas por conta Ubuntu One (tier "Personal"). Acima disso é necessária subscrição paga Ubuntu Pro, cotada por host. Para uso comercial ou frotas maiores, o valor entra no contrato geral de suporte Canonical.

Livepatch elimina a necessidade de reiniciar servidores?

Não completamente. Livepatch adia reboots para janelas planejadas ao aplicar correções críticas de kernel em memória, mas a cada 13 meses por revisão de kernel você precisa reiniciar para renovar a janela de suporte. Além disso, atualizações de glibc, microcódigo de CPU e mudanças de ABI continuam exigindo reboot.

Qual a diferença entre Canonical Livepatch e kpatch?

Ambos usam o framework mainline livepatch do kernel. Canonical Livepatch é a implementação comercial da Canonical para Ubuntu, com patches assinados e distribuídos automaticamente via snap. kpatch é a ferramenta open-source da Red Hat que compila e aplica patches manualmente, é o "motor" cru, sem infraestrutura de entrega.

Livepatch cobre vulnerabilidades como Dirty COW e overlayfs?

Sim, historicamente vulnerabilidades de alta severidade em overlayfs, io_uring, eBPF e user namespaces são as primeiras a receber livepatches. São vetores comuns de container escape e escalação de privilégio. Vulnerabilidades classificadas como Média ou Baixa na priorização Ubuntu não recebem livepatch e ficam para o ciclo regular de atualização.

Como saber qual kernel está protegido pelo Livepatch neste momento?

Execute sudo canonical-livepatch status --verbose. A saída lista o kernel corrente (Kernel:), a versão do patch aplicado em memória (Version:), os CVEs cobertos (fixes:) e o estado geral (State: applied significa proteção ativa). Combine com pro reboot-required para verificar se ainda é preciso reiniciar apesar do patch em memória.

O Livepatch funciona em Ubuntu 26.04 LTS ARM64?

Sim. O suporte a live patching em ARM64 chegou como GA no Ubuntu 26.04 LTS e Ubuntu Core 26, após anos de trabalho upstream em reliable stacktraces e toolchain. Releases anteriores (22.04, 24.04) em ARM64 não recebem suporte retroativo, então é preciso fazer upgrade de LTS para habilitar o serviço.