From: Andrew Morton <akpm@linux-foundation.org>
To: akpm@linux-foundation.org, dvyukov@google.com, elver@google.com,
glider@google.com, hulkci@huawei.com, libaokun1@huawei.com,
linux-mm@kvack.org, mm-commits@vger.kernel.org,
torvalds@linux-foundation.org, wangkefeng.wang@huawei.com,
yukuai3@huawei.com
Subject: [patch 1/9] kfence: fix memory leak when cat kfence objects
Date: Fri, 24 Dec 2021 21:12:32 -0800 [thread overview]
Message-ID: <20211225051232.Xrw2Ipiny%akpm@linux-foundation.org> (raw)
In-Reply-To: <20211224211127.30b60764d059ff3b0afea38a@linux-foundation.org>
From: Baokun Li <libaokun1@huawei.com>
Subject: kfence: fix memory leak when cat kfence objects
Hulk robot reported a kmemleak problem:
-----------------------------------------------------------------------
unreferenced object 0xffff93d1d8cc02e8 (size 248):
comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s)
hex dump (first 32 bytes):
00 40 85 19 d4 93 ff ff 00 10 00 00 00 00 00 00 .@..............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000db5610b3>] seq_open+0x2a/0x80
[<00000000d66ac99d>] full_proxy_open+0x167/0x1e0
[<00000000d58ef917>] do_dentry_open+0x1e1/0x3a0
[<0000000016c91867>] path_openat+0x961/0xa20
[<00000000909c9564>] do_filp_open+0xae/0x120
[<0000000059c761e6>] do_sys_openat2+0x216/0x2f0
[<00000000b7a7b239>] do_sys_open+0x57/0x80
[<00000000e559d671>] do_syscall_64+0x33/0x40
[<000000000ea1fbfd>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
unreferenced object 0xffff93d419854000 (size 4096):
comm "cat", pid 23327, jiffies 4624670141 (age 495992.217s)
hex dump (first 32 bytes):
6b 66 65 6e 63 65 2d 23 32 35 30 3a 20 30 78 30 kfence-#250: 0x0
30 30 30 30 30 30 30 37 35 34 62 64 61 31 32 2d 0000000754bda12-
backtrace:
[<000000008162c6f2>] seq_read_iter+0x313/0x440
[<0000000020b1b3e3>] seq_read+0x14b/0x1a0
[<00000000af248fbc>] full_proxy_read+0x56/0x80
[<00000000f97679d1>] vfs_read+0xa5/0x1b0
[<000000000ed8a36f>] ksys_read+0xa0/0xf0
[<00000000e559d671>] do_syscall_64+0x33/0x40
[<000000000ea1fbfd>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
-----------------------------------------------------------------------
I find that we can easily reproduce this problem with the following
commands:
`cat /sys/kernel/debug/kfence/objects`
`echo scan > /sys/kernel/debug/kmemleak`
`cat /sys/kernel/debug/kmemleak`
The leaked memory is allocated in the stack below:
----------------------------------
do_syscall_64
do_sys_open
do_dentry_open
full_proxy_open
seq_open ---> alloc seq_file
vfs_read
full_proxy_read
seq_read
seq_read_iter
traverse ---> alloc seq_buf
----------------------------------
And it should have been released in the following process:
----------------------------------
do_syscall_64
syscall_exit_to_user_mode
exit_to_user_mode_prepare
task_work_run
____fput
__fput
full_proxy_release ---> free here
----------------------------------
However, the release function corresponding to file_operations is not
implemented in kfence. As a result, a memory leak occurs. Therefore,
the solution to this problem is to implement the corresponding
release function.
Link: https://lkml.kernel.org/r/20211206133628.2822545-1-libaokun1@huawei.com
Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure")
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reported-by: Hulk Robot <hulkci@huawei.com>
Acked-by: Marco Elver <elver@google.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/kfence/core.c | 1 +
1 file changed, 1 insertion(+)
--- a/mm/kfence/core.c~kfence-fix-memory-leak-when-cat-kfence-objects
+++ a/mm/kfence/core.c
@@ -683,6 +683,7 @@ static const struct file_operations obje
.open = open_objects,
.read = seq_read,
.llseek = seq_lseek,
+ .release = seq_release,
};
static int __init kfence_debugfs_init(void)
_
next prev parent reply other threads:[~2021-12-25 5:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-25 5:11 incoming Andrew Morton
2021-12-25 5:12 ` Andrew Morton [this message]
2021-12-25 5:12 ` [patch 2/9] mm: mempolicy: fix THP allocations escaping mempolicy restrictions Andrew Morton
2021-12-25 5:12 ` [patch 3/9] kernel/crash_core: suppress unknown crashkernel parameter warning Andrew Morton
2021-12-25 5:12 ` [patch 4/9] MAINTAINERS: mark more list instances as moderated Andrew Morton
2021-12-25 5:12 ` [patch 5/9] mm, hwpoison: fix condition in free hugetlb page path Andrew Morton
2021-12-25 5:12 ` [patch 6/9] mm: delete unsafe BUG from page_cache_add_speculative() Andrew Morton
2021-12-25 5:12 ` [patch 7/9] mm/page_alloc: fix __alloc_size attribute for alloc_pages_exact_nid Andrew Morton
2021-12-25 5:12 ` [patch 8/9] mm/damon/dbgfs: protect targets destructions with kdamond_lock Andrew Morton
2021-12-25 5:12 ` [patch 9/9] mm/hwpoison: clear MF_COUNT_INCREASED before retrying get_any_page() Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211225051232.Xrw2Ipiny%akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=hulkci@huawei.com \
--cc=libaokun1@huawei.com \
--cc=linux-mm@kvack.org \
--cc=mm-commits@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=wangkefeng.wang@huawei.com \
--cc=yukuai3@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).