A privileged user on a Sun Cluster node which is a current cluster member may be able to corrupt in-memory data structures of a sibling cluster node. This can lead to a system panic and/or data corruption on the sibling node which can affect application throughput or availability of data or applications to end users depending on how the Sun Cluster is configured and is thus a type of Denial of Service (DoS).

This issue can occur in the following releases:

SPARC Platform

• Sun Cluster 3.1 (for Solaris 8) without patch 117950-29
• Sun Cluster 3.1 (for Solaris 9) without patch 117949-29
• Sun Cluster 3.1 (for Solaris 10) without patch 120500-14
• Solaris Cluster 3.2 (for Solaris 9) without patch 126105-01
• Solaris Cluster 3.2 (for Solaris 10) without patch 126106-01

x86 Platform

• Sun Cluster 3.1 (Solaris 9) without patch 117909-29
• Sun Cluster 3.1 (Solaris 10) without patch 120501-14
• Solaris Cluster 3.2 (Solaris 10) without patch 126107-01

Note 1: Sun Cluster 3.0 is not affected by this issue.

Note 2: Sun Cluster 3.1 is not supported on Solaris 8. Solaris Cluster 3.2 is not supported on the x86 platform for either Solaris 8 or Solaris 9.

Note 3: The Symcli backup software version 6.2.1 which is supplied by EMC may trigger this issue and cause attached cluster nodes to panic or experience data corruption.

Note 4: EMC Symcli backup software is installed under "/opt/emc/SYMCLI". Under this path, a directory is named as the Symcli version.

If the described issue occurs, data corruption and "send_mondo" panics may occur with a stack trace similar to the following:

    genunix:cdev_ioctl()
    did:didioctl()
    specfs:spec_ioctl()
    pxfs:void fobj_ii::cascaded_ioctl ( )
    pxfs:void io_repl_impl::cascaded_ioctl ( )
    cl_comm:void _fs_fobj_cascaded_ioctl_receive()
    cl_comm:void replica_handler::handle_incoming_call()
    cl_comm:void rxdoor::handle_request_common()
    cl_comm:void rxdoor::handle_twoway()
    cl_comm:void recstream::execute() - frame recycled
    cl_comm:void threadpool_worker_t::deferred_task_handler()
    cl_comm:void threadpool::thread_handler()
    cl_comm:cllwpwrapper()
    unix:thread_start()
    ---xxx---
    panic string:   send_mondo_set: timeout

Note: A "Bad Trap" panic could be another symptom for this issue.

There is no workaround. Please see the Resolution section below.

This issue is addressed in the following releases:

SPARC Platform

• Sun Cluster 3.1 (for Solaris 8) with patch 117950-29 or later
• Sun Cluster 3.1 (for Solaris 9) with patch 117949-29 or later
• Sun Cluster 3.1 (for Solaris 10) with patch 120500-14 or later
• Solaris Cluster 3.2 (for Solaris 9) with patch 126105-01 or later
• Solaris Cluster 3.2 (for Solaris 10) with patch 126106-01 or later

x86 Platform

• Sun Cluster 3.1 (Solaris 9) with patch 117909-29 or later
• Sun Cluster 3.1 (Solaris 10) with patch 120501-14 or later
• Solaris Cluster 3.2 (Solaris 10) with patch 126107-01 or later

• State: Resolved
• Updated Contributing Factors and Resolution sections

This solution has no attachment