Note: This is an archival copy of Security Sun Alert 201339 as previously published on http://sunsolve.sun.com.
Latest version of this security advisory is available from http://support.oracle.com as Sun Alert 1001013.1.
Article ID : 1001013.1
Article Type : Sun Alerts (SURE)
Last reviewed : 2007-10-17
Audience : PUBLIC
Copyright Notice: Copyright © 2010, Oracle Corporation and/or its affiliates.

Security Vulnerabilities in Solaris Kernel Statistics Retrieval Process May Allow a Denial of Service (DoS)



Category
Security

Release Phase
Resolved

Product
Solaris 9 Operating System
Solaris 10 Operating System
Solaris 8 Operating System

Bug Id
6351793, 6358047

Date of Resolved Release
18-OCT-2007

Impact

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.


Contributing Factors

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

Symptoms

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.


Workaround

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


Resolution

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


References

122300-13
122301-13
127111-01
127112-01
117350-50
117351-50




Attachments
This solution has no attachment