Category
Security
Release Phase
Resolved
ProductSolaris 9 Operating System
Solaris 7 Operating System
Solaris 8 Operating System
Bug Id
4854840
Date of Resolved Release27-OCT-2003
Impact
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.
Contributing Factors
This issue can occur in the following releases:
SPARC Platform
-
Solaris 7 without patch 106541-27
-
Solaris 8 without patch 108528-24
-
Solaris 9 without patch 113454-11
x86 Platform
-
Solaris 7 without patch 106542-27
-
Solaris 8 without patch 108529-24
-
Solaris 9 without patch 114563-07
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.
Notes:
-
Solaris 2.6 will not be evaluated regarding the potential impact of the issue described in this Sun Alert.
-
Solaris NFS Clients do not issue the specific type of request which causes the UFS panic.
-
Some Linux systems have been observed to cause this issue when sending NFS client requests to a Solaris NFS Server.
Symptoms
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.
Workaround
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.
Resolution
This issue is addressed in the following releases:
SPARC Platform
-
Solaris 7 with patch 106541-27 or later
-
Solaris 8 with patch 108528-24 or later
-
Solaris 9 with patch 113454-11 or later
x86 Platform
-
Solaris 7 with patch 106542-27 or later
-
Solaris 8 with patch 108529-24 or later
-
Solaris 9 with patch 114563-07 or later
Modification History
References
106541-27
106542-27
108528-24
108529-24
113454-11
114563-07
AttachmentsThis solution has no attachment