Security vulnerabilities in the implementation of the retrieval of Kernel statistics may allow a local unprivileged user to panic the system, causing a Denial of Service (DoS) condition.

This issue can occur in the following releases:

SPARC Platform:

• Solaris 8 without patch 117350-50
• Solaris 9 without patch 122300-13
• Solaris 10 without patch 127111-01

x86 Platform:

• Solaris 8 without patch 117351-50
• Solaris 9 without patch 122301-13
• Solaris 10 without patch 127112-01

Two different types of panic can result:

A) A 'recursive mutex_enter' panic

To identify this panic scenario, run the following two commands on the crashdump and review the resultant output:

    # echo "::status" | mdb -k unix.0 vmcore.0 | grep "panic message" 
    panic message: recursive mutex_enter, lp=<> owner=<> thread=<>

    # echo "*panic_thread::findstack" | mdb -k unix.0 vmcore.0
    stack pointer for thread 30016e77a00: 2a100ce7ee1
       000002a100ce7f91 mutex_vector_enter+0x334()
       000002a100ce8051 sfmmu_mlspl_enter+0x2c0()
       000002a100ce8101 hat_page_getshare+4()
       000002a100ce81b1 page_create_va+0x564()
       000002a100ce8301 segkmem_page_create+0x78()
       000002a100ce8401 segkmem_xalloc+0xd0()
       000002a100ce84c1 segkmem_alloc+0x9c()
       000002a100ce8581 vmem_xalloc+0x6d4()
       000002a100ce8701 vmem_alloc+0x238()
       000002a100ce87c1 kmem_slab_create+0x44()
       000002a100ce8891 kmem_slab_alloc+0x60()
       000002a100ce8941 kmem_cache_alloc+0x148()
       000002a100ce89f1 kmem_zalloc+0x28()
       000002a100ce8aa1 hrm_init+0x20()
       000002a100ce8b51 hat_setstat+0x64()
       000002a100ce8c01 sfmmu_ttesync+0xe0()
       000002a100ce8cb1 sfmmu_hblk_sync+0x21c()
       000002a100ce8d71 hat_sync+0x378()
       000002a100ce8e71 hat_getstat+0x34()
       000002a100ce8f21 prpdread32+0x3b0()
       000002a100ce90b1 pr_read_pagedata_32+0xc4()
       000002a100ce9161 read+0x29c()
       000002a100ce92e1 syscall_trap32+0x1e8()

Analysis:

1. The panic message should be "recursive mutex_enter, ..."
2. The stack backtrace of the panicking thread should show a call to the hrm_init() function followed by a call to the sfmmu_mlspl_enter() function.

B) A 'Deadlock' panic

To identify this panic scenario, run the following two commands on the crashdump and review the resultant output:

    # echo "::status" | mdb -k unix.0 vmcore.0 | grep "panic message"
    panic message: Deadlock: cycle in blocking chain

    # echo "*panic_thread::findstack" | mdb -k unix.0 vmcore.0
    stack pointer for thread 3003b164ce0: 2a10a2e2941
       000002a10a2e29f1 priv_rtt+0x1c()
       000002a10a2e2b41 0()
       000002a10a2e2bf1 sfmmu_mlspl_enter+0x200()
       000002a10a2e2ca1 hat_pageunload+0x2c()
       000002a10a2e2d61 page_destroy+0x54()
       000002a10a2e2e11 segkmem_free+0xb0()
       000002a10a2e2ec1 hat_freestat+0x164()
       000002a10a2e2f71 prclose+0x18c()
       000002a10a2e3021 fop_close+0x20()
       000002a10a2e30d1 closef+0x4c()
       000002a10a2e3181 closeandsetf+0x37c()
       000002a10a2e3231 close+8()
       000002a10a2e32e1 syscall_trap+0xac()

Analysis:

1. The panic message should be "Deadlock: cycle in blocking chain"
2. The stack backtrace of the panicking thread should show a call to the hat_freestat() function followed by a call to the sfmmu_mlspl_enter() function (or sfmmu_mlist_enter()).

Note: By default, crash dumps are written to /var/crash/<uname -n>. See dumpadm(1M) for more information.

There is no workaround for this issue. Please see the Resolution section below.

This issue is addressed in the following releases:

SPARC Platform:

• Solaris 8 with patch 117350-50 or later
• Solaris 9 with patch 122300-13 or later
• Solaris 10 with patch 127111-01 or later

x86 Platform:

• Solaris 8 with patch 117351-50 or later
• Solaris 9 with patch 122301-13 or later
• Solaris 10 with patch 127112-01 or later

This solution has no attachment