WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 9/9] xen/p2m/debugfs: Fix potential pointer excep

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 9/9] xen/p2m/debugfs: Fix potential pointer exception.
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Fri, 30 Sep 2011 09:18:17 +0100
Cc: Dan, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, Carpenter <error27@xxxxxxxxx>
Delivery-date: Fri, 30 Sep 2011 01:18:47 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1317325971-21603-10-git-send-email-konrad.wilk@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <1317325971-21603-1-git-send-email-konrad.wilk@xxxxxxxxxx> <1317325971-21603-10-git-send-email-konrad.wilk@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-09-29 at 20:52 +0100, Konrad Rzeszutek Wilk wrote:
> We could be referencing the last + 1 element of level_name[]
> array which would cause a pointer exception.

If we end up accessing it does that not mean something, i.e. should it
not be a real string here and not NULL? Otherwise isn't it a bug in the
lookup code that we end up looking there?

I think this lookup correspond to the initialisation of lvl=4 and
falling through the subsequent list of checks without matching one. In
which case I think level_name[4] should be "unknown" or even "error".

I don't think you can hit type_name[4] in the same way, type and
prev_type are always one of the TYPE_* defines, which have values 0..3
inclusive. You could make this more obvious and defend against future
changes breaking this with:
        ... type_name[] = {
                [TYPE_IDENTITY] = "identity",
                [TYPE_MISSING] = "missing"
                ...
        };

Ian.

> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> ---
>  arch/x86/xen/p2m.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/p2m.c b/arch/x86/xen/p2m.c
> index 58efeb9..bc4cf0a 100644
> --- a/arch/x86/xen/p2m.c
> +++ b/arch/x86/xen/p2m.c
> @@ -786,9 +786,9 @@ EXPORT_SYMBOL_GPL(m2p_find_override_pfn);
>  int p2m_dump_show(struct seq_file *m, void *v)
>  {
>       static const char * const level_name[] = { "top", "middle",
> -                                             "entry", "abnormal" };
> +                                             "entry", "abnormal", NULL};
>       static const char * const type_name[] = { "identity", "missing",
> -                                             "pfn", "abnormal"};
> +                                             "pfn", "abnormal", NULL};
>  #define TYPE_IDENTITY 0
>  #define TYPE_MISSING 1
>  #define TYPE_PFN 2



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>