Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CANX2M5Y+98u3R9zATF_VQnxCGzmg59O1sNnTc1sH-wgWFJbLrQ@mail.gmail.com>
In-Reply-To: <CANX2M5Y+98u3R9zATF_VQnxCGzmg59O1sNnTc1sH-wgWFJbLrQ@mail.gmail.com>
From:   Dipanjan Das <mail.dipanjan.das@gmail.com>
Date:   Tue, 2 Aug 2022 23:03:27 -0700
Message-ID: <CANX2M5ZEFGToH42rW+yndG59Uebcj-Eiv21Q2ykvHj=eVjpn+w@mail.gmail.com>
Subject: Re: KASAN: slab-out-of-bounds Read in ntfs_get_ea
To:     almaz.alexandrovich@paragon-software.com, nathan@kernel.org,
        ndesaulniers@google.com, trix@redhat.com, ntfs3@lists.linux.dev,
        linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Cc:     syzkaller@googlegroups.com, fleischermarius@googlemail.com,
        its.priyanka.bose@gmail.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Jul 22, 2022 at 5:51 PM Dipanjan Das
<mail.dipanjan.das@gmail.com> wrote:
>
> Hi,
>
> We would like to report the following bug which has been found by our
> modified version of syzkaller.
>
> ======================================================
> description: KASAN: slab-out-of-bounds Read in ntfs_get_ea
> affected file: fs/ntfs3/xattr.c
> kernel version: 5.19-rc6
> kernel commit: 32346491ddf24599decca06190ebca03ff9de7f8
> git tree: upstream
> kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=cd73026ceaed1402
> crash reproducer: attached
> ======================================================

Here is our initial analysis and findings regarding this crash (when
we run the repro attached to our original report):
In `fs/ntfs3/xattr.c`, the memory size `size` allocated to hold all
the extended attributes is `60` bytes which is pointed to by `ea_all`
in `ntfs_get_ea`. `find_ea`  iterates over the `ea_all` by adding an
`offset` to current `ea` address to find a matching `ea`. The offset
is calculated either using the size of the extended attribute in
`ea->size` or using struct size of the `ea`, if `ea->size` is 0. The
loop terminates if (1) one matched extended attribute `ea` is found or
(2)  The calculated offset is greater than `size`.

In this case, at one point the calculated `offset` becomes `56` which
does not satisfy any of the terminating conditions and therefore it
still attempts to find the next `ea`. In order to do that, it
calculates the size of the current `ea`. Since current `ea->size` is
0, struct size of the current `ea` is used. During that calculation,
the field value `ea->name` is dereferenced to calculate the size
occupied by that field and the address of  `ea->name` falls beyond the
`60` byte slab range. Hence, the slab out of bound occurs.

Please let us know if this helps, or we need to dig in further.

-- 
Thanks and Regards,

Dipanjan