Category
Security
Release Phase
Resolved
ProductSolaris 9 Operating System
Solaris 10 Operating System
Solaris 8 Operating System
Bug Id
6351793, 6358047
Date of Resolved Release18-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:
- The panic message should be "recursive mutex_enter, ..."
- 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:
- The panic message should be "Deadlock: cycle in blocking chain"
- 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
AttachmentsThis solution has no attachment