linux-kernel - [RFC PATCH] kobject: Clean up allocated memory on failure

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: <20190516000716.24249-1-tobin@kernel.org>
Date:   Thu, 16 May 2019 10:07:16 +1000
From:   "Tobin C. Harding" <tobin@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     "Tobin C. Harding" <tobin@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: [RFC PATCH] kobject: Clean up allocated memory on failure

Currently kobject_add_varg() calls kobject_set_name_vargs() then returns
the return value of kobject_add_internal().  kobject_set_name_vargs()
allocates memory for the name string.  When kobject_add_varg() returns
an error we do not know if memory was allocated or not.  If we check the
return value of kobject_add_internal() instead of returning it directly
we can free the allocated memory if kobject_add_internal() fails.  Doing
this means that we now know that if kobject_add_varg() fails we do not
have to do any clean up, this benefit goes back up the call chain
meaning that we now do not need to do any cleanup if kobject_del()
fails.  Moving further back (in a theoretical kobject user callchain)
this means we now no longer need to call kobject_put() after calling
kobject_init_and_add(), we can just call kfree() on the enclosing
structure.  This makes the kobject API better follow the principle of
least surprise.

Check return value of kobject_add_internal() and free previously
allocated memory on failure.

Signed-off-by: Tobin C. Harding <tobin@...nel.org>
---

Hi Greg,

Pretty excited by this one, if this is correct it means that kobject
initialisation code, in the error path, can now use either kobject_put()
(to trigger the release method) OR kfree().  This means most of the
call sites of kobject_init_and_add() will get fixed for free!

I've been wrong before so I'll state here that this is based on the
assumption that kobject_init() does nothing that causes leaked memory.
This is _not_ what the function docs in kobject.c say but it _is_ what
the code seems to say since kobject_init() does nothing except
initialise kobject data member values?  Or have I got the dog by the
tail?

thanks,
Tobin.

 lib/kobject.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/lib/kobject.c b/lib/kobject.c
index f2ccdbac8ed9..bb0c0d374b13 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -387,7 +387,15 @@ static __printf(3, 0) int kobject_add_varg(struct kobject *kobj,
 		return retval;
 	}
 	kobj->parent = parent;
-	return kobject_add_internal(kobj);
+	retval = kobject_add_internal(kobj);
+
+	if (retval) {
+		if (kobj->name)
+			kfree_const(kobj->name);
+
+		return retval;
+	}
+	return 0;
 }

 /**
-- 
2.21.0