🇰🇷 한글 설명
Linux 커널의 skb_zerocopy() 함수에서 skb_orphan_frags() 실패 시 소유하지 않은 skb에 대해 skb_tx_error()를 호출하여 발생하는 취약점입니다. 이로 인해 제로카피 작업이 완료된 것으로 잘못 표시되어, ESP(Encapsulating Security Payload) 처리 과정에서 권한이 없는 메모리 영역에 데이터를 덮어쓰는 보안 문제가 발생할 수 있습니다.
💡 쉬운 설명
데이터를 복사하는 과정에서 오류가 발생했을 때, 시스템이 실수로 데이터의 소유권 정보를 잘못 처리하는 문제입니다. 이로 인해 해커가 시스템의 중요한 메모리 영역을 조작하거나 데이터를 오염시킬 위험이 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()
skb_zerocopy() copies frags from @from into @to. On an
skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive
operation on the source skb the copy helper does not own. That completes
@from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the
SKBFL_SHARED_FRAG page-ownership marker.
Both callers already report the failure on their own drop path.
nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in
the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost by
dropping it here.
On Open vSwitch's OVS_ACTION_ATTR_USERSPACE path the skb is not freed on
this error: do_execute_actions() ignores output_userspace()'s return
value and, unless the upcall was the last action, keeps forwarding the
same skb through the flow's remaining actions. The uarg is completed
while that skb is still in flight, telling the producer its buffers are
free, and SKBFL_SHARED_FRAG is cleared on an skb the rest of the stack
still handles. That flag is what makes esp_input() call skb_cow_data()
instead of decrypting in place, so a later local ESP delivery can
decrypt over frags the skb does not own privately.
Leave error reporting to the callers.
📍 영향받는 시스템
Linux Kernel (skb_zerocopy 관련 모듈 사용 시스템)
⚔️ 공격 벡터
네트워크 패킷 처리 과정에서 의도적으로 오류를 유발하여 메모리 소유권 플래그를 조작하는 방식
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하십시오.
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 해결된 패치 버전 이후인지 확인하십시오.