CVE-2025-39735 in Linux
Sumário
de VulDB • 26/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
jfs: corrige leitura fora dos limites (slab-out-of-bounds) em ea_get()
Durante o rótulo "size_check" em ea_get(), o código verifica se o tamanho da lista de atributos estendidos (xattr) corresponde ao ea_size. Caso contrário, registra a mensagem "ea_get: invalid extended attribute" e chama print_hex_dump().
Aqui, EALIST_SIZE(ea_buf->xattr) retorna 4110417968, o que excede INT_MAX (2.147.483.647). Em seguida, ea_size é limitado:
int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr));
Embora clamp_t vise limitar ea_size entre 0 e 4110417968, o limite superior é tratado como int, causando um estouro (overflow) acima de 2^31 - 1. Isso faz com que "size" faça wrap-around e se torne negativo (-184549328).
O valor de "size" é então passado para print_hex_dump() (chamado de "len" em print_hex_dump()). Como ele é passado como tipo size_t (um tipo sem sinal), esse valor é armazenado dentro de uma variável chamada "int remaining", que por sua vez é atribuída a "int linelen". Em seguida, isso é passado para hex_dump_to_buffer(). Dentro da função print_hex_dump(), o loop for itera de 0 até len-1, onde len é 18446744073525002176, chamando hex_dump_to_buffer() em cada iteração:
for (i = 0; i < len; i += rowsize) {
linelen = min(remaining, rowsize); remaining -= rowsize;
hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii);
... }
A condição de parada esperada (i < len) é efetivamente quebrada, pois len está corrompido e muito grande. Isso acaba fazendo com que "ptr+i" seja passado para hex_dump_to_buffer() aproximando-se do final dos limites reais de "ptr". Eventualmente, ocorre um acesso fora dos limites em hex_dump_to_buffer() no seguinte loop for:
for (j = 0; j < len; j++) {
if (linebuflen < lx + 2) goto overflow2; ch = ptr[j];
... }
Para corrigir isso, devemos validar "EALIST_SIZE(ea_buf->xattr)" antes de utilizá-lo.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.