diff options
| author | Alexander Polakov <apolyakov@beget.ru> | 2016-10-27 17:46:27 -0700 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2016-11-10 16:36:32 +0100 |
| commit | 9fa32e04f8107af05d6d557a27a4687ec02ff6e5 (patch) | |
| tree | 0f95749a83e772e8439465eeeabc92dd3ab0882d | |
| parent | fd9e4cea96df8dc759ce32fb5d1677d781caf244 (diff) | |
| download | linux-stable-9fa32e04f8107af05d6d557a27a4687ec02ff6e5.tar.gz linux-stable-9fa32e04f8107af05d6d557a27a4687ec02ff6e5.tar.bz2 linux-stable-9fa32e04f8107af05d6d557a27a4687ec02ff6e5.zip | |
mm/list_lru.c: avoid error-path NULL pointer deref
commit 1bc11d70b5db7c6bb1414b283d7f09b1fe1ac0d0 upstream.
As described in https://bugzilla.kernel.org/show_bug.cgi?id=177821:
After some analysis it seems to be that the problem is in alloc_super().
In case list_lru_init_memcg() fails it goes into destroy_super(), which
calls list_lru_destroy().
And in list_lru_init() we see that in case memcg_init_list_lru() fails,
lru->node is freed, but not set NULL, which then leads list_lru_destroy()
to believe it is initialized and call memcg_destroy_list_lru().
memcg_destroy_list_lru() in turn can access lru->node[i].memcg_lrus,
which is NULL.
[akpm@linux-foundation.org: add comment]
Signed-off-by: Alexander Polakov <apolyakov@beget.ru>
Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| -rw-r--r-- | mm/list_lru.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/mm/list_lru.c b/mm/list_lru.c index afc71ea9a381..5d8dffd5b57c 100644 --- a/mm/list_lru.c +++ b/mm/list_lru.c @@ -554,6 +554,8 @@ int __list_lru_init(struct list_lru *lru, bool memcg_aware, err = memcg_init_list_lru(lru, memcg_aware); if (err) { kfree(lru->node); + /* Do this so a list_lru_destroy() doesn't crash: */ + lru->node = NULL; goto out; } |