Date: Fri, 10 Aug 2007 06:21:45 GMT From: Arthur Hartwig <arthur.hartwig@nokia.com> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/115371: Device removal leaves resource database such that "devinfo -r" causes panic Message-ID: <200708100621.l7A6Ljps078622@www.freebsd.org> Resent-Message-ID: <200708100630.l7A6U3rD086762@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 115371 >Category: kern >Synopsis: Device removal leaves resource database such that "devinfo -r" causes panic >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 10 06:30:02 GMT 2007 >Closed-Date: >Last-Modified: >Originator: Arthur Hartwig >Release: 7.0 >Organization: Nokia >Environment: >Description: I have been working on a private implementation of a "PCI hotplug" like device replacement. On device removal and subsequent freeing of resources the kernel resource database is left in a state such that the shell command "devinfo -r" or the ddb command??? can cause a panic. Analysis: Resources are allocated by calling rman_reserve_resource_bound() in kern/subr_rman.c which stores a pointer to the "requesting" device in the r_dev field of the device structure and marks the resource as allocated by setting RF_ALLOCATED in the r_flags field. When the resource is freed, int_rman_release_resource() is called which clears the RF_ALLOCATED flag in the resource structure but does not clear the r_dev field in the resource structure. The devinfo -r command causes sysctl_rman() to be called. sysctl_ramn() walks the resource list and assumes any resource with a non-null r_dev field has a pointer to a valid device structure but if the device structure has been freed the device_get_name(res->r_dev) call may generate a page fault and panic. There is a similar issue in dump_rman() in the same file. >How-To-Repeat: It may be possible to create a panic by removing a cardbus device and then issuing devinfo -r. Use of the kernel debugging mechanism to fill free malloc storage with 0xdeadcode is likely to increase the likelihood of seeing the problem. >Fix: Suggested fix: Clear the r_dev field of the resource structure when the RF_ALLOCATED flag is cleared: in int_rman_release_resource() change: r->r_flags &= ~RF_ALLOCATED; return 0; to r->r_flags &= ~RF_ALLOCATED; r->r_dev = NULL; return 0; >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708100621.l7A6Ljps078622>