Bug 22177

Summary:

in_arpinput() doesn't call m_pullup() while it should

Product:

Base System

Reporter:

Yar Tikhiy <yar>

Component:

kern

Assignee:

Yar Tikhiy <yar>

Status:

Closed FIXED

Severity:

Affects Only Me

Priority:

Normal

Version:

4.1-STABLE

Hardware:

Any

OS:

Any

Attachments:

Description	Flags
file.diff	none

Description Yar Tikhiy 2000-10-21 10:50:01 UTC

	The processing of incoming ARP packets is split into two
	parts, the lower one (arpintr()) being protocol-independent,
	and the uppper one (in_arpinput) being IP-specific. The
	lower one uses m_pullup() to ensure the arp header is
	contiguous in memory and can be accessed with mtod().
	However, the length of data being pulled up is smaller than
	required for IP ARP (but still enough for the protocol-independent
	part of the ARP header). The upper part doesn't call
	m_pullup() at all and so can be made by a malicious cracker
	sending too short ARP packets to access memory beyond the
	actual data boundary. Of course, there is usually some
	spare space in a mbuf cluster there, but that's still a
	dangerous behaviour.

	Moreover, that may break some sophisticated encapsulation
	schemes, such as VLANs (and it does break in some cases)

	Thus, yet another m_pullup() won't hurt.

How-To-Repeat: 
	Take a look at the code in file netinet/if_ether.c,
	functions arpintr() and in_arpinput()

Comment 1 Yar Tikhiy freebsd_committer

2001-03-27 13:36:42 UTC

State Changed
From-To: open->closed

Fixed

Comment 2 Yar Tikhiy freebsd_committer

2001-03-27 14:33:11 UTC

State Changed
From-To: closed->analyzed

Reopen the PR and assign it to myself 
because the fix went only to -current right now 
and needs to be MFCed to -stable in perspective.

Comment 3 Yar Tikhiy freebsd_committer

2001-03-27 14:33:11 UTC

Responsible Changed
From-To: freebsd-bugs->yar

It's me who deals with the problem.

Comment 4 Yar Tikhiy freebsd_committer

2001-03-31 12:11:14 UTC

State Changed
From-To: analyzed->closed

Fixed in both branches