]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
Verify the packet length in sctp6_input().
authorGleb Smirnoff <glebius@FreeBSD.org>
Thu, 14 Jan 2016 10:11:10 +0000 (10:11 +0000)
committerGleb Smirnoff <glebius@FreeBSD.org>
Thu, 14 Jan 2016 10:11:10 +0000 (10:11 +0000)
commit479795819a80a3d669f5f36903e3bbf418768f0a
tree236ea1e153963e1dfadb774eb356675d2e50d9e0
parentff7ea78834a2360a86db8beeeb1c7113c6887625
Verify the packet length in sctp6_input().

The sctp6_ctlinput() function does not properly check the length of the packet
it receives from the ICMP6 input routine. This means that an attacker can craft
a packet that will cause a kernel panic.

When the kernel receives an ICMP6 error message with one of the types/codes
it handles, it calls icmp6_notify_error() to deliver it to the upper-level
protocol. icmp6_notify_error() cycles through the extension headers (if any)
to find the protocol number of the first non-extension header. It does NOT
verify the length of the non-extension header.

It passes information about the packet (including the actual packet) to the
upper-level protocol's pr_ctlinput function. In the case of SCTP for IPv6,
icmp6_notify_error() calls sctp6_ctlinput().

sctp6_ctlinput() assumes that the incoming packet contains a sufficiently-long
SCTP header and calls m_copydata() to extract a copy of that header. In turn,
m_copydata() assumes that the caller has already verified that the offset and
length parameters are correct. If they are incorrect, it will dereference a
NULL pointer and cause a kernel panic.

In short, no one is sufficiently verifying the input, and the result is a
kernel panic.

Submitted by: jtl
Security: SA-16:01.sctp
sys/netinet6/sctp6_usrreq.c