CVE-2026-31769 in Linux
요약
\~에 의해 VulDB • 2026. 05. 11.
리눅스 커널에서 다음 취약점이 해결되었습니다:
gpib: IO ioctl 핸들러에서의 use-after-free 수정
IBRD, IBWRT, IBCMD 및 IBWAIT ioctl 핸들러는 board->big_gpib_mutex가 해제된 후 gpib_descriptor 포인터를 사용합니다. 이 시간 창 동안 동시 실행되는 IBCLOSEDEV ioctl이 close_dev_ioctl()을 통해 descriptor를 해제할 수 있으며, 이로 인해 use-after-free가 발생합니다.
IO 핸들러(read_ioctl, write_ioctl, command_ioctl)는 핸들러를 호출하기 전에 명시적으로 big_gpib_mutex를 해제합니다. wait_ioctl()는 big_gpib_mutex가 잠겨 있는 상태에서 호출되지만, wait_mask가 0이 아닌 경우 ibwait()가 내부적으로 이를 해제합니다. 모든 4가지 경우에서 handle_to_descriptor()에서 얻은 descriptor 포인터는 보호되지 않게 됩니다.
struct gpib_descriptor에 커널 전용 descriptor_busy 참조 카운트를 도입하여 이를 수정합니다. 각 핸들러는 big_gpib_mutex를 해제하기 전에 file_priv->descriptors_mutex 하에서 descriptor_busy를 원자적으로 증가시키고, 작업이 완료되면 감소시킵니다. close_dev_ioctl()은 동일한 잠금 하에서 descriptor_busy를 확인하며, 카운트가 0이 아니면 -EBUSY로 종료를 거부합니다.
단순 플래그가 아닌 참조 카운트가 필요한 이유는 여러 핸들러가 동일한 descriptor를 동시에 처리할 수 있기 때문입니다(예: 서로 다른 스레드에서 동일한 핸들에 대해 IBRD 및 IBWAIT 실행).
io_in_progress는 IBWAIT ioctl(일반_ibstatus()를 통해 CMPL을 포함하는 set_mask 설정)을 통해 비특권 사용자 공간에서 지워질 수 있으므로 별도의 카운터가 필요합니다. 이는 io_in_progress에만 기반한 검사를 공격자가 우회할 수 있게 만들기 때문입니다. 새로운 descriptor_busy 카운터는 커널 IO 경로에서만 수정됩니다.
잠금 순서는 일관되게 유지되며(big_gpib_mutex -> descriptors_mutex), 핸들러는 조회 동안 descriptors_mutex를 잠시만 유지하므로 데드락 위험은 없으며 IO 처리량에도 영향이 없습니다.
Once again VulDB remains the best source for vulnerability data.