🇰🇷 한글 설명
Linux 커널의 m68k 아키텍처에서 030 버스 에러 핸들러가 커널 모드 데이터 접근 오류를 예외 테이블 확인 없이 항상 SEGV 시그널 또는 패닉으로 처리하던 문제를 수정합니다. 이로 인해 /proc/sysrq_trigger를 통한 태스크 백트레이스 로깅 중 발생하는 버스 에러가 무시되지 않고 잘못 처리될 수 있었습니다. 수정은 PC가 예외 테이블에 있을 경우 do_page_fault()를 호출하도록 bus_error030에 검사를 추가합니다.
💡 쉬운 설명
리눅스 커널이 특정 오래된 프로세서(68030)에서 내부적으로 발생하는 무해한 메모리 오류를 잘못 처리하던 문제입니다. 이번 수정으로 커널이 이런 오류를 올바르게 무시하도록 바뀝니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
m68k: Only force 030 bus error if PC not in exception table
__get_kernel_nofault() does copy data in supervisor mode when
forcing a task backtrace log through /proc/sysrq_trigger.
This is expected cause a bus error exception on e.g. NULL
pointer dereferencing when logging a kernel task has no
workqueue associated. This bus error ought to be ignored.
Our 030 bus error handler is ill equipped to deal with this:
Whenever ssw indicates a kernel mode access on a data fault,
we don't even attempt to handle the fault and instead always
send a SEGV signal (or panic). As a result, the check
for exception handling at the fault PC (buried in
send_sig_fault() which gets called from do_page_fault()
eventually) is never used.
In contrast, both 040 and 060 access error handlers do not
care whether a fault happened on supervisor mode access,
and will call do_page_fault() on those, ultimately honoring
the exception table.
Add a check in bus_error030 to call do_page_fault() in case
we do have an entry for the fault PC in our exception table.
I had attempted a fix for this earlier in 2019 that did rely
on testing pagefault_disabled() (see link below) to achieve
the same thing, but this patch should be more generic.
Tested on 030 Atari Falcon.
📍 영향받는 시스템
Linux 커널 m68k 아키텍처(68030 프로세서 기반 시스템, 예: Atari Falcon), CVSS 점수 미정
⚔️ 공격 벡터
로컬 권한을 가진 사용자가 /proc/sysrq_trigger를 통해 커널 백트레이스 로깅을 유발하는 방식으로 제한적으로 악용될 수 있으며, 원격 공격 경로는 확인되지 않았습니다.
🛡️ 대응 방법
Linux 커널을 이 수정이 포함된 안정 버전으로 업데이트하거나 배포판의 보안 패치를 적용하세요.
🔧 검증 코드
출력된 아키텍처가 m68k이면 해당 시스템이 영향 대상이며, 커널 버전을 배포판 보안 공지와 비교해 수정 패치 포함 여부를 확인하세요.