netdev - Re: [PATCH] net: fix memory leak in security_sk

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iKVBkbd=vmg0edybmStkDo+zM6N3BP2=71mNZmCG=T6HQ@mail.gmail.com>
Date:   Fri, 11 Nov 2022 08:28:50 -0800
From:   Eric Dumazet <edumazet@...gle.com>
To:     Wang Yufen <wangyufen@...wei.com>
Cc:     linux-security-module@...r.kernel.org, netdev@...r.kernel.org,
        paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com,
        martin.lau@...nel.org, daniel@...earbox.net, ast@...nel.org,
        pabeni@...hat.com, kuba@...nel.org,
        Stanislav Fomichev <sdf@...gle.com>
Subject: Re: [PATCH] net: fix memory leak in security_sk_alloc()

On Fri, Nov 11, 2022 at 1:32 AM Wang Yufen <wangyufen@...wei.com> wrote:
>
> kmemleak reports this issue:
>
> unreferenced object 0xffff88810b7835c0 (size 32):
>   comm "test_progs", pid 270, jiffies 4294969007 (age 1621.315s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>     03 00 00 00 03 00 00 00 0f 00 00 00 00 00 00 00  ................
>   backtrace:
>     [<00000000376cdeab>] kmalloc_trace+0x27/0x110
>     [<000000003bcdb3b6>] selinux_sk_alloc_security+0x66/0x110
>     [<000000003959008f>] security_sk_alloc+0x47/0x80
>     [<00000000e7bc6668>] sk_prot_alloc+0xbd/0x1a0
>     [<0000000002d6343a>] sk_alloc+0x3b/0x940
>     [<000000009812a46d>] unix_create1+0x8f/0x3d0
>     [<000000005ed0976b>] unix_create+0xa1/0x150
>     [<0000000086a1d27f>] __sock_create+0x233/0x4a0
>     [<00000000cffe3a73>] __sys_socket_create.part.0+0xaa/0x110
>     [<0000000007c63f20>] __sys_socket+0x49/0xf0
>     [<00000000b08753c8>] __x64_sys_socket+0x42/0x50
>     [<00000000b56e26b3>] do_syscall_64+0x3b/0x90
>     [<000000009b4871b8>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> The issue occurs in the following scenarios:
>
> unix_create1()
>   sk_alloc()
>     sk_prot_alloc()
>       security_sk_alloc()
>         call_int_hook()
>           hlist_for_each_entry()
>             entry1->hook.sk_alloc_security
>             <-- selinux_sk_alloc_security() succeeded,
>             <-- sk->security alloced here.
>             entry2->hook.sk_alloc_security
>             <-- bpf_lsm_sk_alloc_security() failed
>       goto out_free;
>         ...    <-- the sk->security not freed, memleak
>
> To fix, if security_sk_alloc() failed and sk->security not null,
> goto out_free_sec to reclaim resources.
>
> I'm not sure whether this fix makes sense, but if hook lists don't
> support this usage, might need to modify the
> "tools/testing/selftests/bpf/progs/lsm_cgroup.c" test case.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")

Really the bug has not been added in linux-2.6.12, but this year with
bpf lsm ...

> Signed-off-by: Wang Yufen <wangyufen@...wei.com>
> Cc: Stanislav Fomichev <sdf@...gle.com>
> ---
>  net/core/sock.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index a3ba035..e457a9d 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2030,8 +2030,11 @@ static struct sock *sk_prot_alloc(struct proto *prot, gfp_t priority,
>                 sk = kmalloc(prot->obj_size, priority);
>
>         if (sk != NULL) {
> -               if (security_sk_alloc(sk, family, priority))
> +               if (security_sk_alloc(sk, family, priority)) {

This does not make sense.

A proper fix should be in security_sk_alloc(), not in callers.

(Even if there is one caller today,)

> +                       if (sk->sk_security)
> +                               goto out_free_sec;
>                         goto out_free;
> +               }
>
>                 if (!try_module_get(prot->owner))
>                         goto out_free_sec;
> --
> 1.8.3.1
>