All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anton Altaparmakov <anton@tuxera.com>
To: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Cc: "linux-ntfs-dev@lists.sourceforge.net" 
	<linux-ntfs-dev@lists.sourceforge.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"skhan@linuxfoundation.org" <skhan@linuxfoundation.org>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"linux-kernel-mentees@lists.linuxfoundation.org" 
	<linux-kernel-mentees@lists.linuxfoundation.org>,
	"syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com" 
	<syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com>
Subject: Re: [PATCH] ntfs: Fix validity check for file name attribute
Date: Mon, 28 Jun 2021 09:22:53 +0000	[thread overview]
Message-ID: <A2D2BB3D-8C89-40D7-B0CF-F1D2B5176152@tuxera.com> (raw)
In-Reply-To: <ea63e5af-6ac4-08fe-4261-904d55392b10@gmail.com>

Hi,

Thanks for the patch!  Have asked Andrew to merge it.

Best regards,

	Anton

> On 28 Jun 2021, at 03:45, Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> wrote:
> 
> On 14/6/21 1:05 pm, Desmond Cheong Zhi Xi wrote:
>> When checking the file name attribute, we want to ensure that it fits
>> within the bounds of ATTR_RECORD. To do this, we should check
>> that (attr record + file name offset + file name length) < (attr
>> record + attr record length).
>> However, the original check did not include the file name offset in
>> the calculation. This means that corrupted on-disk metadata might not
>> caught by the incorrect file name check, and lead to an invalid memory
>> access.
>> An example can be seen in the crash report of a memory corruption
>> error found by Syzbot:
>> https://syzkaller.appspot.com/bug?id=a1a1e379b225812688566745c3e2f7242bffc246
>> Adding the file name offset to the validity check fixes this error and
>> passes the Syzbot reproducer test.
>> Reported-by: syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com
>> Tested-by: syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com
>> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
>> ---
>>  fs/ntfs/inode.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
>> index f5c058b3192c..4474adb393ca 100644
>> --- a/fs/ntfs/inode.c
>> +++ b/fs/ntfs/inode.c
>> @@ -477,7 +477,7 @@ static int ntfs_is_extended_system_file(ntfs_attr_search_ctx *ctx)
>>  		}
>>  		file_name_attr = (FILE_NAME_ATTR*)((u8*)attr +
>>  				le16_to_cpu(attr->data.resident.value_offset));
>> -		p2 = (u8*)attr + le32_to_cpu(attr->data.resident.value_length);
>> +		p2 = (u8 *)file_name_attr + le32_to_cpu(attr->data.resident.value_length);
>>  		if (p2 < (u8*)attr || p2 > p)
>>  			goto err_corrupt_attr;
>>  		/* This attribute is ok, but is it in the $Extend directory? */
> 
> Hi Anton,
> 
> Any chance to review this patch?
> 
> Best wishes,
> Desmond


-- 
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer


WARNING: multiple messages have this Message-ID (diff)
From: Anton Altaparmakov <anton@tuxera.com>
To: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Cc: "linux-ntfs-dev@lists.sourceforge.net"
	<linux-ntfs-dev@lists.sourceforge.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com"
	<syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com>,
	"linux-kernel-mentees@lists.linuxfoundation.org"
	<linux-kernel-mentees@lists.linuxfoundation.org>
Subject: Re: [PATCH] ntfs: Fix validity check for file name attribute
Date: Mon, 28 Jun 2021 09:22:53 +0000	[thread overview]
Message-ID: <A2D2BB3D-8C89-40D7-B0CF-F1D2B5176152@tuxera.com> (raw)
In-Reply-To: <ea63e5af-6ac4-08fe-4261-904d55392b10@gmail.com>

Hi,

Thanks for the patch!  Have asked Andrew to merge it.

Best regards,

	Anton

> On 28 Jun 2021, at 03:45, Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> wrote:
> 
> On 14/6/21 1:05 pm, Desmond Cheong Zhi Xi wrote:
>> When checking the file name attribute, we want to ensure that it fits
>> within the bounds of ATTR_RECORD. To do this, we should check
>> that (attr record + file name offset + file name length) < (attr
>> record + attr record length).
>> However, the original check did not include the file name offset in
>> the calculation. This means that corrupted on-disk metadata might not
>> caught by the incorrect file name check, and lead to an invalid memory
>> access.
>> An example can be seen in the crash report of a memory corruption
>> error found by Syzbot:
>> https://syzkaller.appspot.com/bug?id=a1a1e379b225812688566745c3e2f7242bffc246
>> Adding the file name offset to the validity check fixes this error and
>> passes the Syzbot reproducer test.
>> Reported-by: syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com
>> Tested-by: syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.com
>> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
>> ---
>>  fs/ntfs/inode.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
>> index f5c058b3192c..4474adb393ca 100644
>> --- a/fs/ntfs/inode.c
>> +++ b/fs/ntfs/inode.c
>> @@ -477,7 +477,7 @@ static int ntfs_is_extended_system_file(ntfs_attr_search_ctx *ctx)
>>  		}
>>  		file_name_attr = (FILE_NAME_ATTR*)((u8*)attr +
>>  				le16_to_cpu(attr->data.resident.value_offset));
>> -		p2 = (u8*)attr + le32_to_cpu(attr->data.resident.value_length);
>> +		p2 = (u8 *)file_name_attr + le32_to_cpu(attr->data.resident.value_length);
>>  		if (p2 < (u8*)attr || p2 > p)
>>  			goto err_corrupt_attr;
>>  		/* This attribute is ok, but is it in the $Extend directory? */
> 
> Hi Anton,
> 
> Any chance to review this patch?
> 
> Best wishes,
> Desmond


-- 
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer

_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

  reply	other threads:[~2021-06-28  9:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-14  5:05 [PATCH] ntfs: Fix validity check for file name attribute Desmond Cheong Zhi Xi
2021-06-14  5:05 ` Desmond Cheong Zhi Xi
2021-06-28  2:45 ` Desmond Cheong Zhi Xi
2021-06-28  2:45   ` Desmond Cheong Zhi Xi
2021-06-28  9:22   ` Anton Altaparmakov [this message]
2021-06-28  9:22     ` Anton Altaparmakov
2021-06-28  9:22 ` Anton Altaparmakov
2021-06-28  9:22   ` Anton Altaparmakov
2021-07-29  8:31 ` Rolf Eike Beer
2021-07-29  8:31   ` Rolf Eike Beer
2021-07-29 11:56   ` Desmond Cheong Zhi Xi
2021-07-29 11:56     ` Desmond Cheong Zhi Xi

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=A2D2BB3D-8C89-40D7-B0CF-F1D2B5176152@tuxera.com \
    --to=anton@tuxera.com \
    --cc=desmondcheongzx@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-ntfs-dev@lists.sourceforge.net \
    --cc=skhan@linuxfoundation.org \
    --cc=syzbot+213ac8bb98f7f4420840@syzkaller.appspotmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.