* crypto: fscrypt: crypto_create_tfm_node memory leak @ 2025-02-17 18:43 Lucas Tanure [not found] ` <20250217185000.GC1258@sol.localdomain> 0 siblings, 1 reply; 2+ messages in thread From: Lucas Tanure @ 2025-02-17 18:43 UTC (permalink / raw) To: kernelnewbies, linux-fscrypt, LKML, linux-crypto Cc: lucas.tanure@neat.no, krzysztof.opasiak@neat.no Hi, I am working with Android 13 and V5.15 kernel. During our development, I found a memory leak using kmemleak. Steps I did to find the memleak: mount -t debugfs debugfs /sys/kernel/debug echo scan=5 > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak Stack I got (hundreds of them): unreferenced object 0xffffff8101d31000 (size 1024): comm "binder:1357_2", pid 1357, jiffies 4294899464 (age 394.468s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffd327cac060>] crypto_create_tfm_node+0x64/0x228 [<ffffffd3279f8c4c>] fscrypt_prepare_key+0xbc/0x230 [<ffffffd3279f9758>] fscrypt_setup_v1_file_key+0x48c/0x510 [<ffffffd3279f8394>] fscrypt_setup_encryption_info+0x210/0x43c [<ffffffd3279f8108>] fscrypt_prepare_new_inode+0x128/0x1a4 [<ffffffd327bcc878>] f2fs_new_inode+0x27c/0x89c [<ffffffd327bce7c4>] f2fs_mkdir+0x78/0x278 [<ffffffd32796a3bc>] vfs_mkdir+0x138/0x204 [<ffffffd32796a108>] do_mkdirat+0x88/0x204 [<ffffffd32796a068>] __arm64_sys_mkdirat+0x40/0x58 [<ffffffd3274be5d4>] invoke_syscall+0x60/0x150 [<ffffffd3274be528>] el0_svc_common+0xc8/0x114 [<ffffffd3274be3f0>] do_el0_svc+0x28/0x98 [<ffffffd328abcf88>] el0_svc+0x28/0x90 [<ffffffd328abcefc>] el0t_64_sync_handler+0x88/0xec [<ffffffd32741164c>] el0t_64_sync+0x1b8/0x1bc After checking upstream, I came up with the following: cff805b1518f fscrypt: fix keyring memory leak on mount failure But my kernel has this patch. So I continued to dig around this and saw the function fscrypt_prepare_key in fs/crypto/keysetup.c for V5.15. I can't see the pointer tfm being used anywhere or saved, and smp_store_release doesn't kfree it. Is smp_store_release doing something with that pointer that makes this memory leak a false positive? Any help with this issue would be much appreciated. Thanks Lucas Tanure _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 2+ messages in thread
[parent not found: <20250217185000.GC1258@sol.localdomain>]
* Re: crypto: fscrypt: crypto_create_tfm_node memory leak [not found] ` <20250217185000.GC1258@sol.localdomain> @ 2025-02-17 19:08 ` Lucas Tanure 0 siblings, 0 replies; 2+ messages in thread From: Lucas Tanure @ 2025-02-17 19:08 UTC (permalink / raw) To: Eric Biggers Cc: kernelnewbies, LKML, lucas.tanure@neat.no, linux-fscrypt, linux-crypto, krzysztof.opasiak@neat.no On Mon, Feb 17, 2025 at 6:50 PM Eric Biggers <ebiggers@kernel.org> wrote: > > On Mon, Feb 17, 2025 at 06:43:15PM +0000, Lucas Tanure wrote: > > Hi, > > > > I am working with Android 13 and V5.15 kernel. During our development, > > I found a memory leak using kmemleak. > > > > Steps I did to find the memleak: > > mount -t debugfs debugfs /sys/kernel/debug > > echo scan=5 > /sys/kernel/debug/kmemleak > > cat /sys/kernel/debug/kmemleak > > > > Stack I got (hundreds of them): > > unreferenced object 0xffffff8101d31000 (size 1024): > > comm "binder:1357_2", pid 1357, jiffies 4294899464 (age 394.468s) > > hex dump (first 32 bytes): > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > backtrace: > > [<ffffffd327cac060>] crypto_create_tfm_node+0x64/0x228 > > [<ffffffd3279f8c4c>] fscrypt_prepare_key+0xbc/0x230 > > [<ffffffd3279f9758>] fscrypt_setup_v1_file_key+0x48c/0x510 > > [<ffffffd3279f8394>] fscrypt_setup_encryption_info+0x210/0x43c > > [<ffffffd3279f8108>] fscrypt_prepare_new_inode+0x128/0x1a4 > > [<ffffffd327bcc878>] f2fs_new_inode+0x27c/0x89c > > [<ffffffd327bce7c4>] f2fs_mkdir+0x78/0x278 > > [<ffffffd32796a3bc>] vfs_mkdir+0x138/0x204 > > [<ffffffd32796a108>] do_mkdirat+0x88/0x204 > > [<ffffffd32796a068>] __arm64_sys_mkdirat+0x40/0x58 > > [<ffffffd3274be5d4>] invoke_syscall+0x60/0x150 > > [<ffffffd3274be528>] el0_svc_common+0xc8/0x114 > > [<ffffffd3274be3f0>] do_el0_svc+0x28/0x98 > > [<ffffffd328abcf88>] el0_svc+0x28/0x90 > > [<ffffffd328abcefc>] el0t_64_sync_handler+0x88/0xec > > [<ffffffd32741164c>] el0t_64_sync+0x1b8/0x1bc > > > > After checking upstream, I came up with the following: > > cff805b1518f fscrypt: fix keyring memory leak on mount failure > > > > But my kernel has this patch. So I continued to dig around this and > > saw the function fscrypt_prepare_key in fs/crypto/keysetup.c for > > V5.15. > > I can't see the pointer tfm being used anywhere or saved, and > > smp_store_release doesn't kfree it. > > Is smp_store_release doing something with that pointer that makes this > > memory leak a false positive? > > > > Any help with this issue would be much appreciated. > > Thanks > > The pointer to the crypto_skcipher 'tfm' is stored in the fscrypt_inode_info > (previously fscrypt_info) which is stored in inode::i_crypt_info. It gets freed > when the inode is evicted. I don't know why you're getting a kmemleak warning. > Perhaps f2fs in that version of the kernel has a bug that is leaking inodes. > Thanks. How do you check for leaking inodes? Do you have any start point (function) to look at? > smp_store_release is just a fancy way of doing a store that includes a memory > barrier. > > - Eric Lucas _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-02-17 19:10 UTC | newest] Thread overview: 2+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-02-17 18:43 crypto: fscrypt: crypto_create_tfm_node memory leak Lucas Tanure [not found] ` <20250217185000.GC1258@sol.localdomain> 2025-02-17 19:08 ` Lucas Tanure
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).