[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lsq.1456263723.781078669@decadent.org.uk>
Date: Tue, 23 Feb 2016 21:42:03 +0000
From: Ben Hutchings <ben@...adent.org.uk>
To: linux-kernel@...r.kernel.org, stable@...r.kernel.org
CC: akpm@...ux-foundation.org,
"Holger Hoffstätte"
<holger.hoffstaette@...glemail.com>,
"David Sterba" <dsterba@...e.com>, "Victor" <services@...u.com>,
"Chris Mason" <clm@...com>
Subject: [PATCH 3.2 60/67] btrfs: properly set the termination value of
ctx->pos in readdir
3.2.78-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: David Sterba <dsterba@...e.com>
commit bc4ef7592f657ae81b017207a1098817126ad4cb upstream.
The value of ctx->pos in the last readdir call is supposed to be set to
INT_MAX due to 32bit compatibility, unless 'pos' is intentially set to a
larger value, then it's LLONG_MAX.
There's a report from PaX SIZE_OVERFLOW plugin that "ctx->pos++"
overflows (https://forums.grsecurity.net/viewtopic.php?f=1&t=4284), on a
64bit arch, where the value is 0x7fffffffffffffff ie. LLONG_MAX before
the increment.
We can get to that situation like that:
* emit all regular readdir entries
* still in the same call to readdir, bump the last pos to INT_MAX
* next call to readdir will not emit any entries, but will reach the
bump code again, finds pos to be INT_MAX and sets it to LLONG_MAX
Normally this is not a problem, but if we call readdir again, we'll find
'pos' set to LLONG_MAX and the unconditional increment will overflow.
The report from Victor at
(http://thread.gmane.org/gmane.comp.file-systems.btrfs/49500) with debugging
print shows that pattern:
Overflow: e
Overflow: 7fffffff
Overflow: 7fffffffffffffff
PAX: size overflow detected in function btrfs_real_readdir
fs/btrfs/inode.c:5760 cicus.935_282 max, count: 9, decl: pos; num: 0;
context: dir_context;
CPU: 0 PID: 2630 Comm: polkitd Not tainted 4.2.3-grsec #1
Hardware name: Gigabyte Technology Co., Ltd. H81ND2H/H81ND2H, BIOS F3 08/11/2015
ffffffff81901608 0000000000000000 ffffffff819015e6 ffffc90004973d48
ffffffff81742f0f 0000000000000007 ffffffff81901608 ffffc90004973d78
ffffffff811cb706 0000000000000000 ffff8800d47359e0 ffffc90004973ed8
Call Trace:
[<ffffffff81742f0f>] dump_stack+0x4c/0x7f
[<ffffffff811cb706>] report_size_overflow+0x36/0x40
[<ffffffff812ef0bc>] btrfs_real_readdir+0x69c/0x6d0
[<ffffffff811dafc8>] iterate_dir+0xa8/0x150
[<ffffffff811e6d8d>] ? __fget_light+0x2d/0x70
[<ffffffff811dba3a>] SyS_getdents+0xba/0x1c0
Overflow: 1a
[<ffffffff811db070>] ? iterate_dir+0x150/0x150
[<ffffffff81749b69>] entry_SYSCALL_64_fastpath+0x12/0x83
The jump from 7fffffff to 7fffffffffffffff happens when new dir entries
are not yet synced and are processed from the delayed list. Then the code
could go to the bump section again even though it might not emit any new
dir entries from the delayed list.
The fix avoids entering the "bump" section again once we've finished
emitting the entries, both for synced and delayed entries.
References: https://forums.grsecurity.net/viewtopic.php?f=1&t=4284
Reported-by: Victor <services@...u.com>
Signed-off-by: David Sterba <dsterba@...e.com>
Tested-by: Holger Hoffstätte <holger.hoffstaette@...glemail.com>
Signed-off-by: Chris Mason <clm@...com>
[bwh: Backported to 3.2:
- s/ctx->pos/filp->f_pos/
- Adjust context]
Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
---
fs/btrfs/delayed-inode.c | 3 ++-
fs/btrfs/delayed-inode.h | 2 +-
fs/btrfs/inode.c | 14 +++++++++++++-
3 files changed, 16 insertions(+), 3 deletions(-)
--- a/fs/btrfs/delayed-inode.c
+++ b/fs/btrfs/delayed-inode.c
@@ -1593,7 +1593,7 @@ int btrfs_should_delete_dir_index(struct
*/
int btrfs_readdir_delayed_dir_index(struct file *filp, void *dirent,
filldir_t filldir,
- struct list_head *ins_list)
+ struct list_head *ins_list, bool *emitted)
{
struct btrfs_dir_item *di;
struct btrfs_delayed_item *curr, *next;
@@ -1637,6 +1637,7 @@ int btrfs_readdir_delayed_dir_index(stru
if (over)
return 1;
+ *emitted = true;
}
return 0;
}
--- a/fs/btrfs/delayed-inode.h
+++ b/fs/btrfs/delayed-inode.h
@@ -133,7 +133,7 @@ int btrfs_should_delete_dir_index(struct
u64 index);
int btrfs_readdir_delayed_dir_index(struct file *filp, void *dirent,
filldir_t filldir,
- struct list_head *ins_list);
+ struct list_head *ins_list, bool *emitted);
/* for init */
int __init btrfs_delayed_inode_init(void);
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4111,6 +4111,7 @@ static int btrfs_real_readdir(struct fil
char *name_ptr;
int name_len;
int is_curr = 0; /* filp->f_pos points to the current index? */
+ bool emitted;
/* FIXME, use a real flag for deciding about the key type */
if (root->fs_info->tree_root == root)
@@ -4153,6 +4154,7 @@ static int btrfs_real_readdir(struct fil
if (ret < 0)
goto err;
+ emitted = false;
while (1) {
leaf = path->nodes[0];
slot = path->slots[0];
@@ -4254,6 +4256,7 @@ skip:
if (over)
goto nopos;
+ emitted = true;
di_len = btrfs_dir_name_len(leaf, di) +
btrfs_dir_data_len(leaf, di) + sizeof(*di);
di_cur += di_len;
@@ -4267,11 +4270,20 @@ next:
if (is_curr)
filp->f_pos++;
ret = btrfs_readdir_delayed_dir_index(filp, dirent, filldir,
- &ins_list);
+ &ins_list, &emitted);
if (ret)
goto nopos;
}
+ /*
+ * If we haven't emitted any dir entry, we must not touch filp->f_pos as
+ * it was was set to the termination value in previous call. We assume
+ * that "." and ".." were emitted if we reach this point and set the
+ * termination value as well for an empty directory.
+ */
+ if (filp->f_pos > 2 && !emitted)
+ goto nopos;
+
/* Reached end of directory/root. Bump pos past the last item. */
if (key_type == BTRFS_DIR_INDEX_KEY)
/*
Powered by blists - more mailing lists