⚠️ Aviso Legal

Este repositório destina-se a pesquisa de segurança autorizada, análise de vulnerabilidades, ambientes de CTF, depuração de kernel e testes defensivos.

Não utilize código de prova de conceito contra sistemas sem autorização explícita.

📌 Visão Geral da Vulnerabilidade

O aviso do CVE descreve o problema como um underflow de inteiro que pode fazer com que skb->data seja posicionado fora do head do skb alocado.

🧬 Descrição da Vulnerabilidade

A vulnerabilidade existe no caminho de recepção TUN/TAP do kernel Linux.

O código afetado usa o headroom de recepção configurado do dispositivo TUN tanto como headroom do pacote quanto no cálculo de quanto dado do pacote deve permanecer linear.

Um valor de headroom superdimensionado pode, portanto, criar um cálculo inválido em:

SKB_MAX_HEAD(align)

Quando o valor fornecido excede o head do skb utilizável de uma página, o cálculo pode sofrer underflow.

Conceitualmente:

Headroom de recepção superdimensionado
          │
          ▼
     SKB_MAX_HEAD()
          │
          ▼
     Underflow de inteiro
          │
          ▼
    Valor negativo
          │
          ▼
      wrap de size_t
          │
          ▼
Posicionamento inválido de skb data
          │
          ▼
Corrupção de memória do kernel

A implementação vulnerável está localizada em:

drivers/net/tun.c

sendo tun_get_user() central para o caminho vulnerável.

🔬 Causa Raiz

O problema subjacente é o headroom de recepção do TUN insuficientemente limitado.

O kernel pode receber uma solicitação de headroom superdimensionada através de caminhos de dispositivos de rede que propagam o valor para o TUN/TAP.

A vulnerabilidade torna-se particularmente interessante quando uma configuração complexa de rede virtual faz com que um valor grande de headroom alcance um dispositivo TUN.

A divulgação pública descreve um cenário envolvendo:

Netkit
   │
   ▼
VXLAN
   │
   ▼
Open vSwitch
   │
   ▼
TUN

Uma configuração de exemplo pode propagar aproximadamente 4160 bytes de headroom para uma porta TUN raw, causando o underflow na aritmética vulnerável.

💥 Impacto de Segurança

A corrupção ocorre na lógica de gerenciamento de memória de rede do kernel.

As consequências potenciais incluem:

• Corrupção de memória do kernel
• Crash do kernel
• Negação de serviço
• Corrupção de estruturas do kernel
• Potencial execução de código no kernel
• Escalação de privilégios local

A divulgação pública relata a vulnerabilidade como parte de um grupo de vulnerabilidades de root local do Linux e afirma que o PoC publicado pode alcançar execução de usuário local sem privilégios para root em alvos compatíveis.

A explorabilidade depende do ambiente e requer a configuração relevante de dispositivo TUN/rede e funcionalidade de suporte.

🧠 Fluxo Técnico

             ATACANTE
                 │
                 ▼
       Headroom de rede superdimensionado
                 │
                 ▼
        Dispositivo de rede virtual
                 │
                 ▼
             Open vSwitch
                 │
                 ▼
              TUN/TAP
                 │
                 ▼
          tun_get_user()
                 │
                 ▼
       SKB_MAX_HEAD(align)
                 │
                 ▼
          Underflow de inteiro
                 │
                 ▼
          wraparound de size_t
                 │
                 ▼
       Offset inválido de skb->data
                 │
                 ▼
       Corrupção de memória do kernel

🔎 Caminho de Código Vulnerável

Os componentes importantes são:

drivers/net/tun.c
        │
        ├── tun_set_headroom()
        │
        ├── tun_get_user()
        │
        └── tun_alloc_skb()

A relação vulnerável pode ser simplificada como:

tun->align
    │
    ├── headroom do skb
    │
    └── cálculo de dados lineares

Usar o mesmo valor superdimensionado em ambos os cálculos cria uma relação insegura entre o headroom solicitado e o orçamento real do head do skb.

🧮 Underflow de Inteiro

A propriedade crítica de segurança pode ser representada conceitualmente como:

usable_head < requested_headroom

o que pode resultar em:

SKB_MAX_HEAD(align) < 0

seguido por uma conversão sem sinal:

valor negativo
      ↓
size_t
      ↓
valor sem sinal muito grande

Isso pode, em última análise, influenciar a alocação/posicionamento de dados do skb.

A descrição oficial observa especificamente que o valor resultante sofre wrap quando atribuído à variável size_t linear.

🩹 Correção Upstream

A correção upstream é:

447c9303942c439a117d9b76ce6d6e2116c38ee7

Commit:

net: tun: bound receive headroom

A correção limita o headroom armazenado pelo TUN em relação ao orçamento disponível do head do skb de uma página e ao maior offset válido de cabeçalho skb de 16 bits. Também garante que dados lineares suficientes estejam disponíveis para o processamento de TUN raw e TAP.

🛡️ Conceito da Correção

Antes

Usuário / dispositivo de rede
        │
        ▼
