From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: stable-review@kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk,
WANG Cong <amwang@redhat.com>, Eugene Teo <eteo@redhat.com>,
Roman Zippel <zippel@linux-m68k.org>,
Al Viro <viro@zeniv.linux.org.uk>, Christoph Hellwig <hch@lst.de>,
Alexey Dobriyan <adobriyan@gmail.com>,
Dave Anderson <anderson@redhat.com>
Subject: [05/18] hfs: fix a potential buffer overflow
Date: Wed, 16 Dec 2009 16:45:56 -0800 [thread overview]
Message-ID: <20091217004707.607176768@mini.kroah.org> (raw)
In-Reply-To: <20091217005306.GA6230@kroah.com>
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Amerigo Wang <amwang@redhat.com>
commit ec81aecb29668ad71f699f4e7b96ec46691895b6 upstream.
A specially-crafted Hierarchical File System (HFS) filesystem could cause
a buffer overflow to occur in a process's kernel stack during a memcpy()
call within the hfs_bnode_read() function (at fs/hfs/bnode.c:24). The
attacker can provide the source buffer and length, and the destination
buffer is a local variable of a fixed length. This local variable (passed
as "&entry" from fs/hfs/dir.c:112 and allocated on line 60) is stored in
the stack frame of hfs_bnode_read()'s caller, which is hfs_readdir().
Because the hfs_readdir() function executes upon any attempt to read a
directory on the filesystem, it gets called whenever a user attempts to
inspect any filesystem contents.
[amwang@redhat.com: modify this patch and fix coding style problems]
Signed-off-by: WANG Cong <amwang@redhat.com>
Cc: Eugene Teo <eteo@redhat.com>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Dave Anderson <anderson@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/hfs/catalog.c | 4 ++++
fs/hfs/dir.c | 11 +++++++++++
fs/hfs/super.c | 7 ++++++-
3 files changed, 21 insertions(+), 1 deletion(-)
--- a/fs/hfs/catalog.c
+++ b/fs/hfs/catalog.c
@@ -289,6 +289,10 @@ int hfs_cat_move(u32 cnid, struct inode
err = hfs_brec_find(&src_fd);
if (err)
goto out;
+ if (src_fd.entrylength > sizeof(entry) || src_fd.entrylength < 0) {
+ err = -EIO;
+ goto out;
+ }
hfs_bnode_read(src_fd.bnode, &entry, src_fd.entryoffset,
src_fd.entrylength);
--- a/fs/hfs/dir.c
+++ b/fs/hfs/dir.c
@@ -79,6 +79,11 @@ static int hfs_readdir(struct file *filp
filp->f_pos++;
/* fall through */
case 1:
+ if (fd.entrylength > sizeof(entry) || fd.entrylength < 0) {
+ err = -EIO;
+ goto out;
+ }
+
hfs_bnode_read(fd.bnode, &entry, fd.entryoffset, fd.entrylength);
if (entry.type != HFS_CDR_THD) {
printk(KERN_ERR "hfs: bad catalog folder thread\n");
@@ -109,6 +114,12 @@ static int hfs_readdir(struct file *filp
err = -EIO;
goto out;
}
+
+ if (fd.entrylength > sizeof(entry) || fd.entrylength < 0) {
+ err = -EIO;
+ goto out;
+ }
+
hfs_bnode_read(fd.bnode, &entry, fd.entryoffset, fd.entrylength);
type = entry.type;
len = hfs_mac2asc(sb, strbuf, &fd.key->cat.CName);
--- a/fs/hfs/super.c
+++ b/fs/hfs/super.c
@@ -386,8 +386,13 @@ static int hfs_fill_super(struct super_b
/* try to get the root inode */
hfs_find_init(HFS_SB(sb)->cat_tree, &fd);
res = hfs_cat_find_brec(sb, HFS_ROOT_CNID, &fd);
- if (!res)
+ if (!res) {
+ if (fd.entrylength > sizeof(rec) || fd.entrylength < 0) {
+ res = -EIO;
+ goto bail;
+ }
hfs_bnode_read(fd.bnode, &rec, fd.entryoffset, fd.entrylength);
+ }
if (res) {
hfs_find_exit(&fd);
goto bail_no_root;
next prev parent reply other threads:[~2009-12-17 0:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-17 0:53 [00/18] 2.6.27.42-stable review Greg KH
2009-12-17 0:45 ` [01/18] signal: Fix alternate signal stack check Greg KH
2009-12-17 0:45 ` [02/18] debugfs: fix create mutex racy fops and private data Greg KH
2009-12-17 0:45 ` [03/18] firewire: ohci: handle receive packets with a data length of zero Greg KH
2009-12-17 0:45 ` [04/18] fuse: reject O_DIRECT flag also in fuse_create Greg KH
2009-12-17 1:36 ` David Daney
2009-12-17 4:15 ` Greg KH
2009-12-17 0:45 ` Greg KH [this message]
2009-12-17 0:45 ` [06/18] pata_hpt{37x|3x2n}: fix timing register masks (take 2) Greg KH
2009-12-17 0:45 ` [07/18] ssb: Fix range check in sprom write Greg KH
2009-12-17 0:45 ` [08/18] V4L/DVB: Fix test in copy_reg_bits() Greg KH
2009-12-17 0:46 ` [09/18] x86, apic: Enable lapic nmi watchdog on AMD Family 11h Greg KH
2009-12-17 0:46 ` [10/18] x86: ASUS P4S800 reboot=bios quirk Greg KH
2009-12-17 0:46 ` [11/18] x86, Calgary IOMMU quirk: Find nearest matching Calgary while walking up the PCI tree Greg KH
2009-12-17 0:46 ` [12/18] x86: Fix iommu=nodac parameter handling Greg KH
2009-12-17 0:46 ` [13/18] x86: GART: pci-gart_64.c: Use correct length in strncmp Greg KH
2009-12-17 0:46 ` [14/18] [IA64] fix csum_ipv6_magic() Greg KH
2009-12-17 0:46 ` [15/18] USB: fix mos7840 problem with minor numbers Greg KH
2009-12-17 0:46 ` [16/18] backlight: lcd - Fix wrong sizeof Greg KH
2009-12-17 0:46 ` [17/18] jffs2: Fix long-standing bug with symlink garbage collection Greg KH
2009-12-17 0:46 ` [18/18] matroxfb: fix problems with display stability Greg KH
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=20091217004707.607176768@mini.kroah.org \
--to=gregkh@suse.de \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=amwang@redhat.com \
--cc=anderson@redhat.com \
--cc=eteo@redhat.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=stable-review@kernel.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zippel@linux-m68k.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
all inboxes | Powered by JetHome®