linux-kernel - Re: [PATCH -next] kfence: fix memory leak when cat kfence objects

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <71c69735-6064-6b28-eab3-67c36f88e51d@huawei.com>
Date:   Mon, 6 Dec 2021 22:06:51 +0800
From:   Kefeng Wang <wangkefeng.wang@...wei.com>
To:     Marco Elver <elver@...gle.com>, Baokun Li <libaokun1@...wei.com>
CC:     <glider@...gle.com>, <dvyukov@...gle.com>,
        <akpm@...ux-foundation.org>, <viro@...iv.linux.org.uk>,
        <kasan-dev@...glegroups.com>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>, <yukuai3@...wei.com>,
        Hulk Robot <hulkci@...wei.com>
Subject: Re: [PATCH -next] kfence: fix memory leak when cat kfence objects


On 2021/12/6 21:29, Marco Elver wrote:
> On Mon, 6 Dec 2021 at 14:24, Baokun Li <libaokun1@...wei.com> 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 <hulkci@...wei.com>
>> Signed-off-by: Baokun Li <libaokun1@...wei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@...wei.com>