🔍 CVE-2026-98562

0.0
CVSS Score
UNKNOWN
2026-10-18
2026-10-19 10:19
✅ 완료

🇰🇷 한글 설명

Linux 커널의 net: libwx 드라이버에서 Tx 타임스탬프 처리 중 레이스 컨디션(경쟁 상태) 취약점이 발견되었습니다. 이로 인해 이미 해제된 skb(소켓 버퍼)를 참조하거나 참조 횟수가 누수되어 시스템 불안정성을 초래할 수 있습니다.

💡 쉬운 설명

네트워크 데이터를 처리하는 과정에서 여러 작업이 동시에 같은 메모리 영역에 접근하여 충돌이 발생하는 문제입니다. 이로 인해 컴퓨터 시스템이 갑자기 멈추거나 오류가 발생할 수 있습니다.

🇺🇸 원문 (English)

In the Linux kernel, the following vulnerability has been resolved: net: libwx: fix races in Tx timestamp handling wx->ptp_tx_skb is shared between the Tx path, the PTP auxiliary worker and the timestamp cleanup paths. The WX_STATE_PTP_TX_IN_PROGRESS bit prevents multiple Tx paths from submitting timestamp requests, but does not serialize the worker against cleanup. As a result, wx_ptp_clear_tx_timestamp() can free an skb after wx_ptp_tx_hwtstamp_work() has obtained its pointer. The worker may then pass the freed skb to skb_tstamp_tx() and release the same reference again. The cleanup path may also clear the in-progress bit while the worker is still processing the old skb. This allows the Tx path to publish a new skb which the worker can subsequently overwrite with NULL, leaking its reference. Add a dedicated spinlock to protect publication and consumption of the Tx timestamp skb. Detach the skb and clear the in-progress bit while holding the lock, then deliver the timestamp and release the skb after dropping it. Use the same locked cleanup in the quiesce path, but keep the detach there free of register accesses: quiesce runs during PCIe error recovery, where MMIO is not reliable, and it deliberately did not touch the device before. The lock is taken with interrupts disabled, because netpoll can call ndo_start_xmit() with hard interrupts already off. When handling a Tx DMA mapping failure, keep the transmit path reference until after comparing the skb under the lock. This prevents skb address reuse from making the error path mistake a newer timestamp request for the failed one.

📍 영향받는 시스템

Linux kernel (net: libwx 드라이버를 사용하는 시스템)

⚔️ 공격 벡터

로컬 공격자가 특정 네트워크 트래픽 패턴을 유도하여 커널 메모리 레이스 컨디션을 유발

🛡️ 대응 방법

Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 전용 스핀락(spinlock)이 적용된 수정본을 적용하십시오.

🔧 검증 코드

출력된 커널 버전을 확인하여 해당 취약점이 해결된 패치 버전 이상인지 확인하십시오.

Shell / Script
uname -r

💻 영향받는 소프트웨어

Linux Kernel