Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1269388 > unrolled thread

Endless getdents() in vfat filesystem

Started byVegard Nossum <vegard.nossum@oracle.com>
First post2015-11-14 02:30 +0100
Last post2015-11-15 14:00 +0100
Articles 9 — 4 participants

Back to article view | Back to linux.kernel

Contents

  Endless getdents() in vfat filesystem Vegard Nossum <vegard.nossum@oracle.com> - 2015-11-14 02:30 +0100
    Re: Endless getdents() in vfat filesystem Richard Weinberger <richard.weinberger@gmail.com> - 2015-11-14 11:40 +0100
      Re: Endless getdents() in vfat filesystem Vegard Nossum <vegard.nossum@oracle.com> - 2015-11-14 13:50 +0100
        Re: Endless getdents() in vfat filesystem OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> - 2015-11-14 16:00 +0100
          Re: Endless getdents() in vfat filesystem Richard Weinberger <richard@nod.at> - 2015-11-14 16:10 +0100
            Re: Endless getdents() in vfat filesystem OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> - 2015-11-14 19:20 +0100
              Re: Endless getdents() in vfat filesystem Vegard Nossum <vegard.nossum@oracle.com> - 2015-11-15 12:10 +0100
                Re: Endless getdents() in vfat filesystem Richard Weinberger <richard@nod.at> - 2015-11-15 12:30 +0100
                  Re: Endless getdents() in vfat filesystem OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> - 2015-11-15 14:00 +0100

#1269388 — Endless getdents() in vfat filesystem

FromVegard Nossum <vegard.nossum@oracle.com>
Date2015-11-14 02:30 +0100
SubjectEndless getdents() in vfat filesystem
Message-ID<quxPc-5G2-7@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

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


Vegard

[toc] | [next] | [standalone]

#1269465

FromRichard Weinberger <richard.weinberger@gmail.com>
Date2015-11-14 11:40 +0100
Message-ID<quGps-2Pe-7@gated-at.bofh.it>
In reply to#1269388

[Multipart message — attachments visible in raw view] — view raw

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?

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?

-- 
Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1269478

FromVegard Nossum <vegard.nossum@oracle.com>
Date2015-11-14 13:50 +0100
Message-ID<quIrf-42Y-5@gated-at.bofh.it>
In reply to#1269465
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,


Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269493

FromOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date2015-11-14 16:00 +0100
Message-ID<quKt4-5k2-3@gated-at.bofh.it>
In reply to#1269478
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;
 }
 
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269495

FromRichard Weinberger <richard@nod.at>
Date2015-11-14 16:10 +0100
Message-ID<quKCJ-5Cl-5@gated-at.bofh.it>
In reply to#1269493
Am 14.11.2015 um 15:28 schrieb OGAWA Hirofumi:
> 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?

Sure!

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269517

FromOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date2015-11-14 19:20 +0100
Message-ID<quNAC-7sG-19@gated-at.bofh.it>
In reply to#1269495
Richard Weinberger <richard@nod.at> writes:

>>> 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?
>
> Sure!

Attached updated patch made smaller changes, and with missed Cc: stable.

Andrew, please queue this up.

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]
Cc: stable@vger.kernel.org
Signed-off-by: Richard Weinberger <richard.weinberger@gmail.com>
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

 fs/fat/dir.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff -puN fs/fat/dir.c~fat-fake_offset-fix fs/fat/dir.c
--- linux/fs/fat/dir.c~fat-fake_offset-fix	2015-11-14 23:31:45.904700155 +0900
+++ linux-hirofumi/fs/fat/dir.c	2015-11-15 02:45:13.861256766 +0900
@@ -610,9 +610,9 @@ 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;
+			goto end_of_dir;
 		} else if (status == PARSE_INVALID)
 			goto record_end;
 		else if (status == PARSE_NOT_LONGNAME)
@@ -654,8 +654,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))
@@ -681,14 +682,19 @@ record_end:
 	fake_offset = 0;
 	ctx->pos = cpos;
 	goto get_new;
+
 end_of_dir:
-	ctx->pos = cpos;
+	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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269669

FromVegard Nossum <vegard.nossum@oracle.com>
Date2015-11-15 12:10 +0100
Message-ID<qv3m1-zv-7@gated-at.bofh.it>
In reply to#1269517
On 11/14/2015 07:19 PM, OGAWA Hirofumi wrote:
> Richard Weinberger <richard@nod.at> writes:
>
>>>> 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?
>>
>> Sure!
>
> Attached updated patch made smaller changes, and with missed Cc: stable.
>
> Andrew, please queue this up.
>
> Thanks.
>

