public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Endless getdents() in vfat filesystem
Date: Sat, 14 Nov 2015 23:28:36 +0900	[thread overview]
Message-ID: <87r3js3baj.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <56472C2F.5090207@oracle.com> (Vegard Nossum's message of "Sat, 14 Nov 2015 13:42:23 +0100")

Vegard Nossum <vegard.nossum@oracle.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@oracle.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@mail.parknet.co.jp>


[PATCH] fat: Fix fake_offset handling on error path

[hirofumi@mail.parknet.co.jp: cleanup and make sure to correct fake_offset]
Signed-off-by: Richard Weinberger <richard.weinberger@gmail.com>
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.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;
 }
 
_

  reply	other threads:[~2015-11-14 14:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-14  1:19 Endless getdents() in vfat filesystem Vegard Nossum
2015-11-14 10:32 ` Richard Weinberger
2015-11-14 12:42   ` Vegard Nossum
2015-11-14 14:28     ` OGAWA Hirofumi [this message]
2015-11-14 15:06       ` Richard Weinberger
2015-11-14 18:19         ` OGAWA Hirofumi
2015-11-15 11:05           ` Vegard Nossum
2015-11-15 11:24             ` Richard Weinberger
2015-11-15 12:59               ` OGAWA Hirofumi

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=87r3js3baj.fsf@mail.parknet.co.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.weinberger@gmail.com \
    --cc=vegard.nossum@oracle.com \
    /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