All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gary Hade <garyhade@us.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <Yinghai.Lu@Sun.COM>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	Gary Hade <garyhade@us.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-acpi@vger.kernel.org
Subject: Re: [PATCH] x86: check boundary in count/setup_resource called by get_current_resources
Date: Thu, 1 Nov 2007 11:45:55 -0700	[thread overview]
Message-ID: <20071101184555.GB5955@us.ibm.com> (raw)
In-Reply-To: <20071101013239.992840bd.akpm@linux-foundation.org>

On Thu, Nov 01, 2007 at 01:32:39AM -0700, Andrew Morton wrote:
> On Thu, 01 Nov 2007 01:20:29 -0700 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote:
> 
> > [PATCH] x86: check boundary in count/setup_resource called by get_current_resources
> > 
> > need to check info->res_num less than PCI_BUS_NUM_RESOURCES, so
> > info->bus->resource[info->res_num] = res will not beyond of bus resource array
> > when acpi resutrn too many resource entries.
> > 
> 
> Isn't this a bit of a problem?  It sounds like PCI_BUS_NUM_RESOURCES is to
> small for that system?  If so, some sort of dynamic allocation might be
> needed.

I should have considered the possible resource array overrun
when I created these functions.  I had assumed (apparently
incorrectly) that the old PCI_BUS_NUM_RESOURCES value of 4
was based on a spec defined limit on the maximum number of 
resources that _CRS can return.

I recently noticed the potential overrun myself while backporting
the code to kernel source where PCI_BUS_NUM_RESOURCES was initially
defined as 4.  This happened on a system where the _CRS associated
with one of the root bridges returned 5 resources with the 5th causing
a write beyond the end of the array.  Increasing PCI_BUS_NUM_RESOURCES
to the current value of 8 eliminated the overrun that I experienced 
but after discovering that there is apparently no limit on the
number of resources that _CRS can return I had intended to post
a change similar to what Yinghai Lu is proposing.

With the current PCI_BUS_NUM_RESOURCES value, _CRS can return 
up to 8 resources before the pci_bus resource array is totally
saturated but it should be noted that if a transparent bridge
is present below the root bridge it's child bus will only see
the first 5 resources.

The current fixed pci_bus resource array size of 8 is adequate 
(for storing _CRS returned resource and visibility across
transparent bridges) on those systems that I work on but without
a bound on the number of resources returned by _CRS some sort
of dynamic allocation certainly makes sense.

Note that exposure to this issue is currently limited to those
that use the 'pci=use_crs' kernel option. 

Gary

-- 
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503  IBM T/L: 775-4503
garyhade@us.ibm.com
http://www.ibm.com/linux/ltc


      parent reply	other threads:[~2007-11-01 19:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-01  8:20 [PATCH] x86: check boundary in count/setup_resource called by get_current_resources Yinghai Lu
2007-11-01  8:32 ` Andrew Morton
2007-11-01 18:06   ` Yinghai Lu
2007-11-01 20:10     ` Gary Hade
2007-11-01 18:45   ` Gary Hade [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071101184555.GB5955@us.ibm.com \
    --to=garyhade@us.ibm.com \
    --cc=Yinghai.Lu@Sun.COM \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@suse.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.