🇰🇷 한글 설명
Linux 커널의 pinmux 서브시스템에서 같은 GPIO를 두 클라이언트가 동시에 요청할 때, desc->mux_usecount는 갱신되었지만 desc->mux_owner는 아직 설정되지 않은 상태에서 다른 프로세스가 이를 참조하여 NULL 포인터 역참조가 발생하는 문제입니다. 이를 해결하기 위해 mux 관련 설정 접근을 mutex로 직렬화합니다.
💡 쉬운 설명
두 프로그램이 같은 핀을 동시에 사용하려 할 때 커널이 잘못된 메모리 주소를 읽어 멈출 수 있습니다. 접근 순서를 강제로 한 줄로 세워 이 충돌을 막는 패치입니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
pinmux: Use sequential access to access desc->pinmux data
When two client of the same gpio call pinctrl_select_state() for the
same functionality, we are seeing NULL pointer issue while accessing
desc->mux_owner.
Let's say two processes A, B executing in pin_request() for the same pin
and process A updates the desc->mux_usecount but not yet updated the
desc->mux_owner while process B see the desc->mux_usecount which got
updated by A path and further executes strcmp and while accessing
desc->mux_owner it crashes with NULL pointer.
Serialize the access to mux related setting with a mutex lock.
cpu0 (process A) cpu1(process B)
pinctrl_select_state() { pinctrl_select_state() {
pin_request() { pin_request() {
...
....
} else {
desc->mux_usecount++;
desc->mux_usecount && strcmp(desc->mux_owner, owner)) {
if (desc->mux_usecount > 1)
return 0;
desc->mux_owner = owner;
} }
📍 영향받는 시스템
Linux 커널 pinmux/pinctrl 서브시스템을 사용하는 대부분의 배포판 및 임베디드 장치 (수정 이전 커널 버전 전반)
⚔️ 공격 벡터
로컬 권한을 가진 사용자나 프로세스가 같은 GPIO 핀에 대해 동시에 상태 변경을 유발하여 레이스 컨디션으로 커널 NULL 포인터 역참조(서비스 거부)를 일으킴
🛡️ 대응 방법
배포판 제공 커널 보안 업데이트를 적용하거나, mutex 직렬화 패치가 포함된 상위 안정 커널 버전으로 업그레이드
🔧 검증 코드
출력된 커널 버전을 배포판 보안 공지(또는 kernel.org의 stable 패치 목록)와 대조하여 CVE-2024-47141 수정이 포함된 버전인지 확인합니다. 패키지 기준으로는 apt changelog 또는 rpm -q --changelog 로 해당 CVE 언급 여부를 확인할 수 있습니다.