Esta página descreve problemas importantes e correções de bugs encontradas no android-mainline
que podem ser significativas para os parceiros.
15 de novembro de 2024
O Clang foi atualizado para 19.0.1 para
android-mainline
eandroid16-6.12
- Resumo: a nova versão do Clang introduz um limpador de limites para matrizes,
em que o tamanho da matriz é armazenado em uma variável separada vinculada à matriz
usando o atributo
__counted_by
. Esse recurso pode causar um kernel panic se o tamanho da matriz não for atualizado corretamente. A mensagem de erro é semelhante a esta:
UBSAN: array-index-out-of-bounds in common/net/wireless/nl80211.c index 0 is out of range for type 'struct ieee80211_channel *[] __counted_by(n_channels)' (aka 'struct ieee80211_channel *[]')
Detalhes: o limpador de limites é essencial para proteger a integridade do kernel detectando acessos fora dos limites. E com o
CONFIG_UBSAN_TRAP
ativado, o limpador de limites aciona um pânico do kernel em qualquer descoberta.- A versão anterior do limpador de limites verificava apenas matrizes de tamanho fixo
e não podia verificar matrizes alocadas dinamicamente. A nova versão usa o
atributo
__counted_by
para determinar os limites da matriz no momento da execução e detectar mais casos de acesso fora dos limites. No entanto, em alguns casos, a matriz é acessada antes que a variável de tamanho seja definida, o que aciona o limpador de limites e causa um pânico do kernel. Para resolver esse problema, defina o tamanho da matriz imediatamente após alocar a memória subjacente, conforme ilustrado em aosp/3343204.
- A versão anterior do limpador de limites verificava apenas matrizes de tamanho fixo
e não podia verificar matrizes alocadas dinamicamente. A nova versão usa o
atributo
Sobre
CONFIG_UBSAN_SIGNED_WRAP
: a nova versão do Clang limpa o overflow e o underflow de números inteiros assinados, apesar da flag do compilador-fwrapv
. A flag-fwrapv
foi projetada para tratar números inteiros com sinal como números inteiros sem sinal de complemento de dois com comportamento de estouro definido.- Embora a desinfecção de estouro de número inteiro assinado no kernel do Linux possa ajudar
a identificar bugs, há casos em que o estouro é intencional, por
exemplo, com
atomic_long_t
. Como resultado, oCONFIG_UBSAN_SIGNED_WRAP
foi desativado para permitir que o UBSAN funcione apenas como um limpador de limites.
- Embora a desinfecção de estouro de número inteiro assinado no kernel do Linux possa ajudar
a identificar bugs, há casos em que o estouro é intencional, por
exemplo, com
Sobre
CONFIG_UBSAN_TRAP
: o UBSAN é configurado para acionar um kernel panic quando detecta um problema para proteger a integridade do kernel. No entanto, desativamos esse comportamento de 23 de outubro a 12 de novembro. Fizemos isso para desbloquear a atualização do compilador enquanto corrigimos problemas conhecidos do__counted_by
.
- Resumo: a nova versão do Clang introduz um limpador de limites para matrizes,
em que o tamanho da matriz é armazenado em uma variável separada vinculada à matriz
usando o atributo
1º de novembro de 2024
- Página de destino do Linux 6.12-rc4
- Resumo:
CONFIG_OF_DYNAMIC
pode causar regressões graves para drivers com falhas. - Detalhes: ao mesclar o Linux
6.12-rc1
com oandroid-mainline
, notamos problemas com drivers fora da árvore que não carregavam. A mudança que exporou os bugs do driver foi identificada como confirmação274aff8711b2 ("clk: Add KUnit tests for clks registered with struct clk_parent_data")
e revertida temporariamente em aosp/3287735. A mudança selecionaCONFIG_OF_OVERLAY
, que selecionaCONFIG_OF_DYNAMIC
. Com!OF_DYNAMIC
, a contagem de referência emof_node_get()
eof_node_put()
é desativada, já que são implementadas comonoops
. A ativação deOF_DYNAMIC
expõe novamente problemas em drivers que implementam incorretamente a contagem de referências parastruct device_node
. Isso causa vários tipos de erros, como corrupção de memória, uso após a liberação e vazamentos de memória. - Todos os usos de APIs relacionadas à análise de OF precisam ser inspecionados. A lista a seguir é
parcial, mas contém casos que observamos:
- Use After Free (UAF):
- Reutilização do mesmo argumento
device_node
: essas funções chamamof_node_put()
no nó fornecido, possivelmente precisam adicionar umof_node_get()
antes de serem chamadas (por exemplo, quando são chamadas repetidamente com o mesmo nó como argumento):of_find_compatible_node()
of_find_node_by_name()
of_find_node_by_path()
of_find_node_by_type()
of_get_next_cpu_node()
of_get_next_parent()
of_get_next_child()
of_get_next_available_child()
of_get_next_reserved_child()
of_find_node_with_property()
of_find_matching_node_and_match()
- Uso de
device_node
após qualquer tipo de saída de determinados loops:for_each_available_child_of_node_scoped()
for_each_available_child_of_node()
for_each_child_of_node_scoped()
for_each_child_of_node()
- Mantenha ponteiros diretos para propriedades
char *
dedevice_node
, por exemplo, usando:const char *foo = struct device_node::name
of_property_read_string()
of_property_read_string_array()
of_property_read_string_index()
of_get_property()
- Reutilização do mesmo argumento
- Vazamentos de memória:
- Receber um
device_node
e esquecer de remover a referência (of_node_put()
). Os nós retornados precisam ser liberados em algum momento:of_find_compatible_node()
of_find_node_by_name()
of_find_node_by_path()
of_find_node_by_type()
of_find_node_by_phandle()
of_parse_phandle()
of_find_node_opts_by_path()
of_get_next_cpu_node()
of_get_compatible_child()
of_get_child_by_name()
of_get_parent()
of_get_next_parent()
of_get_next_child()
of_get_next_available_child()
of_get_next_reserved_child()
of_find_node_with_property()
of_find_matching_node_and_match()
- Receber um
- Manter um
device_node
de uma iteração de loop. Se você retornar ou interromper o seguinte, precisará excluir a referência restante em algum momento:for_each_available_child_of_node()
for_each_child_of_node()
for_each_node_by_type()
for_each_compatible_node()
of_for_each_phandle()
- Use After Free (UAF):
- A mudança mencionada anteriormente foi restaurada ao lançar o Linux
6.12-rc4
(consulte aosp/3315251) ativando oCONFIG_OF_DYNAMIC
novamente e potencialmente expondo drivers defeituosos.
- Resumo: