public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <len.brown@intel.com>
To: arjanv@redhat.com
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: fix off-by-one error in ioremap()
Date: 18 Sep 2003 12:03:00 -0400	[thread overview]
Message-ID: <1063900980.2674.72.camel@linux.local> (raw)
In-Reply-To: <1063872336.5026.1.camel@laptop.fenrus.com>

On Thu, 2003-09-18 at 04:05, Arjan van de Ven wrote:
> On Fri, 2003-09-12 at 10:15, Linux Kernel Mailing List wrote:
> > ChangeSet 1.1063.43.5, 2003/09/12 04:15:36-04:00, len.brown@intel.com
> > 
> > 	fix off-by-one error in ioremap()
> > 	fixes kernel crash in acpi mode: http://bugzilla.kernel.org/show_bug.cgi?id=1085
> 
> > diff -Nru a/arch/i386/mm/ioremap.c b/arch/i386/mm/ioremap.c
> > --- a/arch/i386/mm/ioremap.c	Wed Sep 17 14:07:31 2003
> > +++ b/arch/i386/mm/ioremap.c	Wed Sep 17 14:07:31 2003
> > @@ -140,7 +140,7 @@
> >  	 */
> >  	offset = phys_addr & ~PAGE_MASK;
> >  	phys_addr &= PAGE_MASK;
> > -	size = PAGE_ALIGN(last_addr) - phys_addr;
> > +	size = PAGE_ALIGN(last_addr+1) - phys_addr;
> >  
> 
> 
> A bit higher in that function is:
>                                                                                                         
>         /* Don't allow wraparound or zero size */
>         last_addr = phys_addr + size - 1;
>         if (!size || last_addr < phys_addr)
>                 return NULL;
>                                                                                                         
> 
> so why do you undo the deliberate -1 there ?

Because:

last_addr = phys_addr + size - 1
means that
size = last_addr - phys_addr + 1
not
size = last_addr - phys_addr

If you leave out this change, then a request for a page-aligned 4096+1
bytes will give you a single 4096 byte page, and the kernel will crash
when you access byte 4096+1.

As this bug has been in the kernel for years, it apparently isn't common
to access 4097-byte item starting on page boundaries;-)

However, ACPI maps tables that are left on arbitrary byte boundaries by
the BIOS.  In this case we got a table that started near the end of a
page and overflowed 1 byte into the next page -- which has the same
effect as the simpler case above.

cheers,
-Len

ps. this fix has been in 2.6 for several months -- sort of a bummer it
had to be debugged and fixed twice.




      reply	other threads:[~2003-09-18 16:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200309172107.h8HL7UBf011628@hera.kernel.org>
2003-09-18  8:05 ` fix off-by-one error in ioremap() Arjan van de Ven
2003-09-18 16:03   ` Len Brown [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=1063900980.2674.72.camel@linux.local \
    --to=len.brown@intel.com \
    --cc=arjanv@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox