linux-kernel - crypto: fscrypt: crypto_create_tfm

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJX_Q+24svAcoyxqcUu4z2g08bJeRFEmzYtVK1paoZ0xBX_uTA@mail.gmail.com>
Date: Mon, 17 Feb 2025 18:43:15 +0000
From: Lucas Tanure <tanure@...ux.com>
To: kernelnewbies <kernelnewbies@...nelnewbies.org>, linux-fscrypt@...r.kernel.org, 
	LKML <linux-kernel@...r.kernel.org>, linux-crypto@...r.kernel.org
Cc: "krzysztof.opasiak@...t.no" <krzysztof.opasiak@...t.no>, 
	"lucas.tanure@...t.no" <lucas.tanure@...t.no>
Subject: crypto: fscrypt: crypto_create_tfm_node memory leak

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