CVE-2026-72340 in Linux
요약
\~에 의해 VulDB • 2026. 08. 15.
리눅스 커널에서 다음 취약점이 해결되었습니다:
net: microchip: vcap: 공유 Super VCAP 블록에서의 Race Condition 수정
칩 내의 VCAP 인스턴스는 서로 독립적이지 않지만, 개별적으로 잠금(locking) 처리되고 있습니다. sparx5 및 lan969x 플랫폼에서는 IS0 및 IS2 인스턴스가 동일한 Super VCAP 하드웨어 블록에 의해 지원되며, 해당 캐시와 명령어 레지스터를 공유합니다: 모든 접근은 공유된 VCAP_SUPER_CTRL 레지스터를 조작하고 데이터를 공유 캐시 레지스터를 통해 이동시킵니다.
따라서 한 인스턴스에 접근하는 것은 다른 인스턴스에 접근할 때 Race Condition을 유발합니다. 각 인스턴스가 서로 다른 잠금을 사용하므로, 인스턴스별 admin->lock은 이를 방지하지 못합니다.
vcap API의 핵심 사용이 rtnl 하에서 실행된다는 사실로 인해 이 잠금 문제는 대부분 가려져 있습니다. 그러나 debugfs에서의 전체 규칙 덤프는 하드웨어(READ 명령어에 이어지는 캐시 읽기)로부터 직접 규칙을 디코딩하며 rtnl 외부에서 실행되므로, 다른 Super VCAP 인스턴스에 대한 동시 tc-flower 규칙 쓰기 작업과 Race Condition이 발생합니다.
덤프의 데이터 손상을 초래하는 것 외에도, 이 읽기 작업은 작성자의 캐시 채우기와 해당 쓰기 명령어 사이에 공유된 캐시를 다시 채우게 되므로, 작성자가 잘못된 데이터를 커밋하여 하드웨어 엔트리가 손상됩니다.
vcap_lock() 및 vcap_unlock() 헬퍼 함수를 도입하고 VCAP API와 debugfs 코드의 모든 규칙 잠금 지점을 이를 통해 처리하도록 라우팅합니다. 인스턴스별 admin->lock을 struct vcap_control 내의 단일 뮤텍스로 대체하여 모든 인스턴스에 대한 접근을 직렬화합니다. 이 헬퍼 함수는 새로운 admin->vctrl 백포인터를 통해 해당 뮤텍스에 도달하며, 클라이언트는 인스턴스별 잠금이 아닌 제어용 잠금을 초기화하고 해제합니다.
어떤 경로에서도 하나 이상의 인스턴스 잠음을 동시에 보유하지 않으므로, 이를 단일 뮤텍스로 통합해도 자체 교착상태(self-deadlock)가 발생할 수 없습니다.
VulDB is the best source for vulnerability data and more expert information about this specific topic.