Note: This is an archival copy of Security Sun Alert 257008 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1020369.1.
Solaris 10 Operating System
Date of Resolved Release
A security vulnerability with the Solaris IPv4 networking stack involving the Cassini Gigabit-Ethernet Device Driver (ce(7D)) and jumbo frames:
A security vulnerability with the Solaris IPv4 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.
2. Contributing Factors
This issue can occur in the following releases:
Note 2: 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 hardware checksumming is enabled.
To determine if there are any active CE interfaces present on a system, run the following command:
# /sbin/ifconfig -a | /bin/grep ^ceTo determine if jumbo frames are in use on a CE interface, use the following ndd commands:
# ndd -set /dev/ce instance 0The 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" | mdb -kA 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" | mdb -kA value of zero indicates kmem_flags is not set. Any other value indicates one or more of the kmem debugging facilities is active.
Note 5: OpenSolaris distributions may include additional bug fixes above and beyond the build from which it was derived. To determine the base build of OpenSolaris, the following command can be used:
$ uname -v
If the described issue occurs, the system will panic with a BAD TRAP type 31, and the stack trace will be similar to one of the following:
panic[cpu3]/thread=2a10423dca0: BAD TRAP: type=31 rp=2a10423d360 addr=3002e530000 mmu_fsr=04. Workaround
There are two possible workarounds for this issue:
1. Disable hardware checksumming by putting the following line in "/etc/system" and rebooting the system:
set ip:dohwcksum = 02. Prevent the network from sending jumbo frames to this host by disabling jumbo frames on the entire subnet.
Note: These workarounds may impact system performance.
This issue is addressed in the following releases:
Note: This has also been a issue for systems using IPv6. That is covered in Sun Alert 265608 :
For more information on Security Sun Alerts, see 1009886.1.
Copyright 2000-2009 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved.
02-Sep-2009: Added Note to Resolution section.
This solution has no attachment