linux-4.1.15_CVE-2023-4128

INSTALANDO o código-fonte do kernel:

• Se você instalar os fontes completos, coloque o tarball do kernel em um diretório onde você tenha permissões (por exemplo, seu diretório home) e descompacte-o:

  xz -cd linux-4.X.tar.xz | tar xvf -

  Substitua "X" pelo número da versão do kernel mais recente.

  NÃO use a área /usr/src/linux! Esta área tem um conjunto (geralmente incompleto) de cabeçalhos do kernel que são usados pelos arquivos de cabeçalho da biblioteca. Eles devem corresponder à biblioteca e não devem ser bagunçados por qualquer que seja o kernel-do-dia.

• Você também pode atualizar entre versões 4.x aplicando patches. Os patches são distribuídos no formato xz. Para instalar por aplicação de patch, obtenha todos os arquivos de patch mais recentes, entre no diretório de nível superior do código-fonte do kernel (linux-4.X) e execute:

  xz -cd ../patch-4.x.xz | patch -p1

  Substitua "x" por todas as versões maiores que a versão "X" da sua árvore de fontes atual, em ordem, e você estará bem. Você pode querer remover os arquivos de backup (some-file-name~ ou some-file-name.orig) e garantir que não haja patches com falha (some-file-name# ou some-file-name.rej). Se houver, ou você ou eu cometemos um erro.

  Diferente dos patches para os kernels 4.x, os patches para os kernels 4.x.y (também conhecidos como kernels -stable) não são incrementais, mas sim aplicam-se diretamente ao kernel base 4.x. Por exemplo, se o seu kernel base é 4.0 e você deseja aplicar o patch 4.0.3, você não deve aplicar primeiro os patches 4.0.1 e 4.0.2. Da mesma forma, se você estiver executando a versão 4.0.2 do kernel e quiser pular para 4.0.3, você deve primeiro reverter o patch 4.0.2 (isto é, patch -R) antes de aplicar o patch 4.0.3. Você pode ler mais sobre isso em Documentation/applying-patches.txt

  Alternativamente, o script patch-kernel pode ser usado para automatizar esse processo. Ele determina a versão atual do kernel e aplica quaisquer patches encontrados.

  linux/scripts/patch-kernel linux

  O primeiro argumento no comando acima é a localização do código-fonte do kernel. Os patches são aplicados a partir do diretório atual, mas um diretório alternativo pode ser especificado como segundo argumento.

• Certifique-se de que não há arquivos .o obsoletos e dependências por aí:

  cd linux make mrproper

  Agora você deve ter os fontes instalados corretamente.

REQUISITOS DE SOFTWARE

Compilar e executar os kernels 4.x requer versões atualizadas de vários pacotes de software. Consulte Documentation/Changes para os números de versão mínimos exigidos e como obter atualizações para esses pacotes. Cuidado: usar versões excessivamente antigas desses pacotes pode causar erros indiretos muito difíceis de rastrear, portanto, não presuma que você pode simplesmente atualizar pacotes quando problemas óbvios surgirem durante a compilação ou operação.

DIRETÓRIO DE BUILD para o kernel:

Ao compilar o kernel, todos os arquivos de saída serão armazenados por padrão junto com o código-fonte do kernel. Usar a opção "make O=output/dir" permite especificar um local alternativo para os arquivos de saída (incluindo .config). Exemplo:

Para configurar e compilar o kernel, use:

Por favor, note: Se a opção 'O=output/dir' for usada, ela deve ser usada em todas as invocações do make.

CONFIGURANDO o kernel:

Não pule esta etapa mesmo que você esteja apenas atualizando uma versão menor. Novas opções de configuração são adicionadas em cada lançamento, e problemas estranhos surgirão se os arquivos de configuração não estiverem configurados como esperado. Se você quiser carregar sua configuração existente para uma nova versão com o mínimo de trabalho, use "make oldconfig", que só perguntará as respostas para novas perguntas.

• Comandos de configuração alternativos são:

  "make config" Interface de texto simples.

  "make menuconfig" Menus coloridos baseados em texto, radiolistas e diálogos.

  "make nconfig" Menus coloridos baseados em texto aprimorados.

  "make xconfig" Ferramenta de configuração baseada em X windows (Qt).

  "make gconfig" Ferramenta de configuração baseada em X windows (Gtk).

  "make oldconfig" Define como padrão todas as perguntas com base no conteúdo do seu arquivo ./.config existente e pergunta sobre novos símbolos de configuração.

  "make silentoldconfig" Como acima, mas evita poluir a tela com perguntas já respondidas. Além disso, atualiza as dependências.

  "make olddefconfig" Como acima, mas define novos símbolos com seus valores padrão sem solicitação.

  "make defconfig" Cria um arquivo ./.config usando os valores de símbolo padrão de arch/$ARCH/defconfig ou arch/$ARCH/configs/${PLATFORM}_defconfig, dependendo da arquitetura.

  "make ${PLATFORM}_defconfig" Cria um arquivo ./.config usando os valores de símbolo padrão de arch/$ARCH/configs/${PLATFORM}_defconfig. Use "make help" para obter uma lista de todas as plataformas disponíveis da sua arquitetura.

  "make allyesconfig" Cria um arquivo ./.config definindo valores de símbolo como 'y' o máximo possível.

  "make allmodconfig" Cria um arquivo ./.config definindo valores de símbolo como 'm' o máximo possível.

  "make allnoconfig" Cria um arquivo ./.config definindo valores de símbolo como 'n' o máximo possível.

  "make randconfig" Cria um arquivo ./.config definindo valores de símbolo como valores aleatórios.

  "make localmodconfig" Cria uma configuração baseada na configuração atual e nos módulos carregados (lsmod). Desativa qualquer opção de módulo que não seja necessária para os módulos carregados.

  root@kitploit:~

                      Para criar um localmodconfig para outra máquina,
                      armazene o lsmod dessa máquina em um arquivo
                      e passe-o como parâmetro LSMOD.
  
              target$ lsmod > /tmp/mylsmod
              target$ scp /tmp/mylsmod host:/tmp
  
              host$ make LSMOD=/tmp/mylsmod localmodconfig
  
                      O acima também funciona ao fazer compilação cruzada.
  

  "make localyesconfig" Similar ao localmodconfig, exceto que converterá todas as opções de módulo em opções embutidas (=y).

  Você pode encontrar mais informações sobre como usar as ferramentas de configuração do kernel Linux em Documentation/kbuild/kconfig.txt.

• NOTAS sobre "make config":

  • Ter drivers desnecessários tornará o kernel maior e pode, em algumas circunstâncias, levar a problemas: a sondagem de uma placa controladora inexistente pode confundir seus outros controladores.

  • Compilar o kernel com "Tipo de processador" definido como superior a 386 resultará em um kernel que NÃO funciona em um 386. O kernel detectará isso na inicialização e desistirá.

  • Um kernel com emulação matemática compilada ainda usará o coprocessador se um estiver presente: a emulação matemática simplesmente nunca será usada nesse caso. O kernel será ligeiramente maior, mas funcionará em máquinas diferentes, independentemente de terem um coprocessador matemático ou não.

  • Os detalhes de configuração de "kernel hacking" geralmente resultam em um kernel maior ou mais lento (ou ambos), e podem até tornar o kernel menos estável ao configurar algumas rotinas para tentar ativamente quebrar código ruim para encontrar problemas no kernel (kmalloc()). Portanto, você provavelmente deve responder 'n' às perguntas para recursos de "desenvolvimento", "experimental" ou "depuração".

COMPILANDO o kernel:

• Certifique-se de ter pelo menos gcc 3.2 disponível. Para mais informações, consulte Documentation/Changes.

  Por favor, note que você ainda pode executar programas de usuário a.out com este kernel.

• Execute "make" para criar uma imagem de kernel compactada. Também é possível executar "make install" se você tiver o lilo instalado para adequar os makefiles do kernel, mas você pode querer verificar sua configuração específica do lilo primeiro.

  Para fazer a instalação real, você precisa ser root, mas nenhuma das etapas normais de construção deve exigir isso. Não tome o nome de root em vão.

• Se você configurou alguma das partes do kernel como `modules', você também terá que executar "make modules_install".

• Saída detalhada de compilação/build do kernel:

  Normalmente, o sistema de build do kernel opera em um modo bastante silencioso (mas não totalmente silencioso). No entanto, às vezes você ou outros desenvolvedores do kernel precisam ver comandos de compilação, linkagem ou outros exatamente como são executados. Para isso, use o modo de build "verbose". Isso é feito inserindo "V=1" no comando "make". Ex.:

  make V=1 all

  Para que o sistema de build também informe o motivo da reconstrução de cada destino, use "V=2". O padrão é "V=0".

• Mantenha um kernel de backup à mão caso algo dê errado. Isso é especialmente verdadeiro para lançamentos de desenvolvimento, já que cada novo lançamento contém código novo que não foi depurado. Certifique-se de manter também um backup dos módulos correspondentes a esse kernel. Se você estiver instalando um novo kernel com o mesmo número de versão do seu kernel funcional, faça um backup do diretório de módulos antes de executar "make modules_install".

  Alternativamente, antes de compilar, use a opção de configuração do kernel "LOCALVERSION" para anexar um sufixo único à versão regular do kernel. LOCALVERSION pode ser definido no menu "Configuração Geral".

• Para inicializar seu novo kernel, você precisará copiar a imagem do kernel (por exemplo, .../linux/arch/i386/boot/bzImage após a compilação) para o local onde seu kernel inicializável regular é encontrado.

• Inicializar um kernel diretamente de um disquete sem a assistência de um carregador de inicialização como o LILO não é mais suportado.

  Se você inicializa o Linux a partir do disco rígido, provavelmente usa o LILO, que usa a imagem do kernel conforme especificado no arquivo /etc/lilo.conf. O arquivo de imagem do kernel geralmente é /vmlinuz, /boot/vmlinuz, /bzImage ou /boot/bzImage. Para usar o novo kernel, salve uma cópia da imagem antiga e copie a nova imagem sobre a antiga. Então, você DEVE REEXECUTAR O LILO para atualizar o mapa de carregamento!! Se não fizer isso, você não conseguirá inicializar a nova imagem do kernel.

  Reinstalar o LILO geralmente é uma questão de executar /sbin/lilo. Você pode querer editar /etc/lilo.conf para especificar uma entrada para sua imagem de kernel antiga (por exemplo, /vmlinux.old) caso a nova não funcione. Veja a documentação do LILO para mais informações.

  Após reinstalar o LILO, tudo deve estar configurado. Desligue o sistema, reinicie e aproveite!

  Se você precisar alterar o dispositivo raiz padrão, modo de vídeo, tamanho do ramdisk, etc. na imagem do kernel, use o programa 'rdev' (ou alternativamente as opções de inicialização do LILO quando apropriado). Não há necessidade de recompilar o kernel para alterar esses parâmetros.

• Reinicie com o novo kernel e aproveite.

SE ALGO DER ERRADO:

• Se você tiver problemas que parecem ser devidos a bugs do kernel, por favor, verifique o arquivo MAINTAINERS para ver se há uma pessoa específica associada à parte do kernel com a qual você está tendo problemas. Se não houver ninguém listado lá, a segunda melhor opção é enviar um e-mail para mim ([email protected]), e possivelmente para qualquer outra lista de discussão relevante ou para o grupo de notícias.

• Em todos os relatórios de bug, por favor informe qual kernel você está usando, como duplicar o problema e qual é a sua configuração (use seu bom senso). Se o problema é novo, me diga, e se o problema é antigo, por favor tente me dizer quando você o notou pela primeira vez.

• Se o bug resultar em uma mensagem como

  unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx

  ou informações de depuração do kernel semelhantes na sua tela ou no seu log do sistema, por favor, duplique exatamente. O dump pode parecer incompreensível para você, mas contém informações que podem ajudar a depurar o problema. O texto acima do dump também é importante: informa algo sobre por que o kernel despejou código (no exemplo acima, é devido a um ponteiro de kernel inválido). Mais informações sobre como interpretar o dump estão em Documentation/oops-tracing.txt

• Se você compilou o kernel com CONFIG_KALLSYMS, pode enviar o dump como está; caso contrário, você terá que usar o programa "ksymoops" para interpretar o dump (mas compilar com CONFIG_KALLSYMS geralmente é preferível). Este utilitário pode ser baixado de ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ . Alternativamente, você pode fazer a consulta do dump manualmente:

• Ao depurar dumps como o acima, ajuda enormemente se você puder consultar o que o valor EIP significa. O valor hexadecimal como tal não ajuda muito a mim ou a ninguém: dependerá da sua configuração específica do kernel. O que você deve fazer é pegar o valor hexadecimal da linha EIP (ignore o "0010:"), e consultá-lo na lista de nomes do kernel para ver qual função do kernel contém o endereço ofensivo.

  Para descobrir o nome da função do kernel, você precisará encontrar o binário do sistema associado ao kernel que exibiu o sintoma. Este é o arquivo 'linux/vmlinux'. Para extrair a lista de nomes e compará-la com o EIP da falha do kernel, faça:

  nm vmlinux | sort | less

  Isso lhe dará uma lista de endereços do kernel classificados em ordem crescente, a partir da qual é simples encontrar a função que contém o endereço ofensivo. Note que o endereço fornecido pelas mensagens de depuração do kernel não corresponderá necessariamente exatamente aos endereços das funções (na verdade, isso é muito improvável), então você não pode apenas usar 'grep' na lista: a lista, no entanto, fornecerá o ponto de partida de cada função do kernel, então, procurando pela função que tem um endereço inicial menor que o que você está procurando, mas é seguida por uma função com um endereço maior, você encontrará a que deseja. Na verdade, pode ser uma boa ideia incluir um pouco de "contexto" no seu relatório de problema, fornecendo algumas linhas ao redor da linha interessante.

  Se por algum motivo você não puder fazer o acima (você tem uma imagem de kernel pré-compilada ou similar), me informar o máximo possível sobre sua configuração ajudará. Por favor, leia o documento REPORTING-BUGS para detalhes.

• Alternativamente, você pode usar o gdb em um kernel em execução. (somente leitura; ou seja, você não pode alterar valores ou definir pontos de interrupção.) Para fazer isso, primeiro compile o kernel com -g; edite arch/i386/Makefile apropriadamente, então execute "make clean". Você também precisará habilitar CONFIG_PROC_FS (via "make config").

  Após reinicializar com o novo kernel, faça "gdb vmlinux /proc/kcore". Agora você pode usar todos os comandos usuais do gdb. O comando para consultar o ponto onde seu sistema travou é "l *0xXXXXXXXX". (Substitua os XXX pelo valor EIP.)

  Atualmente, usar gdb em um kernel que não está em execução falha porque o gdb (erroneamente) desconsidera o deslocamento inicial para o qual o kernel é compilado.