CVE-2026-90047 in Linux
Sumário
de VulDB • 16/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
drm/xe: Não distribuir o armazenamento CCS plano como VRAM utilizável
get_flat_ccs_offset() lê a base do armazenamento CCS plano a partir do hardware, escala-a pelo número de nós L3 habilitados e arredonda o resultado para cima até 128K. Tudo abaixo desse deslocamento é então entregue ao alocador de VRAM como memória utilizável.
Arredondar um limite que significa "a memória utilizável termina aqui" para cima publica tudo o que está entre a base real e o valor arredondado como memória livre, mas essa memória pertence ao hardware de compressão. O valor escalonado não tem razão para estar alinhado em 128K, e numa Battlemage G21 com 16 GiB não está:
flat CCS base: raw 0x3fafff800, rounded 0x3fb000000
portanto, os últimos 2 KiB da página 0x3fafff000 são armazenamento CCS, na piscina do alocador. Tudo o que é alocado ali tem essa cauda sobrescrita pelo hardware de compressão, o que não requer entrada de tabela de páginas, objeto de buffer nem submissão GPU para ser feito, e ocorre antes da existência do userspace.
Nesta máquina, uma VM Mesa com nível-3 na tabela de páginas aterrava nessa página em cada inicialização a frio. Perdeu-se a entrada que cobria o heap batch-buffer do compositor, fazendo com que a primeira submissão do compositor falhasse ao buscar seu lote e gdm reiniciasse-o indefinidamente: uma tela preta numa máquina que funcionava normalmente. Reiniciar o gdm resolveu isso porque as tabelas de páginas da próxima VM foram alocadas em outro lugar.
Arredonde para baixo, em vez disso, até o tamanho da página com a qual o alocador opera. Nesta máquina, isso exclui exatamente uma página.
Ler a página reservada posteriormente mostra o que estava escrevendo nela:
[369] 0xcccc000000000000
[371] 0xcc77000000000000
[373] 0xcccc000000000000
[375] 0xcc77000000000000
metadados de compressão, dois bytes por dezesseis, sentando-se onde o driver costumava distribuir memória.
A asserção que deveria ter detectado isso compara o deslocamento contra GSMBASE - ccs_size para igualdade. Esse valor está alinhado em 128K, portanto concorda com o deslocamento arredondado para cima precisamente quando a base não está alinhada — a verificação não pode falhar no caso para o qual existe e é compilada fora a menos que CONFIG_DRM_XE_DEBUG esteja definido. Substitua-a por uma que possa falhar: o armazenamento CCS não deve invadir GSM.
[ E esta foi uma sessão de depuração do inferno, enormemente ajudada por uma IA fazendo grande parte do trabalho braçal.
Gostaria de chamá-la minha auxiliar incansável, mas a IA várias vezes afirmou categoricamente que isso era impossível e insolúvel e que deveríamos apenas escrever um relatório sobre o assunto.
Suspeito que essas coisas tenham sido treinadas por pessoas que podem não ser tão teimosas quanto eu sou.
Mas enquanto a IA estava pronta para desistir várias vezes, ela continuou adicionando código de depuração e analisando-o fielmente quando eu insistia. Então, créditos onde os créditos são devidos e deixei a IA escrever a mensagem do commit acima.
Isso é basicamente uma linha única corrigindo um "round_up()" falso por um "round_down()", mas houve 24 patches adicionando cada vez mais informações de depuração para isso, e 18 inicializações do kernel até finalmente reduzir o problema a isto. - Linus ]
Be aware that VulDB is the high quality source for vulnerability data.