From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 11613C433FE for ; Mon, 6 Dec 2021 14:07:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A8F06B007E; Mon, 6 Dec 2021 09:07:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 857E56B0080; Mon, 6 Dec 2021 09:07:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 748406B0081; Mon, 6 Dec 2021 09:07:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 66B4F6B007E for ; Mon, 6 Dec 2021 09:07:09 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 3276574CFB for ; Mon, 6 Dec 2021 14:06:59 +0000 (UTC) X-FDA: 78887545758.02.F46799D Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf31.hostedemail.com (Postfix) with ESMTP id D1852105299C for ; Mon, 6 Dec 2021 14:06:57 +0000 (UTC) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.55]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4J74sw35xcz1DJxB; Mon, 6 Dec 2021 22:04:04 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 6 Dec 2021 22:06:52 +0800 Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.20; Mon, 6 Dec 2021 22:06:51 +0800 Message-ID: <71c69735-6064-6b28-eab3-67c36f88e51d@huawei.com> Date: Mon, 6 Dec 2021 22:06:51 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH -next] kfence: fix memory leak when cat kfence objects Content-Language: en-US To: Marco Elver , Baokun Li CC: , , , , , , , , Hulk Robot References: <20211206133628.2822545-1-libaokun1@huawei.com> From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggeme705-chm.china.huawei.com (10.1.199.101) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Stat-Signature: yszdf4ac1akxwtsfd8hu3owjju6qpz4c Authentication-Results: imf31.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf31.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: D1852105299C X-HE-Tag: 1638799617-688981 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2021/12/6 21:29, Marco Elver wrote: > On Mon, 6 Dec 2021 at 14:24, Baokun Li wrote: >> 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. >> >> Fixes: 0ce20dd84089 ("mm: add Kernel Electric-Fence infrastructure") >> Reported-by: Hulk Robot >> Signed-off-by: Baokun Li Reviewed-by: Kefeng Wang