🇰🇷 한글 설명
Linux 커널의 fs 마운트 전파 로직에서 propagate_mount_busy() 함수가 일부 마운트 복사본의 참조를 검사하지 않아, 사용 중인 마운트가 동기식 언마운트로 잘못 분리될 수 있는 취약점입니다. 컨테이너와 호스트가 공유 마운트 트리를 사용하는 환경에서 특히 문제가 됩니다.
💡 쉬운 설명
사용 중인 파일 시스템 마운트가 실수로 강제로 해제될 수 있는 결함입니다. 공유 마운트를 쓰는 컨테이너 환경에서 호스트의 언마운트 작업이 컨테이너의 열린 파일을 끊을 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
fs: don't silently unmount busy mounts
The propagate_mount_busy() helper exists to decide whether a synchronous
can suceed. It does that by looking at the copies of the victims in the
mounts its parent propagates to. One of those functions from propagation
hell.
It skips a copy that has child mounts except for the case of a single
child mount covering the copy's root. That algorithm used to be exact.
It isn't anymore.
Originally only childless copies were unmounted during propagation.
And 1064f874abc0 ("mnt: Tuck mounts under others instead of creating
shadow/side mounts.") ended up adding covered mounts to both sides in
one go.
Along came 99b19d16471e ("mnt: In propgate_umount handle visiting mounts
in any order") and that started to unmount more than before:
[1]: A copy of a mount is unmounted when each of its children is either
its overmount or a copy of the victim itself. In the former case
the overmount gets reparented. In the latter case the copy of the
victim will end up being unmounted.
So propagate_umount() ended up being rewritten without adjusting
propagate_mount_busy(). And currently propagate_mount_busy() doesn't
look at copies of the victim that have two or more children nor a single
child that is not the overmount.
So any such copy in [1] is not checked for
references. The result is that a synchronous unmount succeeds, pulling
out a mount that is still in use.
A container can run into this with its own mounts. The host shares a
tree with the container and the host has a mount in that tree:
mount -t tmpfs none /mnt
mount --make-shared /mnt
mount -t tmpfs none /mnt/a
The container's /mnt is a slave copy of the host mount. The container
now takes a detached copy of the tree and mounts that copy beneath its
propagated copy of /mnt/a and keeps the file descriptor to the tree
open:
unshare -m --propagation unchanged
mount --make-rslave /
fd = open_tree(AT_FDCWD, "/mnt", OPEN_TREE_CLONE | AT_RECURSIVE)
move_mount(fd, "", AT_FDCWD, "/mnt/a", MOVE_MOUNT_BENEATH)
grep /mnt /proc/self/mountinfo
775 355 ... /mnt ... master:646
777 775 ... /mnt/a ... master:646
776 777 ... /mnt/a ... master:647
778 777 ... /mnt/a/a ... master:647
The now attached tree (777) is now mounted beneath the container's copy
of /mnt/a. That's also where the host mount sits (as seen from the host
mount namespace). So the propagated copy (776) of the host's mount is on
top of its root and the copy of that (778) is inside it. Now the host
runs:
umount /mnt/a
and it succeeds. The moved tree tree and the copy inside of it are gone
from the container. Now only the propagated copy is left and it got
reparented to where it was before:
grep /mnt /proc/self/mountinfo
775 355 ... /mnt ... master:646
776 775 ... /mnt/a ...
But the file descriptor still refers to the moved tree. So a synchronous
umount detached a mount that is still in use.
Teach propagate_mount_busy() the same checks that propagate_umount()
does. It now checks for a single victim mount without children
for which it can assume that MNT_LOCKED is cleared on every copy like
propagate_umount() does. The copies form chains. IOW, when a copy itself
receives propagation from the victim's parent then the mount at the same
mountpoint inside that copy is a copy as well. Whether a mount receives
propagation from the victim's can simply be checked by walking its
masters. Walk each chain once from its top so we are sure that nested
copies stay linear. Check every reference once of every copy that gets
unmounted.
📍 영향받는 시스템
패치가 적용되지 않은 Linux 커널 (CVSS 미정, 정확한 영향 버전은 upstream 수정 커밋 기준으로 확인 필요)
⚔️ 공격 벡터
컨테이너 내부에서 open_tree와 move_mount를 조합해 공유 마운트 전파 구조를 조작한 뒤, 호스트의 umount 실행으로 사용 중인 마운트가 분리되도록 유도
🛡️ 대응 방법
배포판 제공 최신 커널 업데이트를 설치하고 재부팅하여 upstream 수정 사항을 적용
🔧 검증 코드
출력된 커널 버전을 배포판 보안 공지 또는 upstream 수정 커널 버전과 비교하여, 해당 수정이 포함된 최신 버전이면 안전하고 그렇지 않으면 업데이트가 필요합니다.