Note: This is an archival copy of Security Sun Alert 200794 as previously published on http://sunsolve.sun.com.|
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1000609.1.
Solaris 9 Operating System
Solaris 7 Operating System
Solaris 8 Operating System
Date of Resolved Release
When a Solaris NFS Server receives certain invalid requests from a client for a shared UFS file system, it may cause a UFS panic on the server. When the server reboots after the panic, the client may retry the same request, causing the server to panic again, resulting in a panic/reboot loop.
This issue can occur in the following releases:
The issue described will only occur on specific forms of invalid requests; most malformed requests are detected and result in an error being returned to the client.
The system panics with a "NULL pointer dereference" message similar to the following:
BAD TRAP: type=31 rp=2a103176cc0 addr=8 mmu_fsr=0 occurred in module "ufs" due to a NULL pointer dereference
As noted above, the server may panic again upon reboot, due to the client retrying the same, malformed request.
If the NFS client which is issuing the malformed requests can be identified, then rebooting this client or removing it from the network will break the server panic/reboot cycle. Alternatively, the file system(s) being accessed by this client may be shared "read-only".
If the NFS client cannot be identified, the NFS server must first be booted into single user mode. The share must then be disabled on the file system which the client is accessing, or the file system must be shared "read-only". If the share cannot be isolated to a specific file system, then all file systems must be temporarily shared "read-only" until the required patch is applied.
Note: Please see the share(1M) man page for options on file system sharing.
This issue is addressed in the following releases:
This solution has no attachment