🇰🇷 한글 설명
Linux 커널의 HID picolcd 드라이버에서 eeprom debugfs 읽기 시 데이터 길이를 검증하지 않는 취약점이 발견되었습니다. 공격자가 조작된 장치를 연결할 경우, 실제 수신된 데이터보다 큰 길이를 전달하여 커널 슬랩 메모리의 인접 영역을 읽고 사용자 공간으로 유출할 수 있습니다.
💡 쉬운 설명
특정 하드웨어 장치가 거짓 정보를 보내면 컴퓨터의 중요한 메모리 내용을 몰래 훔쳐볼 수 있는 결함입니다. 하지만 이 문제를 일으키려면 특수하게 제작된 장치를 직접 연결해야 하므로 일반적인 상황에서는 위험이 낮습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
HID: picolcd: clamp eeprom debugfs read to bytes actually received
picolcd_debug_eeprom_read() trusts resp->raw_data[2] -- a length byte
supplied by the device in its REPORT_EE_DATA reply -- clamped only to
the caller's read() count:
ret = resp->raw_data[2];
if (ret > s)
ret = s;
if (copy_to_user(u, resp->raw_data+3, ret))
It never checks resp->raw_size, the number of bytes picolcd_raw_event()
actually copied into the 64-byte raw_data[] of the kmalloc'd struct
picolcd_pending. A device (or a spoofed picoLCD) returning a length byte
of 0xff, read with a count >= 255, makes copy_to_user() read past
raw_data[] into adjacent slab memory and return it to userspace through
the debugfs "eeprom" file:
BUG: KASAN: slab-out-of-bounds in _copy_to_user
Read of size 255 ... picolcd_debug_eeprom_read+0x214/0x2f0 [hid_picolcd]
The debug-dump path in the same file already validates the device length
byte against the received size before trusting it; this read does not.
The file is created S_IRUSR (root-only) and a crafted device is needed,
so it is neither unprivileged- nor remotely-triggerable.
Clamp the copy length to resp->raw_size - 3 (the payload actually
received, minus the 3-byte header), floored at 0 for short replies.
📍 영향받는 시스템
Linux kernel (HID picolcd driver 포함 버전)
⚔️ 공격 벡터
조작된 picolcd 장치를 시스템에 물리적으로 연결하여 debugfs를 통해 메모리 데이터 유출
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 picolcd 데이터 길이 검증 로직 적용
🔧 검증 코드
출력된 커널 버전이 picolcd 취약점이 수정된 최신 패치 버전인지 확인