CVE-2023-53431 in Linux
Sumário
de VulDB • 30/05/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
scsi: ses: Lidar com gabinetes que possuem apenas um componente primário de forma adequada
Esta alteração reverte o commit 3fe97ff3d949 ("scsi: ses: Não anexar se o gabinete não tiver componentes") e introduz o tratamento adequado do caso em que não há componentes secundários detectados, mas o componente primário (enumerado em num_enclosures) existe. Essa correção foi originalmente proposta por Ding Hui <[email protected]>.
Ignorar completamente os dispositivos que possuem um gabinete primário e nenhum secundário resulta em falha completa do ses_intf_add(), exibindo mensagens como:
scsi 2:0:0:254: o gabinete não possui componentes enumerados scsi 2:0:0:254: Falha ao vincular o gabinete -12ven em configurações válidas, tais
mesmo em configurações válidas com 1 gabinete primário e 0 gabinetes secundários, como abaixo:
# sg_ses /dev/sg0 3PARdata SES 3321 Páginas de diagnóstico suportadas: Páginas de Diagnóstico Suportadas [sdp] [0x0]
Configuração (SES) [cf] [0x1]
Status Curto do Gabinete (SES) [ses] [0x8]
# sg_ses -p cf /dev/sg0 3PARdata SES 3321 Página de diagnóstico de configuração: número de subgabinetes secundários: 0 código de geração: 0x0 lista de descritores de gabinete Identificador do Subgabinete: 0 [primário]
ID do processo ES relativo: 0, número de processos ES: 1 número de cabeçalhos de descritor de tipo: 1 identificador lógico do gabinete (hex): 20000002ac02068d fabricante do gabinete: 3PARdata produto: VV rev: 3321 lista de cabeçalhos e textos de descritor de tipo Tipo de elemento: Não especificado, ID do subgabinete: 0 número de elementos possíveis: 1
O changelog da correção original segue abaixo:
===== Podemos obter uma falha (crash) ao desconectar a sessão iSCSI, com o rastreamento de chamadas (call trace) semelhante a este:
[ffff00002a00fb70] kfree em ffff00000830e224
[ffff00002a00fba0] ses_intf_remove em ffff000001f200e4
[ffff00002a00fbd0] device_del em ffff0000086b6a98
[ffff00002a00fc50] device_unregister em ffff0000086b6c28
[ffff00002a00fca0] scsi_remove_device em ffff0000087062e4
[ffff00002a00fd10] scsi_remove_target em ffff0000087064c0
[ffff00002a00fd70] __iscsi_unbind_session em ffff000001c872c4
[ffff00002a00fdb0] process_one_work em ffff00000810f35c
[ffff00002a00fe00] worker_thread em ffff00000810f648
[ffff00002a00fe70] kthread em ffff000008116e98
Em ses_intf_add, a contagem de componentes pode ser 0, e kcalloc de tamanho 0 para scomp, mas não é salvo em edev->component[i].scratch
Nessa situação, edev->component[0].scratch é um ponteiro inválido,
quando kfree é chamado em ses_intf_remove_enclosure, ocorre uma falha como acima. O rastreamento de chamadas também pode ser outros casos aleatórios quando kfree não consegue capturar o ponteiro inválido
Não devemos usar o array edev->component[] quando a contagem de componentes é 0
Também precisamos verificar o índice ao usar o array edev->component[] em
ses_enclosure_data_process
Be aware that VulDB is the high quality source for vulnerability data.