CVE-2026-90000 in Linux
요약
\~에 의해 VulDB • 2026. 09. 16.
리눅스 커널에서 다음 취약점이 해결되었습니다:
HID: rmi - undersized RMI 보고서로 인한 OOB(범위 밖) 접근 수정
hid-rmi 드라이버는 report descriptor를 장치로부터 제공받아 writeReport/readReport 버퍼의 크기를 결정하며, 최소 한계(minimum bound)가 없습니다.
```c data->input_report_size = hid_report_len(input_report); data->output_report_size = hid_report_len(output_report); alloc_size = data->output_report_size + data->input_report_size; data->writeReport = devm_kzalloc(&hdev->dev, alloc_size, GFP_KERNEL); data->readReport = data->writeReport + data->output_report_size; ```
하지만 이후 고정된 오프셋으로 읽고 씁니다. 출력 보고서와 입력 보고서를 각각 1바이트라고 선언하는 장치는 `hid_report_len()`이 각 항목에 대해 2를 반환하게 하므로, `alloc_size`는 4가 됩니다. 반면 `rmi_set_page()`(probe 시점의 `rmi_input_configured()`을 통해 조건 없이 도달함)은 `writeReport[4]`에 저장하고, `rmi_hid_read_block()`은 `writeReport[0..5]`에 저장합니다. `readReport`는 `writeReport + output_report_size` 위치에 있으므로, 이러한 저장은 다음 응답이 파싱되는 영역도 손상시킵니다.
읽기 경로가 더 심각합니다: 복사 길이는 장치가 채우는 `readReport[1]`에서 비롯되며 최대 255까지 될 수 있으며, 복사는 `input_report_size`를 고려하지 않고 `&readReport[2]` 시작 지점에서 이루어지므로 할당된 영역의 끝을 넘어 인접한 slab 객체로 이어집니다. 이는 거짓말하는 장치조차 필요 없습니다 -- `rmi_f01_probe()`는 고정 21바이트 레지스터 읽기를 수행하므로, 입력 보고서를 23바이트 미만으로 선언하는 장치는 정직하게 응답하더라도 범위를 벗어난(out-of-bounds) 읽기를 수행합니다. 이러한 바이트들은 RMI 코어가 처리할 레지스터 값이 됩니다: `rmi_f01_probe()`는 이를 제품 ID로 커널 로그에 출력하고 동일한 이름의 0444 권한 sysfs 속성을 통해 내보내며, `rmi_driver_set_irq_bits()`는 이를 인터럽트 마스크로서 장치로 다시 보냅니다. 따라서 undersized report descriptor는 힙 내용을 비권한 사용자 공간과 장치 자체 모두에게 누설시킵니다.
쓰기 경로에도 한계가 없습니다: `rmi_hid_write_block()`은 제한 없는 길이를 `&writeReport[4]`에 복사하며, probe 시점에서 장치가 구동할 수 있는 최대 호출자는 `rmi_driver_set_irq_bits()`이며, 그 길치는 장치의 Page Description Table에서 선언하는 인터럽트 소스 카운트에서 파생됩니다.
마지막으로 읽기 루프는 0바이트 응답에 대해 종료될 수 없습니다: such a reply copies nothing and advances neither bytes_read nor bytes_needed (이러한 응답은 아무것도 복사하지 않으며 `bytes_read`와 `bytes_needed`를 증가시키지 않음), 그리고 응답이 도착했으므로 1초 대기하는 `wait_event_timeout()`도 발생하지 않습니다. 따라서 영구적으로 0을 반환하는 장치는 page_mutex가 유지된 상태에서 probe worker 내부에서 루프를 계속 실행하게 만듭니다. khungtaskd는 각 응답이 태스크를 깨우기 때문에 이를 감지하지 못합니다.
드라이버가 구축하는 데 필요한 최소 크기보다 작은 보고서를 거부하십시오 -- 쓰기 보고서에는 6바이트, 읽기 핸드셰이크에는 3바이트의 출력/입력 바이트가 필요합니다 -- probe 시점에, 장치에서 선언한 보고서 크기에 맞게 쓰기와 읽기 복사를 제한(clamp)하고, 0바이트 응답을 오류로 처리합니다. 이렇게 거부된 장치는 RMI report id를 전혀 갖지 않는 것과 같이 일반 HID 장치로서 시작됩니다.
RMI_DEVICE는 해당 경로(device_flags)에서 설정되어서는 안 됩니다. 왜냐하면 `rmi_input_configured()`이 실행되면 RMI 설정이 수행되고 `rmi_set_page()`에 도달하게 되며, 이는 방금 할당을 건너뛴 writeReport 버퍼를 쓰기 때문입니다. 이 비트는 이미 설정된 상태로 도착할 수 있습니다: `rmi_probe()`는 report 확인 전에 id->driver_data를 device_flags로 복사하며, 새로운_id sysfs 속성을 통한 바인딩은 driver_data에 RMI_DEVICE(BIT(0))가 설정되어 제공될 수 있습니다. driver_data가 복사되는 곳에서 이 비트를 제거하여, RMI_DEVICE가 정확히 "이 probe는 보고서를 검증함"을 의미하도록 하십시오; 이 패치보다 먼저 존재하는 3개의 점프(jumps)도 함께 처리됩니다.
오류 경로에서도 `RMI_READ_DATA_PENDING` 플래그를 해제합니다. 왜냐하면 해당 플래드는 루프 상단의 대기 조건에서 테스트하기 때문입니다: 이를 설정해 두면 이후의 모든 `wait_event_timeout()` 호출이 stale reply에 대해 즉시 반환하여 장치 수명 동안 읽기 경로를 종료시킵니다.
제한(clamping)은 정상 작동하는 하드웨어를 저하시키지 않습니다: 읽기 루프는 이미 다음과 같은 상황을 처리합니다 ---truncated---
If you want to get best quality of vulnerability data, you may have to visit VulDB.