It would be nice to have a proper patch description too. How about this?

"""
For the root directory, . and .. are faked (using dir_emit_dots()) and
ctx->pos is reset from 2 to 0.

A corrupted root directory could cause fat_get_entry() to fail, but
->iterate() (fat_readdir()) reports progress to the VFS (with ctx->pos
rewound to 0), so any following calls to ->iterate() continue to return
the same entries again and again.

The result is that userspace will never see the end of the directory,
causing e.g. 'ls' to hang in a getdents() loop.
"""

Thanks,


Vegard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269674

FromRichard Weinberger <richard@nod.at>
Date2015-11-15 12:30 +0100
Message-ID<qv3Fn-HW-3@gated-at.bofh.it>
In reply to#1269669
Am 15.11.2015 um 12:05 schrieb Vegard Nossum:
> On 11/14/2015 07:19 PM, OGAWA Hirofumi wrote:
>> Richard Weinberger <richard@nod.at> writes:
>>
>>>>> 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?
>>>
>>> Sure!
>>
>> Attached updated patch made smaller changes, and with missed Cc: stable.
>>
>> Andrew, please queue this up.
>>
>> Thanks.
>>
> 
> It would be nice to have a proper patch description too. How about this?
> 
> """
> For the root directory, . and .. are faked (using dir_emit_dots()) and
> ctx->pos is reset from 2 to 0.
> 
> A corrupted root directory could cause fat_get_entry() to fail, but
> ->iterate() (fat_readdir()) reports progress to the VFS (with ctx->pos
> rewound to 0), so any following calls to ->iterate() continue to return
> the same entries again and again.
> 
> The result is that userspace will never see the end of the directory,
> causing e.g. 'ls' to hang in a getdents() loop.
> """

Agreed. And you deserve also a Reported-and-tested-by. :-)

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1269689

FromOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date2015-11-15 14:00 +0100
Message-ID<qv54u-1vn-3@gated-at.bofh.it>
In reply to#1269674
Richard Weinberger <richard@nod.at> writes:

>> It would be nice to have a proper patch description too. How about this?
>> 
>> """
>> For the root directory, . and .. are faked (using dir_emit_dots()) and
>> ctx->pos is reset from 2 to 0.
>> 
>> A corrupted root directory could cause fat_get_entry() to fail, but
>> ->iterate() (fat_readdir()) reports progress to the VFS (with ctx->pos
>> rewound to 0), so any following calls to ->iterate() continue to return
>> the same entries again and again.
>> 
>> The result is that userspace will never see the end of the directory,
>> causing e.g. 'ls' to hang in a getdents() loop.
>> """
>
> Agreed. And you deserve also a Reported-and-tested-by. :-)

Sounds good, updated patch here.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>



[PATCH v3] fat: Fix fake_offset handling on error path

For the root directory, . and .. are faked (using dir_emit_dots()) and
ctx->pos is reset from 2 to 0.

A corrupted root directory could cause fat_get_entry() to fail, but
->iterate() (fat_readdir()) reports progress to the VFS (with ctx->pos
rewound to 0), so any following calls to ->iterate() continue to return
the same entries again and again.

The result is that userspace will never see the end of the directory,
causing e.g. 'ls' to hang in a getdents() loop.

[hirofumi@mail.parknet.co.jp: cleanup and make sure to correct fake_offset]
Cc: stable@vger.kernel.org
Reported-and-tested-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Richard Weinberger <richard.weinberger@gmail.com>
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

 fs/fat/dir.c |   16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff -puN fs/fat/dir.c~fat-fake_offset-fix fs/fat/dir.c
--- linux/fs/fat/dir.c~fat-fake_offset-fix	2015-11-14 23:31:45.904700155 +0900
+++ linux-hirofumi/fs/fat/dir.c	2015-11-15 02:45:13.861256766 +0900
@@ -610,9 +610,9 @@ 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;
+			goto end_of_dir;
 		} else if (status == PARSE_INVALID)
 			goto record_end;
 		else if (status == PARSE_NOT_LONGNAME)
@@ -654,8 +654,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))
@@ -681,14 +682,19 @@ record_end:
 	fake_offset = 0;
 	ctx->pos = cpos;
 	goto get_new;
+
 end_of_dir:
-	ctx->pos = cpos;
+	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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web