[syzbot] memory leak in xas_create

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
kernel config: https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a785d0...@syzkaller.appspotmail.com

2022/07/05 05:22:17 executed programs: 828
2022/07/05 05:22:23 executed programs: 846
2022/07/05 05:22:30 executed programs: 866
2022/07/05 05:22:37 executed programs: 875
BUG: memory leak
unreferenced object 0xffff888113662480 (size 576):
comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
hex dump (first 32 bytes):
06 15 08 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
58 08 46 1d 81 88 ff ff 98 24 66 13 81 88 ff ff X.F......$f.....
backtrace:
[<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
[<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
[<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
[<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
[<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
[<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
[<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
[<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
[<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
[<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

BUG: memory leak
unreferenced object 0xffff8881136e2900 (size 576):
comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
hex dump (first 32 bytes):
00 07 00 00 00 00 00 00 80 24 66 13 81 88 ff ff .........$f.....
58 08 46 1d 81 88 ff ff 18 29 6e 13 81 88 ff ff X.F......)n.....
backtrace:
[<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
[<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
[<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
[<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
[<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
[<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
[<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
[<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
[<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
[<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

BUG: memory leak
unreferenced object 0xffff8881136e0480 (size 576):
comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
hex dump (first 32 bytes):
00 06 00 00 00 00 00 00 80 24 66 13 81 88 ff ff .........$f.....
58 08 46 1d 81 88 ff ff 98 04 6e 13 81 88 ff ff X.F.......n.....
backtrace:
[<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
[<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
[<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
[<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
[<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
[<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
[<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
[<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
[<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
[<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

BUG: memory leak
unreferenced object 0xffff8881136de900 (size 576):
comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
hex dump (first 32 bytes):
00 05 00 00 00 00 00 00 80 24 66 13 81 88 ff ff .........$f.....
58 08 46 1d 81 88 ff ff 18 e9 6d 13 81 88 ff ff X.F.......m.....
backtrace:
[<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
[<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
[<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
[<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
[<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
[<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
[<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
[<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
[<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
[<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

BUG: memory leak
unreferenced object 0xffff88811371b6c0 (size 576):
comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
hex dump (first 32 bytes):
00 04 00 00 00 00 00 00 80 24 66 13 81 88 ff ff .........$f.....
58 08 46 1d 81 88 ff ff d8 b6 71 13 81 88 ff ff X.F.......q.....
backtrace:
[<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
[<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
[<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
[<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
[<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
[<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
[<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
[<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
[<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
[<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

BUG: memory leak
unreferenced object 0xffff888113666d80 (size 576):
comm "khugepaged", pid 32, jiffies 4295002751 (age 22.940s)
hex dump (first 32 bytes):
00 03 00 00 00 00 00 00 80 24 66 13 81 88 ff ff .........$f.....
58 08 46 1d 81 88 ff ff 98 6d 66 13 81 88 ff ff X.F......mf.....
backtrace:
[<ffffffff824aa006>] xas_alloc+0xf6/0x120 lib/xarray.c:377
[<ffffffff824acc55>] xas_create+0x395/0x820 lib/xarray.c:679
[<ffffffff824ad180>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
[<ffffffff815957f3>] collapse_file+0x283/0x2870 mm/khugepaged.c:1670
[<ffffffff8159b52c>] khugepaged_scan_file mm/khugepaged.c:2072 [inline]
[<ffffffff8159b52c>] khugepaged_scan_mm_slot mm/khugepaged.c:2167 [inline]
[<ffffffff8159b52c>] khugepaged_do_scan mm/khugepaged.c:2251 [inline]
[<ffffffff8159b52c>] khugepaged+0x227c/0x43a0 mm/khugepaged.c:2296
[<ffffffff8127b8b5>] kthread+0x125/0x160 kernel/kthread.c:376
[<ffffffff8100222f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302



---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to create VM pool: failed to create GCE image: create image operation failed: &{Code:PERMISSIONS_ERROR Location: Message:Required 'read' permission for 'disks/ci-upstream-gce-leak-test-job-test-job-image.tar.gz' ForceSendFields:[] NullFields:[]}.

syzkaller build log:
go env (err=<nil>)
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/syzkaller/.cache/go-build"
GOENV="/syzkaller/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/syzkaller/jobs/linux/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/syzkaller/jobs/linux/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/syzkaller/jobs/linux/gopath/src/github.com/google/syzkaller/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3438461053=/tmp/go-build -gno-record-gcc-switches"

git status (err=<nil>)
HEAD detached at bff65f44b
nothing to commit, working tree clean


go list -f '{{.Stale}}' ./sys/syz-sysgen | grep -q false || go install ./sys/syz-sysgen
make .descriptions
bin/syz-sysgen
touch .descriptions
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=bff65f44b47bd73f56c3d6a5c3899de5f5775136 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20220704-135716'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-fuzzer github.com/google/syzkaller/syz-fuzzer
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=bff65f44b47bd73f56c3d6a5c3899de5f5775136 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20220704-135716'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-execprog github.com/google/syzkaller/tools/syz-execprog
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=bff65f44b47bd73f56c3d6a5c3899de5f5775136 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20220704-135716'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-stress github.com/google/syzkaller/tools/syz-stress
mkdir -p ./bin/linux_amd64
gcc -o ./bin/linux_amd64/syz-executor executor/executor.cc \
-m64 -O2 -pthread -Wall -Werror -Wparentheses -Wunused-const-variable -Wframe-larger-than=16384 -Wno-stringop-overflow -Wno-array-bounds -Wno-format-overflow -static-pie -fpermissive -w -DGOOS_linux=1 -DGOARCH_amd64=1 \
-DHOSTGOOS_linux=1 -DGIT_REVISION=\"bff65f44b47bd73f56c3d6a5c3899de5f5775136\"



Tested on:

commit: 952c53cd Merge tag 'dmaengine-fix-5.19' of git://git.k..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

kernel config: https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

Note: no patches were applied.

[Dmitry Vyukov]

On Sun, 10 Jul 2022 at 23:22, syzbot
<syzbot+a785d0...@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot tried to test the proposed patch but the build/boot failed:
>
> failed to create VM pool: failed to create GCE image: create image operation failed: &{Code:PERMISSIONS_ERROR Location: Message:Required 'read' permission for 'disks/ci-upstream-gce-leak-test-job-test-job-image.tar.gz' ForceSendFields:[] NullFields:[]}.

+syzkaller mailing list

This looks like GCS bug, already happened in the past:
https://groups.google.com/g/syzkaller-bugs/search?q=%22create%20image%20operation%20failed%22
We either need to fix GCS amd/or work-around on our side.

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000007c09d305e37a0725%40google.com.

[Andrew Morton]

On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d0...@syzkaller.appspotmail.com> wrote:

> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
> kernel config: https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
> dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
> compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+a785d0...@syzkaller.appspotmail.com
>
> 2022/07/05 05:22:17 executed programs: 828
> 2022/07/05 05:22:23 executed programs: 846
> 2022/07/05 05:22:30 executed programs: 866
> 2022/07/05 05:22:37 executed programs: 875
> BUG: memory leak

Thanks. Presumably due to khugepaged changes.

Can we expect a bisection search?

[Matthew Wilcox]

On Mon, Jul 11, 2022 at 01:38:08PM -0700, Andrew Morton wrote:
> On Sat, 09 Jul 2022 00:13:23 -0700 syzbot <syzbot+a785d0...@syzkaller.appspotmail.com> wrote:
>
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: c1084b6c5620 Merge tag 'soc-fixes-5.19-2' of git://git.ker..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14967ccc080000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=916233b7694a38ff
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
> > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=122ae834080000
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+a785d0...@syzkaller.appspotmail.com
> >
> > 2022/07/05 05:22:17 executed programs: 828
> > 2022/07/05 05:22:23 executed programs: 846
> > 2022/07/05 05:22:30 executed programs: 866
> > 2022/07/05 05:22:37 executed programs: 875
> > BUG: memory leak
>
> Thanks. Presumably due to khugepaged changes.

Huh, I was expecting it to be something I'd messed up. I've been
looking at it today, but no luck figuring it out so far.

> Can we expect a bisection search?

We only have a syz reproducer so far, and if I understand correctly,
it's probably because this is a flaky test (because it's trying to
find something that's a race condition).

I expect a bisection search to go badly wrong if this is true.

[Dmitry Vyukov]

Is it possible that parts of xas are not freed on the error paths?
I don't immediately see where anything is freed on these error paths:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n681
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/xarray.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n721
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1675

[Matthew Wilcox]

There's nothing to free; if a node is allocated, then it's stored in
the tree where it can later be found and reused.

[Dmitry Vyukov]

What I was thinking of is:

The leaked memory is allocated with:
xas_create_range(&xas);
here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1670

So I assumed the nodes stored in the xas object, which is local to the
collapse_file() function.

So if we do "goto out" here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/khugepaged.c?id=c1084b6c5620a743f86947caca66d90f24060f56#n1676

There does not seem to be anything that frees anything stored in the xas:

out:
VM_BUG_ON(!list_empty(&pagelist));
if (!IS_ERR_OR_NULL(*hpage))
mem_cgroup_uncharge(page_folio(*hpage));
/* TODO: tracepoints */
}

[Matthew Wilcox]

Yes, that's a reasonable thing to think, but it's actually not how
it works. When we allocate a node in xas_create(), we put it straight
into the tree without storing it in xas->xa_alloc. We may then end
up not using it, but the node isn't leaked because it's in the tree.

If the GFP_NOWAIT allocation fails (it didn't in these stack traces),
we call xas_nomem(), which sees an -ENOMEM, allocates a node and stores
it in xas->xa_alloc; then we go round the loop again where xas_create()
will take the node from xas->xa_alloc. But the backtraces here don't
implicate xas_nomem().

[Dmitry Vyukov]

I see. Thanks for the explanation.

Then I think it's still possible that this is a KMEMLEAK false
positive. IIRC it may have some false positives since it does not do
full stop-the-world before scanning memory/registers. syzkaller tries
to circumvent this by doing multiple scans with some delays, but it
does not give 100% guarantee.
And I am assuming this code does not try to hide pointers by storing
something in low/high bits, etc.

[Matthew Wilcox]

On Tue, Jul 12, 2022 at 01:57:59PM +0100, Matthew Wilcox wrote:
> > So I assumed the nodes stored in the xas object, which is local to the
> > collapse_file() function.
>
> Yes, that's a reasonable thing to think, but it's actually not how
> it works. When we allocate a node in xas_create(), we put it straight
> into the tree without storing it in xas->xa_alloc. We may then end
> up not using it, but the node isn't leaked because it's in the tree.
>
> If the GFP_NOWAIT allocation fails (it didn't in these stack traces),
> we call xas_nomem(), which sees an -ENOMEM, allocates a node and stores
> it in xas->xa_alloc; then we go round the loop again where xas_create()
> will take the node from xas->xa_alloc. But the backtraces here don't
> implicate xas_nomem().

There is actually a leak here, but it's not the one that's been found.

do {
xas_lock_irq(&xas);
xas_create_range(&xas);
if (!xas_error(&xas))
break;
xas_unlock_irq(&xas);
if (!xas_nomem(&xas, GFP_KERNEL)) {
result = SCAN_FAIL;
goto out;
}
} while (1);

If xas_create() fails, it sets xas error to -ENOMEM. So we unlock the
xarray lock and call xas_nomem(). xas_nomem() sees the error is -ENOMEM
and allocates a node with GFP_KERNEL, putting the node in xas->xa_alloc.
We re-take the spinlock and call xas_create() again. If we still need
a node, xas_alloc() will take the node stored in xas->xa_alloc. If we
raced and don't need a node, xas_create_range() succeeds and we break out,
failing to free the xas->xa_alloc node.

We should call xas_destroy() at the out: label. However, this does not
explain what is going on, and will not fix what is going on, since any
nodes allocated during xas_create_range() will be stored safely in the
tree and will not be freed by xas_destroy().

[Matthew Wilcox]

On Tue, Jul 12, 2022 at 03:29:29PM +0200, Dmitry Vyukov wrote:
> Then I think it's still possible that this is a KMEMLEAK false
> positive. IIRC it may have some false positives since it does not do
> full stop-the-world before scanning memory/registers. syzkaller tries
> to circumvent this by doing multiple scans with some delays, but it
> does not give 100% guarantee.
> And I am assuming this code does not try to hide pointers by storing
> something in low/high bits, etc.

Oh, I meant to answer this. The XArray does set bit 1 of the pointer
when it's stored in the tree. However, this shouldn't affect kmemleak
(I would think) because it looks like a pointer to the third byte of the
allocation, so the allocation is still referenced, even if the first
byte of the allocation isn't referenced.

Also, I would expect kmemleak to report bugs all over if this were the
problem, because every node no matter how it's allocated gets its bit 1
set.

[Taras Madan]

Did you already https://github.com/google/syzkaller/issues it?

[Dmitry Vyukov]

On Fri, 5 Aug 2022 at 13:34, Taras Madan <taras...@google.com> wrote:
>
> Did you already https://github.com/google/syzkaller/issues it?

https://github.com/google/syzkaller/issues?q=is%3Aissue+%22create+image+operation+failed%22

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit: 2f5065a0bc9d Merge tag 'acpi-6.1-rc4' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12351e76880000
kernel config: https://syzkaller.appspot.com/x/.config?x=7da85296f1024c6a

dashboard link: https://syzkaller.appspot.com/bug?extid=a785d07959bc94837d51
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

syz repro: https://syzkaller.appspot.com/x/repro.syz?x=110bbf39880000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12fff099880000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/2e34093711ff/disk-2f5065a0.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/73117023c3a9/vmlinux-2f5065a0.xz
kernel image: https://storage.googleapis.com/syzbot-assets/c708621825f8/bzImage-2f5065a0.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a785d0...@syzkaller.appspotmail.com

write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file or directory
write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file or directory
BUG: memory leak
unreferenced object 0xffff88810fd216c0 (size 576):
comm "syz-executor159", pid 3686, jiffies 4295064650 (age 50.150s)

hex dump (first 32 bytes):

06 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20 85 98 0f 81 88 ff ff d8 16 d2 0f 81 88 ff ff ...............
backtrace:
[<ffffffff844153c6>] xas_alloc+0xf6/0x120 lib/xarray.c:377
[<ffffffff84418039>] xas_create+0x3b9/0x800 lib/xarray.c:679
[<ffffffff84418520>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
[<ffffffff8159f11c>] collapse_file+0x13c/0x2730 mm/khugepaged.c:1725
[<ffffffff815a1b28>] hpage_collapse_scan_file+0x418/0x9a0 mm/khugepaged.c:2156
[<ffffffff815a4001>] madvise_collapse+0x211/0x5e0 mm/khugepaged.c:2611
[<ffffffff8153ba2d>] madvise_vma_behavior+0x5dd/0x1030 mm/madvise.c:1076
[<ffffffff81537257>] madvise_walk_vmas+0x127/0x1d0 mm/madvise.c:1250
[<ffffffff81537eb0>] do_madvise.part.0+0x1c0/0x2b0 mm/madvise.c:1429
[<ffffffff8153c6e8>] do_madvise mm/madvise.c:1440 [inline]
[<ffffffff8153c6e8>] __do_sys_madvise mm/madvise.c:1442 [inline]
[<ffffffff8153c6e8>] __se_sys_madvise mm/madvise.c:1440 [inline]
[<ffffffff8153c6e8>] __x64_sys_madvise+0x98/0xa0 mm/madvise.c:1440
[<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

BUG: memory leak
unreferenced object 0xffff88810fd21480 (size 576):
comm "syz-executor159", pid 3686, jiffies 4295064650 (age 50.150s)

hex dump (first 32 bytes):

00 07 00 00 00 00 00 00 c0 16 d2 0f 81 88 ff ff ................
20 85 98 0f 81 88 ff ff 98 14 d2 0f 81 88 ff ff ...............
backtrace:
[<ffffffff844153c6>] xas_alloc+0xf6/0x120 lib/xarray.c:377
[<ffffffff84418039>] xas_create+0x3b9/0x800 lib/xarray.c:679
[<ffffffff84418520>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
[<ffffffff8159f11c>] collapse_file+0x13c/0x2730 mm/khugepaged.c:1725
[<ffffffff815a1b28>] hpage_collapse_scan_file+0x418/0x9a0 mm/khugepaged.c:2156
[<ffffffff815a4001>] madvise_collapse+0x211/0x5e0 mm/khugepaged.c:2611
[<ffffffff8153ba2d>] madvise_vma_behavior+0x5dd/0x1030 mm/madvise.c:1076
[<ffffffff81537257>] madvise_walk_vmas+0x127/0x1d0 mm/madvise.c:1250
[<ffffffff81537eb0>] do_madvise.part.0+0x1c0/0x2b0 mm/madvise.c:1429
[<ffffffff8153c6e8>] do_madvise mm/madvise.c:1440 [inline]
[<ffffffff8153c6e8>] __do_sys_madvise mm/madvise.c:1442 [inline]
[<ffffffff8153c6e8>] __se_sys_madvise mm/madvise.c:1440 [inline]
[<ffffffff8153c6e8>] __x64_sys_madvise+0x98/0xa0 mm/madvise.c:1440
[<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

BUG: memory leak
unreferenced object 0xffff88810fd21240 (size 576):
comm "syz-executor159", pid 3686, jiffies 4295064650 (age 50.150s)

hex dump (first 32 bytes):

00 06 00 00 00 00 00 00 c0 16 d2 0f 81 88 ff ff ................
20 85 98 0f 81 88 ff ff 58 12 d2 0f 81 88 ff ff .......X.......
backtrace:
[<ffffffff844153c6>] xas_alloc+0xf6/0x120 lib/xarray.c:377
[<ffffffff84418039>] xas_create+0x3b9/0x800 lib/xarray.c:679
[<ffffffff84418520>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
[<ffffffff8159f11c>] collapse_file+0x13c/0x2730 mm/khugepaged.c:1725
[<ffffffff815a1b28>] hpage_collapse_scan_file+0x418/0x9a0 mm/khugepaged.c:2156
[<ffffffff815a4001>] madvise_collapse+0x211/0x5e0 mm/khugepaged.c:2611
[<ffffffff8153ba2d>] madvise_vma_behavior+0x5dd/0x1030 mm/madvise.c:1076
[<ffffffff81537257>] madvise_walk_vmas+0x127/0x1d0 mm/madvise.c:1250
[<ffffffff81537eb0>] do_madvise.part.0+0x1c0/0x2b0 mm/madvise.c:1429
[<ffffffff8153c6e8>] do_madvise mm/madvise.c:1440 [inline]
[<ffffffff8153c6e8>] __do_sys_madvise mm/madvise.c:1442 [inline]
[<ffffffff8153c6e8>] __se_sys_madvise mm/madvise.c:1440 [inline]
[<ffffffff8153c6e8>] __x64_sys_madvise+0x98/0xa0 mm/madvise.c:1440
[<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

BUG: memory leak
unreferenced object 0xffff88810fd24d80 (size 576):
comm "syz-executor159", pid 3686, jiffies 4295064650 (age 50.150s)

hex dump (first 32 bytes):

00 05 00 00 00 00 00 00 c0 16 d2 0f 81 88 ff ff ................
20 85 98 0f 81 88 ff ff 98 4d d2 0f 81 88 ff ff ........M......
backtrace:
[<ffffffff844153c6>] xas_alloc+0xf6/0x120 lib/xarray.c:377
[<ffffffff84418039>] xas_create+0x3b9/0x800 lib/xarray.c:679
[<ffffffff84418520>] xas_create_range+0xa0/0x1c0 lib/xarray.c:719
[<ffffffff8159f11c>] collapse_file+0x13c/0x2730 mm/khugepaged.c:1725
[<ffffffff815a1b28>] hpage_collapse_scan_file+0x418/0x9a0 mm/khugepaged.c:2156
[<ffffffff815a4001>] madvise_collapse+0x211/0x5e0 mm/khugepaged.c:2611
[<ffffffff8153ba2d>] madvise_vma_behavior+0x5dd/0x1030 mm/madvise.c:1076
[<ffffffff81537257>] madvise_walk_vmas+0x127/0x1d0 mm/madvise.c:1250
[<ffffffff81537eb0>] do_madvise.part.0+0x1c0/0x2b0 mm/madvise.c:1429
[<ffffffff8153c6e8>] do_madvise mm/madvise.c:1440 [inline]
[<ffffffff8153c6e8>] __do_sys_madvise mm/madvise.c:1442 [inline]
[<ffffffff8153c6e8>] __se_sys_madvise mm/madvise.c:1440 [inline]
[<ffffffff8153c6e8>] __x64_sys_madvise+0x98/0xa0 mm/madvise.c:1440
[<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file or directory
write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file or directory
write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file or directory
write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file or directory