All of lore.kernel.org
 help / color / mirror / Atom feed
* crypto: fscrypt: crypto_create_tfm_node memory leak
@ 2025-02-17 18:43 ` Lucas Tanure
  0 siblings, 0 replies; 5+ messages in thread
From: Lucas Tanure @ 2025-02-17 18:43 UTC (permalink / raw)
  To: kernelnewbies, linux-fscrypt, LKML, linux-crypto
  Cc: krzysztof.opasiak@neat.no, lucas.tanure@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

^ permalink raw reply	[flat|nested] 5+ messages in thread
* crypto: fscrypt: crypto_create_tfm_node memory leak
@ 2025-02-17 18:43 ` Lucas Tanure
  0 siblings, 0 replies; 5+ 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] 5+ messages in thread
* Re: crypto: fscrypt: crypto_create_tfm_node memory leak
  2025-02-17 18:43 ` Lucas Tanure
  (?)
@ 2025-02-17 18:50 ` Eric Biggers
  2025-02-17 19:08     ` Lucas Tanure
  -1 siblings, 1 reply; 5+ messages in thread
From: Eric Biggers @ 2025-02-17 18:50 UTC (permalink / raw)
  To: Lucas Tanure
  Cc: kernelnewbies, linux-fscrypt, LKML, linux-crypto,
	krzysztof.opasiak@neat.no, lucas.tanure@neat.no

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.

smp_store_release is just a fancy way of doing a store that includes a memory
barrier.

- Eric

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: crypto: fscrypt: crypto_create_tfm_node memory leak
  2025-02-17 18:50 ` Eric Biggers
@ 2025-02-17 19:08     ` Lucas Tanure
  0 siblings, 0 replies; 5+ messages in thread
From: Lucas Tanure @ 2025-02-17 19:08 UTC (permalink / raw)
  To: Eric Biggers
  Cc: kernelnewbies, linux-fscrypt, LKML, linux-crypto,
	krzysztof.opasiak@neat.no, lucas.tanure@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

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: crypto: fscrypt: crypto_create_tfm_node memory leak
@ 2025-02-17 19:08     ` Lucas Tanure
  0 siblings, 0 replies; 5+ 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] 5+ messages in thread
end of thread, other threads:[~2025-02-17 19:10 UTC | newest]

Thread overview: 5+ 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
2025-02-17 18:43 ` Lucas Tanure
2025-02-17 18:50 ` Eric Biggers
2025-02-17 19:08   ` Lucas Tanure
2025-02-17 19:08     ` Lucas Tanure

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.