From owner-svn-src-all@FreeBSD.ORG Thu Nov 20 12:00:33 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 07057E1F; Thu, 20 Nov 2014 12:00:33 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id ECC9A2639; Thu, 20 Nov 2014 12:00:29 +0000 (UTC) Message-ID: <546DD7BB.90004@FreeBSD.org> Date: Thu, 20 Nov 2014 14:59:55 +0300 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bruce Evans , Warner Losh Subject: Re: svn commit: r274721 - head/sys/geom/part References: <201411191855.sAJItShA048381@svn.freebsd.org> <20141120150210.P976@besplex.bde.org> In-Reply-To: <20141120150210.P976@besplex.bde.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 12:00:33 -0000 On 20.11.2014 07:38, Bruce Evans wrote: > On Wed, 19 Nov 2014, Warner Losh wrote: > >> Log: >> The number of BSD partitions is variable. Return the proper number >> (which is in basetable->gpt_entries). >> >> Submitted by: ae@ >> >> Modified: >> head/sys/geom/part/g_part_bsd.c >> >> Modified: head/sys/geom/part/g_part_bsd.c >> ============================================================================== >> >> --- head/sys/geom/part/g_part_bsd.c Wed Nov 19 18:19:21 2014 >> (r274720) >> +++ head/sys/geom/part/g_part_bsd.c Wed Nov 19 18:55:27 2014 >> (r274721) >> @@ -521,7 +521,7 @@ g_part_bsd_ioctl(struct g_part_table *ba >> >> table = (struct g_part_bsd_table *)basetable; >> p = table->bbarea + pp->sectorsize; >> - return (bsd_disklabel_le_dec(p, data, MAXPARTITIONS)); >> + return (bsd_disklabel_le_dec(p, data, basetable->gpt_entries)); >> } >> default: >> return (ENOIOCTL); > > How can this work? I think you are implementing DIOCGDINFO. This returns > a struct disklabel, which is limited by binary compatibility to the > historical number of partitions (8). So this ioctl just cannot support > more than 8 partitions. The best that could happen is for > bsd_disklabel_le_dec() to return an error in this case. But it actually > does essentially the reverse -- you pass it the maximum supported by the > ioctl, and it returns an error if the actual number is larger. So > MAXPARTITIONS was correct if this is to implement DIOCGDINFO. Yes, you are right. The size is hardcoded in the DIOCGDINFO and this can lead to out of the bound access in the application that uses it. Sorry for wrong suggestion. -- WBR, Andrey V. Elsukov