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] [day] [month] [year] [list]
Message-ID: <CANX2M5ZEFGToH42rW+yndG59Uebcj-Eiv21Q2ykvHj=eVjpn+w@mail.gmail.com>
Date:   Tue, 2 Aug 2022 23:03:27 -0700
From:   Dipanjan Das <mail.dipanjan.das@...il.com>
To:     almaz.alexandrovich@...agon-software.com, nathan@...nel.org,
        ndesaulniers@...gle.com, trix@...hat.com, ntfs3@...ts.linux.dev,
        linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Cc:     syzkaller@...glegroups.com, fleischermarius@...glemail.com,
        its.priyanka.bose@...il.com
Subject: Re: KASAN: slab-out-of-bounds Read in ntfs_get_ea

On Fri, Jul 22, 2022 at 5:51 PM Dipanjan Das
<mail.dipanjan.das@...il.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