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.
next prev 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