🇰🇷 한글 설명
Linux 커널의 NFSD에서 open 및 lock stateid를 회수할 때 export 참조를 적절히 해제하지 않는 취약점이 발견되었습니다. 이로 인해 export 참조가 유지되어 시스템에서 unmount가 불가능해지는 리소스 누수 문제가 발생할 수 있습니다.
💡 쉬운 설명
파일 공유 서비스(NFS)를 사용할 때 사용 기록이 제대로 삭제되지 않아, 공유 중인 폴더를 연결 해제(unmount)할 수 없게 만드는 버그입니다. 시스템이 해당 폴더를 여전히 누군가 사용 중이라고 착각하여 발생하는 문제입니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: Release the export reference when reaping open stateids
nfs4_put_stid() releases the svc_export tracked in
nfs4_stid.sc_export, but free_ol_stateid_reaplist() frees open and
lock stateids by calling ->sc_free() directly, bypassing that path.
An open stateid takes an sc_export reference in nfs4_open() and a
lock stateid takes its own in init_lock_stateid(); both reach
free_ol_stateid_reaplist() through their normal teardown, the open
stateid via release_open_stateid() and the lock stateid via
nfsd4_release_lockowner(), each through put_ol_stateid_locked().
The reference is therefore never dropped, pinning the export and
blocking unmount for the lifetime of the stateid.
Release sc_export in free_ol_stateid_reaplist() the way
nfs4_put_stid() does. ->sc_free() runs once per stateid, and a
stateid reaches free_ol_stateid_reaplist() or nfs4_put_stid() but
never both, so the reference is dropped exactly once. Revoked
stateids reach this path with sc_export already cleared by
drop_stid_export(), so they are skipped rather than double-freed.
nfs4_put_stid() itself read sc_export before acquiring cl_lock.
drop_stid_export() clears that field and releases the reference
under cl_lock, so a concurrent revocation could drop the export in
the window between the read and the final put, releasing the same
reference twice. Read sc_export while cl_lock is held so the two
paths serialize and the reference is released exactly once.
📍 영향받는 시스템
Linux kernel (NFSD component)
⚔️ 공격 벡터
로컬 또는 네트워크를 통한 NFS 상태 정보(stateid)의 비정상적 유지 및 관리
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하십시오.
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 수정된 패치 버전 이후인지 확인하십시오.