CVE-2024-36894 in Linux
요약
\~에 의해 VulDB • 2026. 06. 16.
리눅스 커널에서 다음 취약점이 해결되었습니다:
usb: gadget: f_fs: aio_cancel()과 AIO 요청 완료 간 Race Condition 수정
FFS(Filesystem in Userspace) 기반 애플리케이션은 UDC(USB Device Controller)에 제출된 대기 중인 USB 요청을 대기열에서 제거하기 위해 aio_cancel() 콜백을 사용할 수 있습니다. UDC가 소프트 디스커넥트(soft disconnect)를 처리하는 동안 FFS 애플리케이션이 AIO 취소 호출을 수행하는 시나리오가 존재합니다. DWC3 기반 구현의 경우 호출 스택은 다음과 같습니다:
DWC3 Gadget FFS Application dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue()
현재 AIO 완료 핸들러와 AIO 취소 간에는 잠금(locking)이 구현되어 있지 않으므로, 완료 루틴이 FFS 애플리케이션에서 오는 AIO 취소 호출과 병렬로 실행될 경우 문제가 발생합니다. 완료 호출이 USB 요청(io_data->req)을 해제(free)하는 동안 FFS 애플리케이션도 usb_ep_dequeue() 호출을 위해 해당 요청을 참조하고 있습니다. 이로 인해 무효화된(hanging) 포인터에 접근할 수 있습니다.
커밋 b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")는 usb_ep_free_request()를 ffs_epfile_async_io_complete() 내부로 이동시켰습니다. 그러나 이 문제를 완화하기 위해 잠금을 적절히 구현하려면 spinlock를 ffs_epfile_async_io_complete()에 추가할 수 없습니다. 그 이유는 usb_ep_dequeue()가 USB 요청을 성공적으로 대기열에서 제거할 경우 동일한 컨텍스트에서 함수 드라이버의 완료 핸들러를 호출하기 때문입니다. 이는 데드락(deadlock)으로 이어집니다.
이 문제를 해결하기 위해 usb_ep_free_request()를 ffs_user_copy_worker()로 다시 이동시키고, ffs->eps_lock 내에서 요청을 해제한 후 io_data->req를 명시적으로 NULL로 설정하도록 합니다. 이를 통해 위의 Race Condition이 해결됩니다. ffs_aio_cancel() 루틴은 이미 해제된 요청을 대기열에서 제거하려고 계속 시도하지 않게 되며, ffs_user_copy_work()는 AIO 취소가 해당 요청을 참조하는 동안 USB 요청을 해제하지 않습니다.
이 수정 사항은 다음 커밋에 의존합니다: 커밋 b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.