v0idnetwork/cve-2026-46331pedit COW
CVE-2026-46331 (apelidada de “pedit COW”) é uma falha local de escalonamento de privilégio no kernel do Linux no subsistema de controle de tráfego. Um usuário não privilegiado (em um namespace de rede não privilegiado) pode configurar o filtro act_pedit (editor de pacotes) para acionar uma escrita parcial copy-on-write (COW) no cache de páginas. Efetivamente, o kernel escreve dados controlados pelo atacante na imagem em memória de um arquivo sem marcar a página como privada, corrompendo a cópia em cache desse arquivo. Crucialmente, o exploit requer apenas CAP_NET_ADMIN (obtível em um namespace de usuário) e não modifica o arquivo em disco. Na prática, uma prova de conceito (PoC) funcional chamada packet_edit_meme foi publicada em 17 de junho de 2026, demonstrando como sobrescrever a imagem do cache de páginas de um binário setuid (ex.: /bin/su) para obter um shell root. A vulnerabilidade decorre de um cálculo incorreto do intervalo COW em tcf_pedit_act() e foi corrigida upstream (4 de junho de 2026) movendo a verificação da região gravável para dentro do loop por chave.
act_pedit. Versões estáveis sem correção (incluindo muitos kernels de distribuições) são vulneráveis.tc e sobrescreve o ponto de entrada ELF de um binário setuid na memória com shellcode.skb_ensure_writable() para dentro do loop de chaves). Como solução alternativa, bloqueie ou descarregue o módulo act_pedit ou desabilite namespaces de usuário não privilegiados (ex.: sysctl user.max_user_namespaces=0). Após a mitigação, limpe os caches (echo 3 > /proc/sys/vm/drop_caches) para remover quaisquer páginas envenenadas.Este relatório fornece uma análise técnica detalhada do CVE-2026-46331: sua causa, exploração, detecção e estratégias de remediação, com referências a avisos de fornecedores, CVEs e o exploit público.
Definição: CVE-2026-46331 é um bug de escrita fora dos limites no subsistema Traffic Control (net/sched) do kernel do Linux, especificamente na ação act_pedit (editor de pacotes). A função tcf_pedit_act() calcula um intervalo “copy-on-write” para operações de edição de pacotes antes de iterar sobre as chaves tipadas, usando uma dica estática tcfp_off_max_hint. No entanto, algumas chaves (ex.: edições de cabeçalho TCP/UDP) determinam seu deslocamento final de byte apenas em tempo de execução. O código nunca reverifica a capacidade de escrita para esses deslocamentos dinâmicos. Como resultado, escritas podem ocorrer fora da região pré-COW: parte da escrita do pacote nunca é tornada privada, levando a um COW parcial. Essa escrita errônea se propaga para a memória do cache de páginas compartilhada de um arquivo (se os buffers do pacote referenciarem páginas de arquivo), corrompendo a imagem em cache do arquivo.
Contexto: A ação editor de pacotes (pedit) do Linux permite que administradores reescrevam bytes arbitrários dentro de cabeçalhos de pacotes (camadas de enlace, rede ou transporte) à medida que os pacotes atravessam um filtro tc configurado. Funciona especificando um deslocamento (possivelmente ancorado a um cabeçalho) e um valor/máscara de 32 bits. Internamente, pedit opera em socket-buffers (sk_buff) e deve tornar a memória do pacote alvo gravável antes de modificá-la (via skb_ensure_writable() no estilo COW). Idealmente, o kernel deve clonar (cópia privada) quaisquer páginas compartilhadas antes de escrever para evitar alterar memória usada em outro lugar.
Causa Raiz: Em tcf_pedit_act(), o código calcula erroneamente o intervalo gravável apenas uma vez no início, usando tcfp_off_max_hint (o deslocamento estático máximo). Essa dica não inclui nenhum deslocamento de cabeçalho em tempo de execução que as chaves tipadas adicionam quando o pacote está sendo processado. Chaves como TCP ou UDP podem calcular um deslocamento com base na posição do cabeçalho IP em tempo de execução (por exemplo, se uma chave anterior deslocar o cabeçalho de rede). Assim, durante o loop por chave, o deslocamento real para uma chave pode exceder o intervalo que foi pré-alocado como gravável. O código então escreve na memória do pacote via skb_store_bits(), mas como a página além da região pré-COW não foi tornada privada, a escrita corrompe uma página que ainda está compartilhada com o cache de páginas. Em resumo, “calcular o intervalo gravável do pacote muito cedo” causa uma escrita fora dos limites entre páginas. Deslocamentos negativos (ex.: editar cabeçalhos Ethernet na entrada) também são maltratados, e até mesmo offset_valid() carecia de uma proteção para INT_MIN, agravando a falha.
Por Que Isso Acontece: Esse bug é essencialmente um erro de lógica no cálculo do intervalo copy-on-write. O kernel assumiu que o deslocamento estático máximo (conhecido no momento do carregamento) era suficiente para todas as edições. Ele não atualizou o intervalo COW quando chaves com deslocamentos dinâmicos eram realmente aplicadas. Após uma série de edições em fila, a escrita final poderia ficar fora da região pré-verificada. Como os buffers de pacotes podem referenciar páginas de arquivo mapeadas em memória (ex.: via mecanismos de cópia zero), essa escrita “COW parcial” pode alcançar o cache de páginas de um arquivo em disco. Na prática, a ação do editor de pacotes pode receber páginas de um sendfile ou splice; assim, uma única operação de filtro de pacotes pode indiretamente escrever dados escolhidos pelo atacante na imagem em memória de um arquivo, sem alterar o disco.
Componentes e Fluxo de Dados: O código vulnerável reside no subsistema net/sched do Linux (act_pedit.c). Quando um pacote corresponde a uma regra pedit configurada, tcf_pedit_act() é invocada. Internamente, ela chama skb_ensure_writable(skb, X) exatamente uma vez, onde X = tcfp_off_max_hint. Isso torna os primeiros X bytes do pacote privados (COW). Então, em um loop sobre cada chave (operação de edição), ela calcula o deslocamento real da chave somando o deslocamento do cabeçalho em tempo de execução ao deslocamento especificado da chave, e escreve um valor de 32 bits no pacote. Em pseudocódigo:```c
u32 off_max = action->tcfp_off_max_hint;
skb_ensure_writable(skb, off_max);
for (i = 0; i < num_keys; i++) {
u32 hdr_off = compute_header_offset(skb, key[i].hdr_type);
u32 write_off = hdr_off + key[i].offset;
skb_store_bits(skb, write_off, &key[i].value, 4);
}
Porque `hdr_off` só é calculado ao processar cada chave, a chamada inicial `skb_ensure_writable()` não levou isso em conta. Se `hdr_off + key[i].offset` exceder `off_max`, o código recorre a `skb_store_bits()` em fragmentos em vez da área linear principal, ou seja, escreve em uma página que não foi tornada privada. Esse é o ponto de falha.
**Superfície de Ataque:** A única interface necessária é o **filtro tc** com uma ação `pedit`, que normalmente requer a capacidade **CAP_NET_ADMIN**. No entanto, usuários comuns podem obter CAP_NET_ADMIN dentro de um namespace de rede privado (clonagem de namespace de usuário) sem privilégios reais. Assim, um usuário não privilegiado pode entrar em um namespace user+net e criar uma regra `tc pedit` no loopback. A escrita ocorre quando um pacote é processado (o atacante geralmente gera tráfego no loopback para acioná-lo). O limite de confiança (usuário vs kernel) é cruzado porque o kernel confiou em sua própria configuração de COW, mas os offsets fornecidos pelo usuário quebraram essa suposição.
**Mecanismo Interno:** No lado do kernel, a vulnerabilidade se manifesta como uma **escrita fora dos limites** (CWE-787). Ela corrompe a memória do kernel que está mapeada no espaço do usuário (cache de páginas de arquivo). Especificamente, pode sobrescrever o conteúdo de qualquer página de arquivo que esteja mapeada no buffer do socket. Na prova de conceito, `/bin/su` é mapeado via mmap ao ser enviado para o buffer do socket, então o exploit modifica os bytes do ponto de entrada na memória. Isso não altera o arquivo no disco, mas qualquer execução subsequente desse binário lê a imagem envenenada do cache. A análise do blog observa:
> “Como o skb pode referenciar páginas de cópia zero obtidas via sendfile, essa escrita fora dos limites pode cair na memória compartilhada do cache de páginas que dá suporte a um arquivo real. O kernel acredita que tornou a memória do pacote segura para modificação; na realidade, a escrita posterior atinge uma região fora da que ele realmente privatizou.”
**Limites de Confiança:** O kernel assumiu erroneamente que `skb_ensure_writable()` (COW de caminho rápido) garantiria segurança para todas as escritas subsequentes. Ele não verificou novamente para cada chave. O usuário controla apenas a configuração do filtro de pacotes e o conteúdo do pacote; o kernel concedeu isso (através de namespaces de rede). Uma vez que essa confiança foi quebrada, a escrita escapou para a memória de arquivo que deveria estar protegida.
## Análise de Causa Raiz
A causa raiz é **cálculo incorreto do intervalo de COW na ação pedit**. Em termos de código, uma única chamada `skb_ensure_writable()` foi feita com um comprimento baseado em `tcfp_off_max_hint`; depois, dentro do loop, os offsets reais podiam exceder isso. Um pequeno patch (maio de 2026) corrige isso movendo `skb_ensure_writable()` *para dentro* do loop, após o offset verdadeiro ser conhecido, e adicionando verificações e tratamento especial para offsets negativos. Em outras palavras:
- **Código com bug:** ```c
skb_ensure_writable(skb, action->tcfp_off_max_hint);
for each key:
// compute offset (hdr_off + key_offset)
skb_store_bits(skb, write_off, ...);
Além disso, a correção garante que para deslocamentos negativos (edições no cabeçalho Ethernet) ela use skb_cow() no espaço livre e proteja contra casos de INT_MIN. A mensagem de commit (resumo stack.watch) afirma: “Corrigir movendo skb_ensure_writable() para dentro do loop por chave, onde o deslocamento real de gravação é conhecido, e adicionar verificação de estouro na aritmética de deslocamento.”.
Assim, por que existe: durante a revisão de código ou projeto, o recálculo por chave foi negligenciado. A otimização de dica estática contornou a necessidade de reavaliar por chave. Parece ser um erro honesto em vez de uma omissão maliciosa, mas seu efeito é severo porque viola a suposição de COW. Como observa a TuxCare, esse bug foi mesclado sob o disfarce de uma correção rotineira de “corrupção de dados”, sem contexto imediato de segurança.
A vulnerabilidade foi introduzida pelo commit do kernel 8b796475fd78 (maio de 2022) e permaneceu despercebida até o início de 2026. De acordo com fontes, a correção (commit 899ee91156e5 em 31 de maio de 2026) foi submetida à lista de discussão netdev como um patch comum de corrupção de dados. Os mantenedores do kernel mesclaram a correção (net-7.1-rc7) em 4 de junho de 2026. Apenas em 16 de junho de 2026 foi formalmente atribuído o CVE-2026-46331 (cerca de duas semanas após o patch aparecer). Um exploit público totalmente funcional apareceu em 17 de junho de 2026 (o PoC packet_edit_meme).
Na prática, a sequência foi:
Várias partes notaram o bug através do patch aberto. Por exemplo, Massimiliano Oldani (pesquisador de cibersegurança) publicou um artigo detalhado e um exploit logo depois, observando que “um exploit de prova de conceito público e funcional chamado packet_edit_meme apareceu no GitHub dentro de 24 horas após a atribuição do CVE”. CloudLinux, TuxCare e SentinelOne publicaram análises assim que o PoC se tornou público e os CVEs foram atribuídos. O rastreador de segurança do Debian e o PT DBugs também resumiram o problema e os avisos disponíveis (consulte as Referências).
Um ataque realista requer pré-condições mínimas:
Capacidades do atacante: Um usuário local não privilegiado na máquina alvo. O usuário deve ser capaz de criar um novo namespace de usuário com namespace de rede (via unshare(CLONE_NEWUSER|CLONE_NEWNET)), o que concede CAP_NET_ADMIN dentro desse namespace sem privilégios root reais. Namespaces de usuário não privilegiados estão habilitados por padrão em muitos kernels (ex.: RHEL, Debian) e podem ser reativados no Ubuntu com uma solução alternativa aa-exec.
Condições do alvo: O alvo deve estar executando um kernel Linux vulnerável (aproximadamente 5.18–7.1-rc6) com o módulo act_pedit disponível. Se act_pedit estiver embutido ou já carregado, é imediatamente explorável. Se for um módulo, ele carrega automaticamente quando uma regra tc pedit é configurada. O alvo não deve ter aplicado o patch upstream. Notavelmente, não é necessário que o atacante tenha acesso de gravação a qualquer arquivo; o exploit funciona escrevendo através de filtros de pacotes.
Cadeia de ataque:
unshare --map-root-user --net --pid bash para criar um novo namespace de usuário e rede. Isso concede CAP_NET_ADMIN nesse namespace (usuário mapeado como root internamente).ifconfig lo up) e opcionalmente inicia um listener (ex.: nc -l 127.0.0.1 9999). Isso fornece um fluxo de pacotes para usar nas ações do TC.Impacto: Se bem-sucedido, o atacante obtém privilégios totais de root localmente. O exploit pode ser feito em um comando e é determinístico. Além disso, a corrupção de páginas arbitrárias com suporte de arquivo poderia causar negação de serviço (crash do sistema) se usada de outra forma. O PoC publicado sobrescreveu especificamente o ponto de entrada do /bin/su com shellcode, mas qualquer arquivo que o atacante possa mapear poderia ser alvo. A cadeia não requer sincronização ou condição de corrida especial e foi demonstrada em muitas distribuições (RHEL, Ubuntu, Debian, etc.).
Um exploit público, packet_edit_meme, está disponível no GitHub (sgkdev/packet_edit_meme) e tem como alvo /bin/su. Descrevemos sua lógica essencial sem payloads destrutivos:```c
/* Pseudocode outline of the exploit (simplified) /
int main() {
/ 1. Identify a setuid binary (su) and its ELF entry offset */
int fd = open("/bin/su", O_RDONLY);
long entry = elf_entry_offset(fd);
if (entry < 0) abort();
printf("Target %s (UID=%d), entry offset 0x%lx\n", "/bin/su", getuid(), entry);
/* 2. Unshare user+net namespace to get CAP_NET_ADMIN locally */
if (unshare(CLONE_NEWUSER | CLONE_NEWNET) < 0) abort();
/* Map UID/GID to root (handled via /proc/self/uid_map, /gid_map) */
// (omit details: write "0 <uid> 1" to /proc/self/uid_map and gid_map, and deny setgroups)
/* 3. Setup environment: bring up loopback and listener */
if (system("ip link set lo up") < 0) abort();
if (system("nc -l 127.0.0.1 9999 &") < 0) abort();
/* 4. Configure a tc pedit action via netlink (simplified) */
// Assume 'pedit_write' sends a packet-edit command to the kernel.
// The key offsets below are chosen such that they exceed the initial COW range.
char shellcode[/*size=48*/] = {
// (assembly for setgid(0); setuid(0); execve("/bin/sh").., padded to 36 or 48 bytes)
};
size_t total = sizeof(shellcode), sent = 0;
while (sent < total) {
int chunk = min(PEDIT_MAX_WRITE, total - sent);
/* Issue TC pedit action to write next chunk */
if (pedit_write(fd, entry + sent, &shellcode[sent], chunk) != 0) {
fprintf(stderr, "pedit_write failed\n");
exit(1);
}
sent += chunk;
}
/* 5. Trigger execution of su (in original namespace) */
execl("/bin/su", "su", NULL); // This will run the poisoned binary as root
return 0;
}
Este pseudocódigo ilustra o fluxo: abrir `/bin/su`, usar `unshare` de namespaces para obter CAP_NET_ADMIN, configurar regras de loopback e TC pedit, e então chamar a função `pedit_write(fd, offset, data, len)` (no PoC real, isso usa chamadas netlink internamente) para sobrescrever o cache de página do alvo. Finalmente, o binário é executado, gerando um shell root.
O PoC real é mais elaborado (lidando com mapas UID/GID, escuta de rede e bytes de shellcode a nível de syscall), mas o conceito central é o descrito acima. Enfatizamos **não executar este exploit** exceto em um ambiente de teste seguro, e não mirar em nenhum sistema real. O acima é apenas para demonstração.
**Nota:** Se não houvesse nenhum PoC público seguro de usar, declararíamos isso explicitamente. Neste caso, o PoC é público, e o descrevemos conceitualmente. Omitimos os bytes brutos de shellcode e os detalhes reais de netlink por brevidade e segurança.
## Fluxo de Exploração
1. **Ponto de Entrada:** O atacante deve primeiro obter CAP_NET_ADMIN. Tipicamente, isso significa criar um namespace de usuário+rede (`unshare`) a partir de um processo não privilegiado, que concede CAP_NET_ADMIN local ao namespace.
2. **Acesso Inicial:** Dentro deste namespace, o atacante pode usar ferramentas normais (`ip`, `tc`) para configurar o controle de tráfego. O caminho de código `act_pedit` do kernel agora está acessível para pacotes.
3. **Disparo:** O atacante configura um `tc filter ... action pedit` na interface loopback. Este filtro corresponde a pacotes (por exemplo, 0-match) e especifica uma ou mais **chaves tipadas** com tipos de cabeçalho (IP, TCP) e deslocamentos. Os deslocamentos são escolhidos de modo que *após o kernel calcular a base do cabeçalho dentro do loop*, o deslocamento final de escrita exceda o intervalo inicial de COW.
4. **Exploração:** Quando um pacote correspondente ao filtro é processado, o kernel chama `tcf_pedit_act()`. Ele realiza uma chamada *insuficiente* a `skb_ensure_writable()` e então itera sobre as chaves. Para pelo menos uma chave, a escrita atinge uma página que *não* foi clonada para uma cópia privada. Isso causa uma **escrita fora dos limites** no cache de página compartilhado. Se o buffer de socket foi preparado para referenciar páginas de um arquivo (via sendfile/splice), essa escrita corrompe essas páginas do arquivo.
5. **Pós-Exploração:** O shellcode do atacante foi escrito no pagecache do binário alvo (por exemplo, `/bin/su`). O atacante (no namespace original) então executa `/bin/su`. O kernel lê a imagem na memória (com o payload injetado) e executa o shellcode, dando ao atacante um shell root. Neste ponto, ocorreu um comprometimento total do sistema.
6. **Impacto:** O atacante obtém privilégios de root. Dados confidenciais podem ser sobrescritos, mas não vazados diretamente. A integridade é completamente quebrada (o atacante pode alterar a imagem de memória de qualquer arquivo). A disponibilidade também pode ser afetada (escrever incorretamente em páginas críticas pode travar processos ou o sistema). Métricas CVSS: Médio no geral (CVSS 3.1=6.0), mas o impacto real é root local severo.
Este fluxo é resumido diagramaticamente:```mermaid
flowchart LR
A[Attacker (unprivileged user)] --> B[Unshare into user+net namespace<br>(gains CAP_NET_ADMIN)]
B --> C[Configure TC pedit filter on lo]
C --> D{Packet processing by kernel}
D --> E[act_pedit computes wrong COW range]
E --> F[skb_store_bits writes beyond COW'd region]
F --> G[Page cache of target file is corrupted]
G --> H[Attacker executes poisoned setuid binary]
H --> I[Root shell obtained]
act_pedit aparece em lsmod inesperadamente em sistemas que normalmente não usam tc pedit (ex.: lsmod | grep act_pedit não vazio em servidores web).tc: Comandos tc incomuns ou mensagens netlink de processos não privilegiados. Logs de auditoria podem mostrar CAP_NET_ADMIN concedido a um processo não root.netstat -tulnp mostrando nc ou um ouvinte personalizado em 127.0.0.1 pode ser um sinal.tcf_pedit_act, skb_ensure_writable, ou soft lockups durante tráfego intenso em loopback ou erros no processamento de tc. (Isso seria incomum e indicativo de corrupção.)Por exemplo, um IOA é arquivos corrompidos no cache de páginas: uma lista de verificação de triagem pode incluir a verificação do conteúdo do arquivo na memória versus o disco, especialmente para binários setuid após atividade intensa de tc. Outro é criação de novo namespace: monitorar chamadas para unshare(CLONE_NEWUSER|CLONE_NEWNET) pode ser sinalizado. Em resumo, defensores devem observar qualquer um dos seguintes: uso de act_pedit, uso de userns e modificações repentinas de executáveis na RAM.
Para detectar tentativas de exploração:
tc ou mensagens netlink que adicionam um filtro act_pedit. Por exemplo, regras Sigma podem procurar por eventos contendo TCA_ACT_KIND: pedit ou similar. Monitore logs de auditoria para capset CAP_NET_ADMIN de processos não root, ou escritas em /proc/*/uid_map./bin/su (ou outros binários sensíveis) e repentinamente executando-os em conjunto com chamadas de sistema namespace/unshare. Alertar sobre qualquer processo que tanto abra um binário setuid quanto crie um userns.skb_ensure_writable() não possa ser enganado (embora não exista verificação embutida conhecida).Em resumo, defensores devem registrar e auditar o uso de namespace de usuário, comandos tc e cargas de módulos. Uma abordagem chave: rejeitar ou registrar qualquer invocação de tc pedit por usuários não confiáveis. Em hosts comprometidos, verificar se /etc/modprobe.d/disable-act_pedit.conf foi aplicado (deve ser aplicado preventivamente).
Aplicar Patches: A correção principal é uma atualização do kernel. Todas as principais distribuições lançaram atualizações em junho de 2026. Atualizar para um kernel corrigido (Linux 7.1.0 ou posterior, ou backports da distribuição) é a solução definitiva.
Alterações de Configuração: Se a aplicação de patches não for imediatamente possível, implementar mitigações:
act_pedit: Se suas cargas de trabalho não exigem tc pedit, coloque o módulo na lista negra. Por exemplo: ```
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf
lsmod | grep -w act_pedit && sudo rmmod act_pedit
Isso garante que a ação não pode ser carregada. (Isso é recomendado pela CloudLinux e pela TuxCare.) Não aplique em hosts que usam legitimamente tc pedit.
No Ubuntu 22.04+: ``` sudo sysctl -w kernel.unprivileged_userns_clone=0 echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf
Isto impede que utilizadores não privilegiados criem o namespace de utilizador necessário para obter CAP_NET_ADMIN. Nota: desativar namespaces pode quebrar contentores rootless e algumas aplicações em sandbox.
- **Drop Page Cache (Containment):** Se suspeitar que o exploit foi executado, as cópias em memória dos binários podem estar envenenadas. Imediatamente limpe os caches para removê-los: ```
sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"
Isto força as páginas a serem recarregadas a partir do disco. Ressalva: Se um atacante já tinha root, limpar caches não removerá qualquer persistência que ele tenha instalado. Trate esses hosts como comprometidos.
Menor Privilégio: Audite e restrinja quem pode usar tc. O exploit precisa apenas de CAP_NET_ADMIN; garanta que apenas administradores confiáveis tenham essa capacidade. Use RBAC ou conteinerização para limitar as concessões de capacidade.
Controles de Rede: Embora não seja diretamente explotável via rede, monitore o uso de loopback. Firewall em 127.0.0.1 é impraticável, mas garanta que apenas tráfego localhost seja usado para manipulações de TC.
Avisos dos Fornecedores: Consulte os avisos oficiais do seu sistema operacional. Red Hat tem RHSA-2026:27354 (e relacionados) para RHEL 8/9/10, Debian tem DSA-6355-1, a página CVE do Ubuntu lista kernels corrigidos, etc. (Consulte Referências.)
A remediação a longo prazo envolve garantir que todos os sistemas afetados estejam com kernels atualizados. Pacotes de kernel que contenham a correção devem ser instalados e os sistemas reinicializados. Para contêineres ou sistemas que não podem reiniciar, considere soluções de livepatch (ex.: KernelCare) que prepararam patches.
Além disso, o design do sistema deve assumir que interfaces do kernel acessíveis do espaço de usuário podem mudar ao longo do tempo. Restringir CAP_NET_ADMIN e filtrar o uso de tc são boas práticas além deste bug.
Se um comprometimento ocorreu, reconstrua o sistema. A vulnerabilidade envenena apenas o cache de páginas, mas um atacante com root pode ter realizado outras ações maliciosas; é necessária validação forense. Não confie em varreduras de integridade de arquivos após o exploit, pois conforme observado, a PoC deixa os arquivos em disco intactos. Reinicializar e aplicar patch é o caminho seguro de remediação.
Considerando esses fatores, um vetor CVSS v3.1 típico é AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H, resultando em uma Pontuação Base de 6,0 (Média). Note, no entanto, que o CVSS não captura que essa vulnerabilidade concede escalonamento de privilégio para root, o que na prática é crítico. (Algumas fontes calcularam CVSSv4 para bugs semelhantes; ex.: PT DBugs lista 8,5 no CVSSv4.)
A gravidade é frequentemente classificada como Importante/Crítica pelos fornecedores. O aviso da Red Hat para esta CVE a classifica como Importante, e a AWS marca como Médio (CVSS 6,0). De qualquer forma, como o root é obtido, o risco prático é maior em sistemas multiusuário ou compartilhados.
Esta vulnerabilidade pertence a uma família de bugs de envenenamento do cache de páginas. Outras CVEs notáveis incluem:
splice() em um pipe poderia escrever no cache de páginas além dos limites COW. Também permitia sobrescrever arquivos na memória (sem alteração no disco)./proc/self/mem copy-on-write que permitia escrita local em mapeamentos somente leitura.Cada um desses envolve um caminho rápido do kernel escrevendo em memória que acreditava possuir exclusivamente, mas não possuía. CVE-2026-46331 é único por ocorrer na ação net/sched pedit e por alavancar namespaces de usuário para contornar restrições de privilégio. Ao contrário de DirtyPipe ou Dirty COW, nenhum processo privilegiado auxiliar (como um sistema malcomportado) é necessário – um único usuário não privilegiado pode acioná-lo.
Todas as referências são de fontes respeitáveis (avisos de fornecedores, análises publicadas, entradas CVE/NVD).
act_pedit, calcular a possibilidade de escrita cedo demais possibilitou a corrupção do cache de páginas.tc ou netlink, o atacante cria um qdisc e filtro em lo que corresponde a todos os pacotes (ex.: match u32 0 0) e anexa uma ação pedit com chaves especialmente criadas. Cada chave tem um tipo de cabeçalho dinâmico (ex.: cabeçalho IP para um deslocamento L4) e um deslocamento escolhido de modo que a posição real de gravação (início do cabeçalho + deslocamento) fique logo além do intervalo coberto por skb_ensure_writable().echo '' > /dev/udp/127.0.0.1/53) para acionar o filtro. O kernel chama tcf_pedit_act(), aloca um intervalo COW, então itera sobre as chaves. Pelo menos um write de chave cai fora da região pré-COP, fazendo com que a gravação vá para o cache de página compartilhado./bin/su no socket via sendfile ou similar, de modo que o buffer do pacote referencie as páginas desse arquivo. O write fora dos limites então corrompe a cópia em memória de /bin/su (especificamente o ponto de entrada ELF)./bin/su). Como o kernel injetou inadvertidamente shellcode que faz setgid(0); setuid(0); execve("/bin/sh"), executar su concede um shell root. O arquivo no disco nunca foi alterado, portanto nenhuma ferramenta de integridade de arquivo em disco mostrará uma mudança.auditd) mostrando programas obtendo CAP_NET_ADMIN via userns ou escrevendo em /proc/[pid]/uid_map.