🇰🇷 한글 설명
Linux 커널의 ft260 HID 드라이버에서 I2C 읽기 경합 조건으로 인해 stack-use-after-return 취약점이 발생합니다. 악의적인 하드웨어가 응답을 지연시켜 읽기 함수가 스택 프레임을 해제한 후, 인터럽트 경로를 통해 해제된 스택 위치에 데이터를 쓰는 방식으로 공격이 가능합니다.
💡 쉬운 설명
특수한 하드웨어를 연결했을 때, 컴퓨터의 메모리 관리 오류를 이용해 시스템을 망가뜨릴 수 있는 보안 약점입니다. 하드웨어가 일부러 응답을 늦게 보내 컴퓨터가 이미 사용을 끝낸 메모리 공간에 데이터를 강제로 쓰게 만듭니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
HID: ft260: fix stack-use-after-return write in I2C read race
ft260_i2c_read() points dev->read_buf at a caller-supplied buffer
(often an on-stack variable), arms a completion and waits up to five
seconds for the device to return the data. The HID input callback
ft260_raw_event() runs in the input/IRQ path, independent of the
dev->lock mutex held by the read path, and copies the device-supplied
payload into dev->read_buf after a plain NULL check.
These two paths share read_buf, read_idx and read_len with no
serialization. If the device delays its response until the read
times out, ft260_i2c_read() resets the controller, clears read_buf
and returns, unwinding the stack frame the buffer lived in. A
response that arrives at that moment lets ft260_raw_event() pass the
NULL check and then memcpy() the device-controlled payload into the
now-freed stack location, a bounded but attacker-influenced
stack-use-after-return write triggerable by malicious or
malfunctioning hardware.
Add a dedicated spinlock that serializes every access to read_buf,
read_idx and read_len. ft260_raw_event() now holds it across the
NULL check, the memcpy and the index update, while the read path
takes it when arming and when clearing the buffer, so the teardown
can no longer slip between the check and the copy.
📍 영향받는 시스템
Linux kernel (ft260 HID driver 포함 버전)
⚔️ 공격 벡터
악의적이거나 오작동하는 하드웨어를 통한 물리적 공격 (Local/Physical)
🛡️ 대응 방법
ft260 드라이버에 전용 spinlock을 추가하여 메모리 접근을 직렬화한 최신 커널로 업데이트
🔧 검증 코드
출력된 커널 버전이 ft260 관련 패치가 적용된 최신 보안 업데이트 버전인지 확인합니다.