linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Markus Elfring <Markus.Elfring@web.de>
Cc: Navid Emamdoost <navid.emamdoost@gmail.com>,
	linux-security-module@vger.kernel.org, netdev@vger.kernel.org,
	Navid Emamdoost <emamd001@umn.edu>, Kangjie Lu <kjlu@umn.edu>,
	linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org,
	Stephen A McCamant <smccaman@umn.edu>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: genetlink: prevent memory leak in netlbl_unlabel_defconf
Date: Fri, 27 Sep 2019 10:48:54 -0400	[thread overview]
Message-ID: <CAHC9VhRk8Gc_Yexrjz5uif+Vj7d+b=uMUytbrmbm2Yv+zoM05w@mail.gmail.com> (raw)
In-Reply-To: <c490685a-c7d6-5c95-5bf4-ed71f3c60cb6@web.de>

On Fri, Sep 27, 2019 at 9:15 AM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> > > In netlbl_unlabel_defconf if netlbl_domhsh_add_default fails the
> > > allocated entry should be released.
> …
> > That said, netlbl_unlabel_defconf() *should* clean up here just on
> > principal if nothing else.
>
> How do you think about to add the tag “Fixes” then?

From what I've seen the "Fixes" tag is typically used by people who
are backporting patches, e.g. the -stable folks, to help decide what
they need to backport.  As I mentioned in my previous email this
missing free doesn't actually manifest itself as a practical leak on
any of the existing kernels so there isn't a need to backport this
patch.  For that reason I would probably skip the "Fixes" metadata
here, but I don't feel strongly enough about it to object if others
want it.  FWIW, I play things very conservatively when talking about
backporting patches to stable kernels; if it doesn't fix a serious
user-visible bug it shouldn't be backported IMHO.

This patch is more of a conceptual fix than a practical fix.  Not that
there is anything wrong with this patch, I just think it isn't as
critical as most people would think from reading "memory leak" in the
subject line.  Yes, there is a memory leak, but the kernel panics soon
after so it's a bit moot.  Further, even if the panic was somehow
skipped (?) the memory leak only happens once during boot; the failed
initialization is undoubtedly going to be far more damaging to the
system than a few lost bytes of memory.

-- 
paul moore
www.paul-moore.com

  reply	other threads:[~2019-09-27 14:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25 22:10 [PATCH] genetlink: prevent memory leak in netlbl_unlabel_defconf Navid Emamdoost
2019-09-25 23:27 ` Paul Moore
2019-09-27 13:15   ` Markus Elfring
2019-09-27 14:48     ` Paul Moore [this message]
2019-09-27 16:14       ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHC9VhRk8Gc_Yexrjz5uif+Vj7d+b=uMUytbrmbm2Yv+zoM05w@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=Markus.Elfring@web.de \
    --cc=davem@davemloft.net \
    --cc=emamd001@umn.edu \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=kjlu@umn.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=navid.emamdoost@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=smccaman@umn.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).