[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r3js3baj.fsf@mail.parknet.co.jp>
Date: Sat, 14 Nov 2015 23:28:36 +0900
From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To: Richard Weinberger <richard.weinberger@...il.com>
Cc: Vegard Nossum <vegard.nossum@...cle.com>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Endless getdents() in vfat filesystem
Vegard Nossum <vegard.nossum@...cle.com> writes:
> On 11/14/2015 11:32 AM, Richard Weinberger wrote:
>> On Sat, Nov 14, 2015 at 2:19 AM, Vegard Nossum <vegard.nossum@...cle.com> wrote:
>>> Hi,
>>>
>>> Using the attached disk image I observe that getdents() never returns
>>> the end of the directory, i.e. mounting the disk image on a loopback
>>> device and running 'ls' under strace shows an endless stream of:
>>>
>>> getdents(3, /* 2 entries */, 32768) = 48
>>> getdents(3, /* 2 entries */, 32768) = 48
>>> getdents(3, /* 2 entries */, 32768) = 48
>>> ...
>>
>> Please more details. Is this image hand crafted?
>> If not, how has it been created? Is is supposed to work?
>
> It was created by fuzzing, it is not supposed to work per se.
>
>> From a quick look it seems as the root directory is bad but we report
>> progress in ->iterate.
>> ctx->pos is 2, we set it back to 0, because of the faked dot entries.
>> but fat_get_entry() did not make any progress and we report 0 back to VFS.
>> So, VFS sees progress and the game continues.
>>
>> Does the attached patch help?
>
> Yes, it does fixes the problem here, but I can't really comment on the
> correctness of the patch.
>
> Thanks for the quick reponse,
I made cleanup and made sure fake_offset is corrected.
Richard, Signed-off-by was missed in your patch, so I added. Can you
agree to Signed-off-by?
Thanks.
--
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
[PATCH] fat: Fix fake_offset handling on error path
[hirofumi@...l.parknet.co.jp: cleanup and make sure to correct fake_offset]
Signed-off-by: Richard Weinberger <richard.weinberger@...il.com>
Signed-off-by: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
---
fs/fat/dir.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff -puN fs/fat/dir.c~fat-fake_offset-fix fs/fat/dir.c
--- linux-tux3/fs/fat/dir.c~fat-fake_offset-fix 2015-11-14 21:53:21.722269967 +0900
+++ linux-tux3-hirofumi/fs/fat/dir.c 2015-11-14 23:03:16.740608521 +0900
@@ -559,7 +559,7 @@ static int __fat_readdir(struct inode *i
{
struct super_block *sb = inode->i_sb;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
- struct buffer_head *bh;
+ struct buffer_head *bh = NULL;
struct msdos_dir_entry *de;
unsigned char nr_slots;
wchar_t *unicode = NULL;
@@ -588,10 +588,9 @@ static int __fat_readdir(struct inode *i
goto out;
}
- bh = NULL;
get_new:
if (fat_get_entry(inode, &cpos, &bh, &de) == -1)
- goto end_of_dir;
+ goto out;
parse_record:
nr_slots = 0;
/*
@@ -614,7 +613,7 @@ parse_record:
int status = fat_parse_long(inode, &cpos, &bh, &de,
&unicode, &nr_slots);
if (status < 0) {
- ctx->pos = cpos;
+ bh = NULL;
ret = status;
goto out;
} else if (status == PARSE_INVALID)
@@ -622,7 +621,7 @@ parse_record:
else if (status == PARSE_NOT_LONGNAME)
goto parse_record;
else if (status == PARSE_EOF)
- goto end_of_dir;
+ goto out;
if (nr_slots) {
void *longname = unicode + FAT_MAX_UNI_CHARS;
@@ -658,8 +657,9 @@ parse_record:
fill_len = short_len;
start_filldir:
- if (!fake_offset)
- ctx->pos = cpos - (nr_slots + 1) * sizeof(struct msdos_dir_entry);
+ ctx->pos = cpos - (nr_slots + 1) * sizeof(struct msdos_dir_entry);
+ if (fake_offset && ctx->pos < 2)
+ ctx->pos = 2;
if (!memcmp(de->name, MSDOS_DOT, MSDOS_NAME)) {
if (!dir_emit_dot(file, ctx))
@@ -685,14 +685,19 @@ record_end:
fake_offset = 0;
ctx->pos = cpos;
goto get_new;
-end_of_dir:
- ctx->pos = cpos;
+
+out:
+ if (fake_offset && cpos < 2)
+ ctx->pos = 2;
+ else
+ ctx->pos = cpos;
fill_failed:
brelse(bh);
if (unicode)
__putname(unicode);
-out:
+
mutex_unlock(&sbi->s_lock);
+
return ret;
}
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists