public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Buesch <mb@bu3sch.de>
To: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Len Brown <lenb@kernel.org>,
	linux-acpi@vger.kernel.org, ibm-acpi-devel@lists.sourceforge.net,
	stable@kernel.org
Subject: Re: [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun
Date: Sun, 2 Aug 2009 11:53:06 +0200	[thread overview]
Message-ID: <200908021153.06769.mb@bu3sch.de> (raw)
In-Reply-To: <20090802015012.GA14889@khazad-dum.debian.net>

On Sunday 02 August 2009 03:50:12 Henrique de Moraes Holschuh wrote:
> > Note that it turns out this is not a real-life bug after all.
> > The VFS code checks count for signedness (high bit set) and bails
> > out if this is the case.
> > Well, it might probably be a good idea to restrict the count range to
> > something sane here anyway, so...
> 
> It is a good idea to restrict the maximum size to something sane anyway.
> 
> But the commit message needs to be fixed if there is no security hole.
> 
> Anyway, in which function and file is the VFS code that restricts the
> maximum size?
> 

Well there are two things. It happens that access_ok() on x86 does such a
check. It does _not_ do this on all arches, but as a thinkpad is x86...
And there are sanity checks in fs/read_write.c:

208 /*
209  * rw_verify_area doesn't like huge counts. We limit
210  * them to something that fits in "int" so that others
211  * won't have to do range checks all the time.
212  */
213 #define MAX_RW_COUNT (INT_MAX & PAGE_CACHE_MASK)
214 
215 int rw_verify_area(int read_write, struct file *file, loff_t *ppos, size_t count)
216 {
217         struct inode *inode;
218         loff_t pos;
219         int retval = -EINVAL;
220 
221         inode = file->f_path.dentry->d_inode;
222         if (unlikely((ssize_t) count < 0))
223                 return retval;
224         pos = *ppos;
225         if (unlikely((pos < 0) || (loff_t) (pos + count) < 0))
226                 return retval;
227 
228         if (unlikely(inode->i_flock && mandatory_lock(inode))) {
229                 retval = locks_mandatory_area(
230                         read_write == READ ? FLOCK_VERIFY_READ : FLOCK_VERIFY_WRITE,
231                         inode, file, pos, count);
232                 if (retval < 0)
233                         return retval;
234         }
235         retval = security_file_permission(file,
236                                 read_write == READ ? MAY_READ : MAY_WRITE);
237         if (retval)
238                 return retval;
239         return count > MAX_RW_COUNT ? MAX_RW_COUNT : count;
240 }

-- 
Greetings, Michael.

  parent reply	other threads:[~2009-08-02  9:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-01 15:04 [GIT PATCH] thinkpad-acpi 2.6.31-rc fixes Henrique de Moraes Holschuh
2009-08-01 15:04 ` [PATCH 1/4] thinkpad-acpi: disable broken bay and dock subdrivers Henrique de Moraes Holschuh
2009-08-02  3:39   ` Len Brown
2009-08-01 15:04 ` [PATCH 2/4] thinkpad-acpi: remove dock and bay subdrivers Henrique de Moraes Holschuh
2009-08-02  4:05   ` Len Brown
2009-08-01 15:04 ` [PATCH 3/4] thinkpad-acpi: Avoid heap buffer overrun Henrique de Moraes Holschuh
2009-08-01 15:54   ` Michael Buesch
2009-08-02  1:50     ` Henrique de Moraes Holschuh
2009-08-02  4:11       ` Len Brown
2009-08-02  9:54         ` Michael Buesch
2009-08-02  9:53       ` Michael Buesch [this message]
2009-08-01 15:04 ` [PATCH 4/4] thinkpad-acpi: fix incorrect use of TPACPI_BRGHT_MODE_ECNVRAM Henrique de Moraes Holschuh
2009-08-02  3:51   ` Len Brown

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=200908021153.06769.mb@bu3sch.de \
    --to=mb@bu3sch.de \
    --cc=hmh@hmh.eng.br \
    --cc=ibm-acpi-devel@lists.sourceforge.net \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=stable@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