Note: This is an archival copy of Security Sun Alert 200794 as previously published on
Latest version of this security advisory is available from as Sun Alert 1000609.1.
Article ID : 1000609.1
Article Type : Sun Alerts (SURE)
Last reviewed : 2003-10-21
Audience : PUBLIC
Copyright Notice: Copyright © 2010, Oracle Corporation and/or its affiliates.

NFS Server May Panic Upon Receipt of Certain Invalid Client Requests


Release Phase

Solaris 9 Operating System
Solaris 7 Operating System
Solaris 8 Operating System

Bug Id

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.

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.


  1. Solaris 2.6 will not be evaluated regarding the potential impact of the issue described in this Sun Alert.
  2. Solaris NFS Clients do not issue the specific type of request which causes the UFS panic.
  3. Some Linux systems have been observed to cause this issue when sending NFS client requests to a Solaris NFS Server.


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:

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



This solution has no attachment