All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, "ast@kernel.org, daniel@iogearbox.net,
	stable@vger.kernel.org, Yonghong Song" <yhs@fb.com>,
	Mathieu Malaterre <malat@debian.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Yonghong Song <yhs@fb.com>
Subject: [PATCH 4.14 2/9] bpf: fix memory leak in lpm_trie map_free callback function
Date: Fri,  9 Mar 2018 16:19:07 -0800	[thread overview]
Message-ID: <20180310001828.656537139@linuxfoundation.org> (raw)
In-Reply-To: <20180310001828.476933393@linuxfoundation.org>

4.14-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Yonghong Song <yhs@fb.com>

[ upstream commit 9a3efb6b661f71d5675369ace9257833f0e78ef3 ]

There is a memory leak happening in lpm_trie map_free callback
function trie_free. The trie structure itself does not get freed.

Also, trie_free function did not do synchronize_rcu before freeing
various data structures. This is incorrect as some rcu_read_lock
region(s) for lookup, update, delete or get_next_key may not complete yet.
The fix is to add synchronize_rcu in the beginning of trie_free.
The useless spin_lock is removed from this function as well.

Fixes: b95a5c4db09b ("bpf: add a longest prefix match trie map implementation")
Reported-by: Mathieu Malaterre <malat@debian.org>
Reported-by: Alexei Starovoitov <ast@kernel.org>
Tested-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 kernel/bpf/lpm_trie.c |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/kernel/bpf/lpm_trie.c
+++ b/kernel/bpf/lpm_trie.c
@@ -470,7 +470,10 @@ static void trie_free(struct bpf_map *ma
 	struct lpm_trie_node __rcu **slot;
 	struct lpm_trie_node *node;
 
-	raw_spin_lock(&trie->lock);
+	/* Wait for outstanding programs to complete
+	 * update/lookup/delete/get_next_key and free the trie.
+	 */
+	synchronize_rcu();
 
 	/* Always start at the root and walk down to a node that has no
 	 * children. Then free that node, nullify its reference in the parent
@@ -484,7 +487,7 @@ static void trie_free(struct bpf_map *ma
 			node = rcu_dereference_protected(*slot,
 					lockdep_is_held(&trie->lock));
 			if (!node)
-				goto unlock;
+				goto out;
 
 			if (rcu_access_pointer(node->child[0])) {
 				slot = &node->child[0];
@@ -502,8 +505,8 @@ static void trie_free(struct bpf_map *ma
 		}
 	}
 
-unlock:
-	raw_spin_unlock(&trie->lock);
+out:
+	kfree(trie);
 }
 
 static int trie_get_next_key(struct bpf_map *map, void *key, void *next_key)

  parent reply	other threads:[~2018-03-10  0:27 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-10  0:19 [PATCH 4.14 0/9] 4.14.26-stable review Greg Kroah-Hartman
2018-03-10  0:19 ` [PATCH 4.14 1/9] bpf: fix mlock precharge on arraymaps Greg Kroah-Hartman
2018-03-10  0:19 ` Greg Kroah-Hartman [this message]
2018-03-10  0:19 ` [PATCH 4.14 3/9] bpf: fix rcu lockdep warning for lpm_trie map_free callback Greg Kroah-Hartman
2018-03-10  0:19 ` [PATCH 4.14 4/9] bpf, x64: implement retpoline for tail call Greg Kroah-Hartman
2018-03-10  0:19 ` [PATCH 4.14 5/9] bpf, arm64: fix out of bounds access in " Greg Kroah-Hartman
2018-03-10  0:19 ` [PATCH 4.14 6/9] bpf: add schedule points in percpu arrays management Greg Kroah-Hartman
2018-03-10  0:19 ` [PATCH 4.14 7/9] bpf: allow xadd only on aligned memory Greg Kroah-Hartman
2018-03-10  0:19 ` [PATCH 4.14 8/9] bpf, ppc64: fix out of bounds access in tail call Greg Kroah-Hartman
2018-03-10  0:19 ` [PATCH 4.14 9/9] KVM: x86: fix backward migration with async_PF Greg Kroah-Hartman
2018-03-10  5:12 ` [PATCH 4.14 0/9] 4.14.26-stable review Shuah Khan
2018-03-10  7:19 ` kernelci.org bot
2018-03-10 15:45 ` Guenter Roeck
2018-03-12  9:52 ` Naresh Kamboju

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=20180310001828.656537139@linuxfoundation.org \
    --to=gregkh@linuxfoundation.org \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=malat@debian.org \
    --cc=stable@vger.kernel.org \
    --cc=yhs@fb.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.