No kernel Linux, a seguinte vulnerabilidade foi resolvida. mm/slab: evitar a recursão livre no caminho livre com o novo tipo de kmalloc Commit 280 x 9 c 3154 b ("mm/slab: evite alocar slabobj_ext array de sua própria laje") evitou alocar recursivamente obj_exts de caches kmalloc do mesmo tamanho, batendo o tamanho de alocação do array obj_exts sempre que o tamanho do array for igual ao tamanho do objeto alocado. No entanto, conforme relatado por Danielle Costantino e Shakeel Butt, até mesmo as placas de caches kmalloc de diferentes tamanhos podem formar um ciclo ao atribuir arrays obj_exts de um ao outro [ 1 ]:.
O que aconteceu: um array obj_ exts da laje KMALLOC_NORMAL (usado pelo perfil de atribuição / contabilidade memcg) é em si mesmo kmalloc()'d de um cache KMALLOC_ NORMAL, assim que a "laje mantém a relação obj_ exts de outra laje" pode formar ciclos. Com tamanho de (struct slabobj_ext) == 16 e a geometria do hospedeiro: - kmalloc- 512 tem 64 objetos/slab -> array é 64 * 16 == 1024 bytes, servido a partir do kmalloc- 1 k; - kmalloc- 1 k tem 32 objetos/slab -> array é 32 * 16 == 512 bytes, servido a partir do kmalloc- 512. Um kmalloc- 512 laje e um kmalloc- 1 k slab, portanto, segurar o array obj_ exts um do outro. Descartar um liberta o array do outro, que esvazia e descarta o slab, que liberta o array do primeiro, e assim por diante: __free_slab() -> free_slab_obj_exts() -> kfree() -> recursões ao longo do ciclo até que a pilha esteja esgotada.
Com o perfil de alocação de memória, isso permite uma recursão não delimitada no caminho livre e levou a um sobrecarga de pilha em um hospedeiro de produção na frota Meta [ 1 ]: BUG: TASK foi acertado o prêmio de guarda de pilha Oops: prêmio de guarda de pilha RIP: 0010:kfree+ 0 x 8 / 0 x 5 d 0 Chamada de rastreamento: __free_slab+ 0 x 66 / 0 xc 0 kfree+ 0 x 3 f 0 / 0 x 5 d 0... ( ~ 125 x __free_slab kfree )... do_syscall_ 64.
É proposto [ 1 ] para resolver este problema sempre servindo a alocação de array obj_ exts a partir de caches kmalloc (ou kmalloc grande) de tamanhos maiores do que o tamanho do objeto. No entanto, como apontado por Vlastimil Babka [ 2 ], isto pode desperdiçar uma quantidade excessiva de memória como placas de tamanhos grandes de kmalloc (por exemplo kmalloc- 8 k) geralmente necessita de arrays obj_ exts muito menores do que o tamanho do objeto. Portanto, em vez de bater o tamanho, vamos tomar uma abordagem diferente; desallow formação de ciclos entre tipos de kmalloc ao alocar arrays obj_ exts. Atualmente, todos os arrays obj_ exts são servidos a partir de caches de kmalloc normais. Os ciclos não podem ser criados se os arrays obj_ exts de caches de kmalloc normais forem servidos a partir de um tipo especial de kmalloc que nunca poderá ter arrays obj_ exts.
Para isso, crie um novo tipo de kmalloc chamado KMALLOC_NO_OBJ_EXT. As caches do KMALLOC_NO_OBJ_EXT são criadas com a bandeira SLAB_NO_OBJ_EXT quando um ou outro 1 ) o perfil de alocação de memória não está permanentemente desativado, ou 2 ) os tipos de kmalloc com uma prioridade maior que o KMALLOC_CGROUP são alias com o KMALLOC_ NORMAL. O bootstrapping de caches para o KMALLOC_NO_OBJ_EXT agora deve ser adiado, pois a alocação de um celeiro pode ativar a alocação de arrays obj_exts de caches de kmalloc normais quando o cache do KMALLOC_NO_OBJ_EXT para esse tamanho ainda não estiver pronto. Para simplicidade, execute o arranque de gavetas para todos os caches do kmalloc mais tarde.
Introduza uma nova bandeira de alloc de lajes, SLAB_ALLOC_NO_OBJ_EXT, para evitar a alocação de arrays obj_exts, e deixe o kmalloc_slab() sobrepor o tipo para o KMALLOC_NO_OBJ_EXT quando especificado. Note que kmalloc_ type() permanece inalterado porque kmalloc_flags() evita o caminho rápido do kmalloc. Não passe SLAB_ALLOC_NO_RECURSE para kmalloc_flags() em alloc_slab_obj_exts() e use SLAB_ALLOC_NO_OBJ_EXT apenas quando os objetos são alocados a partir de caches de kmalloc normais. Embora isso impeça a alocação recursiva não delimitada de obj_exts, ele permite que as caches do KMALLOC_NO_OBJ_EXT tenham bainhas.
Como as alocações de maçanetas especificam SLAB_ ALLOC_NO_RECURSE que impede a alocação de ambos os arrays de maçanetas e obj_exts, a profundidade de recursão é limitada. obj_ exts arrays para não- --- truncado--. Registro de aconselhamento: GHSA-cwq 6 - wj 3 w- xw 2 f. Identificadores relacionados: CVE- 2026 - 74576.
Tempo: GitHub Advisory Database publicou este registro em 2026 - 08 - 15 T 15: 30: 36.000 Z e lista a sua última modificação como 2026 - 08 - 17 T 06: 33: 54.000 Z. Severidade: ALTAMENTE. Dados de pontuação publicados: CVSS_V 3: CVSS: 3.1 /AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
Software afetado: o registro de aconselhamento não fornece um pacote normalizado ou faixa de versões. Classificação e evidência: nenhum identificador CWE está listado. O registro contém 5 suporte de referências nestes tipos: AVISO, WEB.