we should check for valid STANDARD_INFORMATION attribute offset and
length before trying to access it
Reported-and-tested-by: [email protected]
Signed-off-by: Rustam Kovhaev <[email protected]>
Acked-by: Anton Altaparmakov <[email protected]>
Link: https://syzkaller.appspot.com/bug?extid=c584225dabdea2f71969
---
fs/ntfs/inode.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index f7e4cbc26eaf..be4ff9386ec0 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -629,6 +629,12 @@ static int ntfs_read_locked_inode(struct inode *vi)
}
a = ctx->attr;
/* Get the standard information attribute value. */
+ if ((u8 *)a + le16_to_cpu(a->data.resident.value_offset)
+ + le32_to_cpu(a->data.resident.value_length) >
+ (u8 *)ctx->mrec + vol->mft_record_size) {
+ ntfs_error(vi->i_sb, "Corrupt standard information attribute in inode.");
+ goto unm_err_out;
+ }
si = (STANDARD_INFORMATION*)((u8*)a +
le16_to_cpu(a->data.resident.value_offset));
--
2.30.0
Hi Andrew,
Can you please push this one upstream? Thanks a lot in advance!
Best regards,
Anton
> On 17 Feb 2021, at 15:59, Rustam Kovhaev <[email protected]> wrote:
>
> we should check for valid STANDARD_INFORMATION attribute offset and
> length before trying to access it
>
> Reported-and-tested-by: [email protected]
> Signed-off-by: Rustam Kovhaev <[email protected]>
> Acked-by: Anton Altaparmakov <[email protected]>
> Link: https://syzkaller.appspot.com/bug?extid=c584225dabdea2f71969
> ---
> fs/ntfs/inode.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
> index f7e4cbc26eaf..be4ff9386ec0 100644
> --- a/fs/ntfs/inode.c
> +++ b/fs/ntfs/inode.c
> @@ -629,6 +629,12 @@ static int ntfs_read_locked_inode(struct inode *vi)
> }
> a = ctx->attr;
> /* Get the standard information attribute value. */
> + if ((u8 *)a + le16_to_cpu(a->data.resident.value_offset)
> + + le32_to_cpu(a->data.resident.value_length) >
> + (u8 *)ctx->mrec + vol->mft_record_size) {
> + ntfs_error(vi->i_sb, "Corrupt standard information attribute in inode.");
> + goto unm_err_out;
> + }
> si = (STANDARD_INFORMATION*)((u8*)a +
> le16_to_cpu(a->data.resident.value_offset));
>
> --
> 2.30.0
>
--
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer
On Fri, 19 Feb 2021 01:54:30 +0000 Anton Altaparmakov <[email protected]> wrote:
> Hi Andrew,
>
> Can you please push this one upstream? Thanks a lot in advance!
The changelog is a bit brief...
>
> > On 17 Feb 2021, at 15:59, Rustam Kovhaev <[email protected]> wrote:
> >
> > we should check for valid STANDARD_INFORMATION attribute offset and
> > length before trying to access it
It's a kernel a crash and I assume it results from mounting a corrupted
filesystem?
I think it's worth a cc:stable, yes?
Hi Andrew,
Sorry for the delay in replying.
> On 19 Feb 2021, at 18:49, Andrew Morton <[email protected]> wrote:
>
> On Fri, 19 Feb 2021 01:54:30 +0000 Anton Altaparmakov <[email protected]> wrote:
>
>> Hi Andrew,
>>
>> Can you please push this one upstream? Thanks a lot in advance!
>
> The changelog is a bit brief...
Yes you are right it is a bit brief. I guess I thought the syzkaller link was sufficient... Rustam would you like to resubmit with an improved/extended description?
>>> On 17 Feb 2021, at 15:59, Rustam Kovhaev <[email protected]> wrote:
>>>
>>> we should check for valid STANDARD_INFORMATION attribute offset and
>>> length before trying to access it
>
> It's a kernel a crash and I assume it results from mounting a corrupted
> filesystem?
>
> I think it's worth a cc:stable, yes?
The problem is an invalid memory access due to corrupt on-disk metadata.
The issue with NTFS is that it is effectively a relational database so it is full of "struct X, field A" contains offset to "struct Y" so you get: "&struct Y = &struct X + X->A" and if the value of A is corrupt on-disk then your Y pointer is now pointing to random memory.
The patch fixes one such place by validating that Y pointer is within bounds of the structure/buffer it is in.
So I guess this could be worth a cc:stable? I guess we can add it and Greg / others can decide whether to put it into stable or not... Rustam when resubmitting with better description, please also add the "Cc: [email protected]" line together with the "Signed-off-by", etc lines (note no need to actually put this in CC: field of the email iteslf).
Best regards,
Anton
--
Anton Altaparmakov <anton at tuxera.com> (replace at with @)
Lead in File System Development, Tuxera Inc., http://www.tuxera.com/
Linux NTFS maintainer
On Mon, Feb 22, 2021 at 02:18:50PM +0000, Anton Altaparmakov wrote:
> Rustam would you like to resubmit with an improved/extended description?
sure thing, no problem!
> when resubmitting with better description, please also add the
> "Cc: [email protected]" line together with the "Signed-off-by",
> etc lines (note no need to actually put this in CC: field of the email
> iteslf).
i will do that, thanks Andrew and Anton