d/freebsd-nq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Check that the mbuf len is positive (like we do in the v4 case).

Browse Source 
Read the other way round this means that even with the checks
the m_len turned negative in some cases which led to panics.
The reason to my understanding seems to be that the checks are wrong
(also for v4) ignoring possible padding when checking cmsg_len or
padding after data when adjusting the mbuf.
Doing proper cheks seems to break applications like named so
further investigation and regression tests are needed.

PR:		kern/119123
Tested by:	Ashish Shukla  wahjava gmail.com
MFC after:	3 days
This commit is contained in:
Bjoern A. Zeeb 2008-10-15 19:24:18 +00:00
parent f6dd5c15fd
commit 6f4da20196
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
sys/netinet6/ip6_output.c
View File

@ -2820,7 +2820,7 @@ ip6_setpktopts(struct mbuf *control, struct ip6_pktopts *opt,
if (control->m_next)
return (EINVAL);
for (; control->m_len; control->m_data += CMSG_ALIGN(cm->cmsg_len),
for (; control->m_len > 0; control->m_data += CMSG_ALIGN(cm->cmsg_len),
control->m_len -= CMSG_ALIGN(cm->cmsg_len)) {
int error;