Re: [PATCH -next] selinux: Fix memleak in security_read_policy

From: Paul Moore
Date: Wed Jun 15 2022 - 18:58:50 EST


On Wed, Jun 15, 2022 at 6:04 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote:
> On Wed, Jun 15, 2022 at 4:03 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
> > On Tue, Jun 14, 2022 at 9:25 AM Xiu Jianfeng <xiujianfeng@xxxxxxxxxx> wrote:
> > >
> > > In this function, it directly returns the result of __security_read_policy
> > > without freeing the allocated memory in *data, cause memory leak issue,
> > > so free the memory if __security_read_policy failed.
> > >
> > > Signed-off-by: Xiu Jianfeng <xiujianfeng@xxxxxxxxxx>
> > > ---
> > > security/selinux/ss/services.c | 9 ++++++++-
> > > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > This is another case where there is not actually a memory leak as the
> > only caller of security_read_policy() is sel_open_policy() which will
> > free the buffer it passes to security_read_policy() on error.
> >
> > If you want you could add a comment to security_read_policy()
> > indicating that the caller is responsible for freeing the memory.
>
> Can we please not have two almost identical functions with different
> cleanup conventions? Please let's either make both functions guarantee
> cleanup on error or neither of them (adapting the caller(s) and
> comments accordingly).

Priorities Ondrej, priorities.

Every patch posted to the list has a time and effort cost associated
with it, and between reviewing other more important patches and
working on a proper SCTP/SELinux fix, I simply don't have the cycles
to spend doing the back-and-forth on a patch like this to fix a memory
leak that doesn't exist. It definitely isn't because I don't think
the code could be improved, it is just that there are only so many
hours in a day and I need to prioritize actual bugs and important new
features that people want merged.

... oh, and I need to reply to the complaints too, that's always the
highlight of my day.

--
paul-moore.com