linux-kernel - Re: [PATCH] ntfs: change check order in ntfs_attr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1636796c-c85e-7f47-e96f-e074fee3c7d3@huawei.com>
Date:   Sat, 27 Aug 2022 09:28:51 +0800
From:   "chenxiaosong (A)" <chenxiaosong2@...wei.com>
To:     Hawkins Jiawei <yin31149@...il.com>,
        <syzbot+5f8dcabe4a3b2c51c607@...kaller.appspotmail.com>,
        Anton Altaparmakov <anton@...era.com>
CC:     <akpm@...ux-foundation.org>, <linux-kernel@...r.kernel.org>,
        <linux-ntfs-dev@...ts.sourceforge.net>,
        <syzkaller-bugs@...glegroups.com>
Subject: Re: [PATCH] ntfs: change check order in ntfs_attr_find

在 2022/8/26 20:27, Hawkins Jiawei 写道:
> syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> 
> Looks like it is improper check order that causes this bug.
> 
> Signed-off-by: Hawkins Jiawei <yin31149@...il.com>
> ---
>   fs/ntfs/attrib.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ntfs/attrib.c b/fs/ntfs/attrib.c
> index 52615e6090e1..6480cd2d371d 100644
> --- a/fs/ntfs/attrib.c
> +++ b/fs/ntfs/attrib.c
> @@ -594,10 +594,11 @@ static int ntfs_attr_find(const ATTR_TYPE type, const ntfschar *name,
>   	for (;;	a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))) {
>   		u8 *mrec_end = (u8 *)ctx->mrec +
>   		               le32_to_cpu(ctx->mrec->bytes_allocated);
> +		if ((u8*)a < (u8*)ctx->mrec || (u8*)a > mrec_end)
> +			break;
>   		u8 *name_end = (u8 *)a + le16_to_cpu(a->name_offset) +
>   			       a->name_length * sizeof(ntfschar);
> -		if ((u8*)a < (u8*)ctx->mrec || (u8*)a > mrec_end ||
> -		    name_end > mrec_end)
> +		if (name_end > mrec_end)
>   			break;
>   		ctx->attr = a;
>   		if (unlikely(le32_to_cpu(a->type) > le32_to_cpu(type) ||
> 

The reason is that a->length is 0, it will occur uaf when deref any 
field of ATTR_RECORD.

It seems that changing check order will not fix root cause, if the 
condition "if ((u8*)a < (u8*)ctx->mrec || (u8*)a > mrec_end)" is false, 
uaf will still occur.

Do you have any thoughts on this ?