Note: This is an archival copy of Security Sun Alert 265608 as previously published on http://sunsolve.sun.com.
Latest version of this security advisory is available from http://support.oracle.com
as Sun Alert 1020829.1.

1. Impact

A security vulnerability with the Solaris IPv6 networking stack
involving the
Cassini Gigabit-Ethernet Device Driver (ce(7D)) and jumbo frames may
allow
a remote user to panic the system. This is a type of Denial of Service
(DoS) condition.

Note: A similar issue exists for systems using IPv4 networking. See Sun Alert 257008 for details:

http://sunsolve.sun.com/search/document.do?assetkey=1-66-257008-1

2. Contributing Factors

This issue can occur in the following releases:

SPARC platform

Solaris 10 without patch 141414-10

OpenSolaris based upon builds snv_01 through snv_82, and snv_111
through snv_123

x86 platform

Solaris 10 without patch 141415-10

OpenSolaris based upon builds snv_01 through snv_82, and snv_111
through snv_123

Notes: Solaris 9 and Solaris 8 are not impacted by this
issue.

A system is only vulnerable to this issue if it is using a GigaSwift
Ethernet Adapter (CE)
interface (ce(7D)) which has been configured to accept jumbo
frames and
is configured for IPv6 and hardware checksumming is enabled.

To determine if there are any active CE interfaces present on a system,
run the following command:

To determine if jumbo frames are in use on a CE interface, use the
following ndd commands:

# ndd -set /dev/ce instance 1 # ndd -get /dev/ce accept_jumbo 1

The above two commands must be repeated for each CE interface
present on
the system (adjusting the instance number in the first command
accordingly).

The file /kernel/drv/ce.conf may also include the accept_jumbo=1
directive, either globally or for a subset of interfaces, but the above
ndd commands will give the current state of the running interfaces.

To determine whether hardware checksumming is enabled, run the following
command as root:

# echo "dohwcksum/X" | /usr/bin/mdb -k dohwcksum: dohwcksum: 1

A value of 1 indicates that hardware checksumming is enabled
(default value).
A value of 0 indicates hardware checksumming is disabled.

Note 3: Some third party storage systems have been seen to
generate
jumbo ethernet packets which may trigger this issue and cause the
Solaris system to panic.

Note 4: The use of the kernel memory debugging facility
'kmem_flags'
will greatly increase the likelihood of a panic. To determine if
kmem_flags is set, run the following command as root:

# echo "kmem_flags/X" | /usr/bin/mdb -k kmem_flags: kmem_flags: 0

A value of zero indicates kmem_flags is not set. Any other value
indicates one or more of the kmem debugging facilities is active.

3. Symptoms

If the described issue occurs, the system will panic with a BAD TRAP
type 31, and a stack trace similar to the following: