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]
Date:   Mon, 26 Dec 2022 08:09:10 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Xingyuan Mo <hdthky0@...il.com>
Cc:     djwong@...nel.org, linux-xfs@...r.kernel.org,
        linux-kernel@...r.kernel.org, syzkaller@...glegroups.com
Subject: Re: memory leak in xfs_init_local_fork

On Mon, Dec 26, 2022 at 5:39 AM Xingyuan Mo <hdthky0@...il.com> wrote:
>
> Hello,
>
> Recently, when using our local Syzkaller to fuzz kernel, the following bug was
> triggered.
>
> git tree: stable
> branch: linux-5.10.y
> HEAD commit: 1a9148dfd8e03835dc7617cee696dd18c0000e99
> compiler: gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
>
> I have included the C repro, the Syzkaller config file and the config file used
> to compile the kernel.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: Xingyuan Mo <hdthky0@...il.com>
>
> The bug report is as follows:
>
> BUG: memory leak

Hi Xingyuan,

Let me put it this way - there are much worse bugs in v5.10 than
a memory leak generated by a fuzzed image
and there are far easier ways to take up system memory as a privileged user.

You would have to demonstrate the severity of a bug in order to justify
the work and the risk involved with patching v5.10.

Thanks,
Amir.


> unreferenced object 0xffff888104d9b100 (size 64):
>   comm "syz-executor163", pid 258, jiffies 4294772370 (age 13.800s)
>   hex dump (first 32 bytes):
>     00 22 02 00 06 06 00 78 61 74 74 72 31 78 61 74  .".....xattr1xat
>     74 72 31 00 00 00 00 00 00 00 00 32 78 61 74 74  tr1........2xatt
>   backtrace:
>     [<00000000ed987fcc>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
>     [<00000000ed987fcc>] slab_post_alloc_hook mm/slab.h:534 [inline]
>     [<00000000ed987fcc>] slab_alloc_node mm/slub.c:2896 [inline]
>     [<00000000ed987fcc>] slab_alloc mm/slub.c:2904 [inline]
>     [<00000000ed987fcc>] __kmalloc+0x19c/0x850 mm/slub.c:3967
>     [<00000000293e3034>] kmalloc include/linux/slab.h:557 [inline]
>     [<00000000293e3034>] kmem_alloc+0x131/0x310 fs/xfs/kmem.c:21
>     [<00000000c01e339f>] xfs_init_local_fork+0xf8/0x180 fs/xfs/libxfs/xfs_inode_fork.c:52
>     [<0000000016f4ae7f>] xfs_iformat_local+0x181/0x340 fs/xfs/libxfs/xfs_inode_fork.c:91
>     [<00000000815b5848>] xfs_iformat_attr_fork+0x1a4/0x1f0 fs/xfs/libxfs/xfs_inode_fork.c:302
>     [<000000004cf4bc61>] xfs_inode_from_disk+0x592/0x5f0 fs/xfs/libxfs/xfs_inode_buf.c:268
>     [<0000000067a7ee06>] xfs_iget_cache_miss fs/xfs/xfs_icache.c:516 [inline]
>     [<0000000067a7ee06>] xfs_iget+0x7a3/0x17d0 fs/xfs/xfs_icache.c:653
>     [<000000008cff65b8>] xfs_lookup+0x123/0x260 fs/xfs/xfs_inode.c:687
>     [<000000004d7ec325>] xfs_vn_lookup+0xa8/0x110 fs/xfs/xfs_iops.c:267
>     [<00000000265d1ca5>] __lookup_hash+0xa4/0xf0 fs/namei.c:1447
>     [<0000000040f86cb0>] do_renameat2+0x37f/0x7b0 fs/namei.c:4404
>     [<00000000967d8465>] __do_sys_rename fs/namei.c:4498 [inline]
>     [<00000000967d8465>] __se_sys_rename fs/namei.c:4496 [inline]
>     [<00000000967d8465>] __x64_sys_rename+0x2c/0x40 fs/namei.c:4496
>     [<000000001f16c835>] do_syscall_64+0x35/0x50 arch/x86/entry/common.c:46
>     [<000000004c35f0dd>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
>
>
> Best Regards,
> Xingyuan Mo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