🔍 CVE-2026-43489

5.5
CVSS Score
MEDIUM
2026-05-13
2026-06-26 19:16
✅ 완료

🇰🇷 한글 설명

Linux 커널의 liveupdate 구성 요소에서 luo_file의 retrieve 상태를 제대로 저장하지 않아 발생하는 취약점입니다. retrieve 작업이 실패했을 때 오류 상태를 기록하지 않아, 재시도 시 이미 해제된 데이터 구조체에 접근하거나 잘못된 작업을 수행하여 시스템 오류를 유발할 수 있습니다.

💡 쉬운 설명

파일을 업데이트하는 과정에서 오류가 발생했을 때, 시스템이 이 오류를 기억하지 못해 똑같은 실수를 반복하는 문제입니다. 이로 인해 이미 사용이 끝난 데이터를 다시 건드리게 되어 컴퓨터 시스템이 오작동하거나 멈출 수 있습니다.

🇺🇸 원문 (English)

In the Linux kernel, the following vulnerability has been resolved: liveupdate: luo_file: remember retrieve() status LUO keeps track of successful retrieve attempts on a LUO file. It does so to avoid multiple retrievals of the same file. Multiple retrievals cause problems because once the file is retrieved, the serialized data structures are likely freed and the file is likely in a very different state from what the code expects. The retrieve boolean in struct luo_file keeps track of this, and is passed to the finish callback so it knows what work was already done and what it has left to do. All this works well when retrieve succeeds. When it fails, luo_retrieve_file() returns the error immediately, without ever storing anywhere that a retrieve was attempted or what its error code was. This results in an errored LIVEUPDATE_SESSION_RETRIEVE_FD ioctl to userspace, but nothing prevents it from trying this again. The retry is problematic for much of the same reasons listed above. The file is likely in a very different state than what the retrieve logic normally expects, and it might even have freed some serialization data structures. Attempting to access them or free them again is going to break things. For example, if memfd managed to restore 8 of its 10 folios, but fails on the 9th, a subsequent retrieve attempt will try to call kho_restore_folio() on the first folio again, and that will fail with a warning since it is an invalid operation. Apart from the retry, finish() also breaks. Since on failure the retrieved bool in luo_file is never touched, the finish() call on session close will tell the file handler that retrieve was never attempted, and it will try to access or free the data structures that might not exist, much in the same way as the retry attempt. There is no sane way of attempting the retrieve again. Remember the error retrieve returned and directly return it on a retry. Also pass this status code to finish() so it can make the right decision on the work it needs to do. This is done by changing the bool to an integer. A value of 0 means retrieve was never attempted, a positive value means it succeeded, and a negative value means it failed and the error code is the value.

📍 영향받는 시스템

Linux kernel (liveupdate/luo_file 관련 모듈 사용 환경)

⚔️ 공격 벡터

사용자 공간(userspace)에서 LIVEUPDATE_SESSION_RETRIEVE_FD ioctl을 반복 호출하여 오류 상태를 유도하는 방식

🛡️ 대응 방법

Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 retrieve 상태를 정수로 관리하도록 수정해야 합니다.

🔧 검증 코드

출력된 커널 버전이 해당 취약점이 해결된 패치 버전 이후인지 확인합니다.

Shell / Script
uname -r

📊 CVSS Vector String

CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

💻 영향받는 소프트웨어

Linux Kernel