Fw: [Bug 206651] New: kmemleak in rpcsec_gss_krb5

Fw: [Bug 206651] New: kmemleak in rpcsec_gss_krb5

[Stephen Hemminger]

Begin forwarded message:

Date: Mon, 24 Feb 2020 03:16:28 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 206651] New: kmemleak in rpcsec_gss_krb5


https://bugzilla.kernel.org/show_bug.cgi?id=206651

            Bug ID: 206651
           Summary: kmemleak in rpcsec_gss_krb5
           Product: Networking
           Version: 2.5
    Kernel Version: 4.19.36
          Hardware: ARM
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
          Assignee: stephen@networkplumber.org
          Reporter: kircherlike@outlook.com
        Regression: No

During the loading and unloading of the kernel module, kmemleak discovered a
leak problem. To reproduce this problem, you only need to enable the kmemleak
option. 
CONFIG_DEBUG_KMEMLEAK=y 
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=10000: 
Then, load and unload the module. 
modprobe rpcsec_gss_krb5 
modprobe -r rpcsec_gss_krb5: 
Repeat this process every 1000 cycles to obtain the leaked information. 
Repeat the preceding operations for 115 times. The SUnreclaim memory will
increase by 85 MB. 

After checking the loading source code of rpcsec_gss_krb5, we find that the
svcauth_gss_register_pseudoflavor function in the svcauth_gss.c file contains
the following code segment: 

...
        test = auth_domain_lookup(name, &new->h);
        if (test != &new->h) { /* Duplicate registration */
                auth_domain_put(test);
                kfree(new->h.name);
                goto out_free_dom;
        }
        return 0;

out_free_dom:
        kfree(new);
out:
        return stat;
...

The structure of new->h.name is dynamically applied by kstrdup. When
auth_domain_lookup cannot find new->h.name in the hash table, it is added to
the hash table. 

When the module is unloaded, the structure in the hash table is not released
accordingly. As a result, the module is leaked. I modified the gss_mech_free
function to forcibly release the structure in the hash table. 

...
        for (i = 0; i < gm->gm_pf_num; i++) {
                pf = &gm->gm_pfs[i];
+               struct auth_domain *test;
+               test = auth_domain_find(pf->auth_domain_name);
+               if (test != NULL) {
+                       test->flavour->domain_release(test);
+               }
                kfree(pf->auth_domain_name);
...

Perform the leakage test again. The memory usage of SUnreclaim does not
increase. 

I want a complete destructor to free the hash table, not by force.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Re: Fw: [Bug 206651] New: kmemleak in rpcsec_gss_krb5

[J. Bruce Fields]

On Sun, Feb 23, 2020 at 07:55:20PM -0800, Stephen Hemminger wrote:
> During the loading and unloading of the kernel module, kmemleak discovered a
> leak problem. To reproduce this problem, you only need to enable the kmemleak
> option. 
> CONFIG_DEBUG_KMEMLEAK=y 
> CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE=10000: 
> Then, load and unload the module. 
> modprobe rpcsec_gss_krb5 
> modprobe -r rpcsec_gss_krb5: 
> Repeat this process every 1000 cycles to obtain the leaked information. 
> Repeat the preceding operations for 115 times. The SUnreclaim memory will
> increase by 85 MB. 
> 
> After checking the loading source code of rpcsec_gss_krb5, we find that the
> svcauth_gss_register_pseudoflavor function in the svcauth_gss.c file contains
> the following code segment: 
> 
> ...
>         test = auth_domain_lookup(name, &new->h);
>         if (test != &new->h) { /* Duplicate registration */
>                 auth_domain_put(test);
>                 kfree(new->h.name);
>                 goto out_free_dom;
>         }
>         return 0;
> 
> out_free_dom:
>         kfree(new);
> out:
>         return stat;
> ...
> 
> The structure of new->h.name is dynamically applied by kstrdup. When
> auth_domain_lookup cannot find new->h.name in the hash table, it is added to
> the hash table. 
> 
> When the module is unloaded, the structure in the hash table is not released
> accordingly. As a result, the module is leaked. I modified the gss_mech_free
> function to forcibly release the structure in the hash table. 
> 
> ...
>         for (i = 0; i < gm->gm_pf_num; i++) {
>                 pf = &gm->gm_pfs[i];
> +               struct auth_domain *test;
> +               test = auth_domain_find(pf->auth_domain_name);
> +               if (test != NULL) {
> +                       test->flavour->domain_release(test);
> +               }
>                 kfree(pf->auth_domain_name);
> ...
> 
> Perform the leakage test again. The memory usage of SUnreclaim does not
> increase. 
> 
> I want a complete destructor to free the hash table, not by force.

Thanks!  I'm not sure what the right solution is.  Honestly, maybe just
preventing unloading of these modules--I'm not sure why it's really
needed.

--b.