Headroom grande
        │
        ▼
tun->align
        │
        ▼
Aritmética insegura
        │
        ▼
Potencial acesso OOB

Depois

Usuário / dispositivo de rede
        │
        ▼
Headroom grande
        │
        ▼
Headroom limitado
        │
        ▼
Cálculo seguro de skb
        │
        ▼
Processamento normal de pacotes

📊 Vulnerável vs Corrigido

🧪 Ambiente de Pesquisa

Topologia de laboratório recomendada:

┌─────────────────────────────────────────┐
│             Linux VM / Host             │
│                                         │
│   ┌─────────┐     ┌──────────────┐     │
│   │ Netkit  │────▶│    VXLAN     │     │
│   └─────────┘     └──────┬───────┘     │
│                          │             │
│                   ┌──────▼───────┐     │
│                   │ Open vSwitch │     │
│                   └──────┬───────┘     │
│                          │             │
│                   ┌──────▼───────┐     │
│                   │    TUN/TAP   │     │
│                   └──────────────┘     │
│                                         │
└─────────────────────────────────────────┘

Ferramentas úteis:

uname -a
ip link
ip tuntap
bridge link
ovs-vsctl show
dmesg -w

Para depuração de kernel:

GDB
GDB + GEF
GDB + pwndbg
crash
objdump
readelf
pahole

🔎 Verificação do Kernel

Verifique o kernel em execução:

uname -r

Verifique a configuração do kernel:

grep CONFIG_TUN /boot/config-$(uname -r)

Configuração esperada:

CONFIG_TUN=y

ou:

CONFIG_TUN=m

Verifique se o módulo está carregado:

lsmod | grep tun

🧪 Pesquisa de PoC

A divulgação pública fornece um repositório PoC dedicado ao TUNderflow para validação controlada.

Para um fluxo de pesquisa seguro:

1. Compilar kernel vulnerável
2. Inicializar VM isolada
3. Configurar TUN/TAP
4. Reproduzir headroom superdimensionado
5. Monitorar mensagens do kernel
6. Capturar comportamento de crash/corrupção
7. Aplicar patch upstream
8. Repetir teste
9. Comparar resultados

Monitore o kernel:

sudo dmesg -w

O objetivo do laboratório é demonstrar a diferença entre o comportamento vulnerável e o corrigido, em vez de atacar sistemas de produção.

📂 Estrutura do Repositório

CVE-2026-81000-TUNderflow/
│
├── README.md
│
├── exploit/
│   ├── poc.c
│   └── Makefile
│
├── analysis/
│   ├── root-cause.md
│   ├── kernel-path.md
│   ├── integer-underflow.md
│   └── patch-analysis.md
│
├── kernel/
│   ├── vulnerable/
│   └── patched/
│
├── lab/
│   ├── setup.sh
│   ├── cleanup.sh
│   └── topology.md
│
├── screenshots/
│
├── docs/
│   └── research-notes.md
│
└── LICENSE

🔐 Mitigação

A mitigação recomendada é instalar um kernel que contenha a correção de segurança upstream ou um backport apropriado da distribuição.

Para Debian/Kali:

sudo apt update
sudo apt full-upgrade

Em seguida, reinicie:

sudo reboot

Verifique:

uname -r

Para ambientes de produção, verifique o kernel da distribuição instalada em relação ao aviso de segurança do fornecedor, em vez de confiar apenas no número da versão upstream.

A Oracle Linux, por exemplo, publicou atualizações de segurança contendo a correção net: tun: bound receive headroom.

📦 Correções em Kernels Estáveis

A divulgação pública identifica as seguintes versões de kernel estáveis como as primeiras versões contendo as correções para as quatro vulnerabilidades de root local divulgadas, incluindo o TUNderflow:

🧩 Lições de Segurança

O TUNderflow demonstra vários princípios importantes de segurança de kernel:

01 — Limite valores influenciados externamente

Valores de configuração de rede nunca devem ser confiados cegamente.

02 — Valide a aritmética antes da alocação

O underflow de inteiro pode transformar um cálculo aparentemente inofensivo em uma primitiva de segurança de memória.

03 — Separe metadados de suposições de memória

Um valor de headroom de dispositivo de rede deve permanecer consistente com o orçamento real de memória do skb.

04 — Stacks de rede complexas aumentam a superfície de ataque

Camadas de rede virtual podem propagar metadados de pacotes inesperados através de múltiplos subsistemas.

05 — A análise de patches importa

Estudar a correção upstream frequentemente fornece uma compreensão mais clara da vulnerabilidade original do que olhar apenas para o crash.

📚 Referências

• CVE: CVE-2026-81000
• Componente: Linux Kernel TUN/TAP
• Arquivo afetado: drivers/net/tun.c
• Função principal: tun_get_user()
• Correção upstream: 447c9303942c439a117d9b76ce6d6e2116c38ee7
• Correção: net: tun: bound receive headroom
• Divulgação: Aviso de segurança do kernel Linux / oss-security

👤 Pesquisa