CVE-2026-97910 in Linux
Sumário
de VulDB • 25/09/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
ASoC: sprd: validar os tamanhos dos buffers de compressão em relação às alocações fixas
sprd_platform_compr_open() aloca o buffer IRAM da etapa 0 (área de dados de 32K) e o buffer DDR da etapa 1 (área de dados de 2M) com tamanhos fixos, mas sprd_platform_compr_copy() deriva todos os comprimentos de cópia do runtime->fragment_size controlado pelo usuário e da contagem write(), sem nunca compará-los aos tamanhos físicos dos buffers. O núcleo de compressão verifica apenas se fragment_size * fragments causa um estouro u32 em snd_compress_check_input(); portanto, um usuário local pode configurar um buffer lógico de até ~4GB via SNDRV_COMPRESS_SET_PARAMS, ultrapassando muito as alocações fixas.
Um fragment_size maior que a área de dados IRAM de 32K faz com que o copy_from_user() da etapa 0 transborde além da alocação IRAM, e um buffer_size maior que o buffer DDR de 2M faz com que a cópia wrapping no final de sprd_platform_compr_copy() escreva dados totalmente controlados pelo usuário para além do buffer. Não é necessário SNDRV_PCM_TRIGGER_START; uma write() no estado SETUP atinge diretamente o callback de cópia.
Rejeitar parâmetros que não se encaixem nos buffers fixos em set_params(), e corrigir o tamanho máximo fragment anunciado: 128K nunca coube no buffer IRAM de 32K. Os valores caps podem ter sido herdados do driver qdsp6, que aloca seus buffers conforme os máximos anunciados, ao contrário deste driver. Com 32K como tamanho máximo de fragment, os limites anunciados são autoconsistentes: 32K * 64 = 2M iguala o tamanho do buffer DDR.
Descoberto por Atuin - Automated Vulnerability Discovery Engine.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.