🔍 CVE-2026-97979

0.0
CVSS Score
UNKNOWN
2026-09-25
2026-10-19 10:17
✅ 완료

🇰🇷 한글 설명

Linux 커널의 ice 드라이버에서 sched_node_ids를 위한 xarray를 추가했으나, 이를 해제하는 xa_destroy 함수를 호출하지 않아 메모리 누수가 발생합니다. 이 문제를 해결하기 위해 xarray를 port_info 구조체에서 hw 구조체로 이동시키고 적절한 정리 경로에 xa_destroy를 추가했습니다.

💡 쉬운 설명

컴퓨터가 작업을 위해 메모리를 빌려 쓰고 나서 돌려주지 않는 '메모리 누수' 문제가 발견되었습니다. 이로 인해 시스템을 오래 사용하면 메모리가 부족해질 수 있는 결함입니다.

🇺🇸 원문 (English)

In the Linux kernel, the following vulnerability has been resolved: ice: add missing xa_destroy for sched_node_ids Commit 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node") added a sched_node_ids xarray to the port info structure, but never called xa_destroy on it. Since xarrays can allocate internal memory, this can result in a memory leak even if every element in the xarray has been removed. The xarray is currently embedded in the port_info structure. This appears to have been done because its use is within functions that take the port_info as a primary argument. However, this complicates managing the lifecycle of the field. The port_info structure is allocated in ice_init_hw() using devm, and it is not released until the devm cleanup when the driver is unloaded. The ice_init_hw() function is called in many places, including devlink reload, and possibly during DDP load after updating the Tx scheduler layout. Adding a call of xa_destroy to the ice_deinit_hw() causes Sashiko to raise multiple concerns due to potential ordering issues and possible ways that port_info could be a dangling reference. To handle this, move the sched_node_ids out of port_info and into the hw structure. All users of the array already have a pointer to hw anyways, and there is only one sched_node_ids per adapter. While here, remove the overly verbose comment explaining the nature of the sched_node_ids xarray. Add the missing xa_destroy to the cleanup path and to ice_deinit_hw(), ensuring that we properly release the xarray memory. This was caught by Sashiko during development of unrelated code.

📍 영향받는 시스템

Linux kernel (ice driver 사용 시스템)

⚔️ 공격 벡터

직접적인 공격은 어려우나, 드라이버 로드/언로드 반복을 통해 시스템 자원을 고갈시키는 DoS 공격이 가능할 수 있음

🛡️ 대응 방법

해당 패치가 적용된 최신 Linux 커널로 업데이트

🔧 검증 코드

출력된 커널 버전이 해당 패치가 포함된 버전인지 배포판 보안 공지를 통해 확인

Shell / Script
uname -r

💻 영향받는 소프트웨어

Linux Kernel