Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Sasha Levin <Alexander.Levin@microsoft.com>
To:     "stable@vger.kernel.org" <stable@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
CC:     Eric Biggers <ebiggers@google.com>,
        David Howells <dhowells@redhat.com>,
        James Morris <james.l.morris@oracle.com>,
        Sasha Levin <Alexander.Levin@microsoft.com>
Subject: [PATCH AUTOSEL for 4.9 019/293] KEYS: put keyring if
 install_session_keyring_to_cred() fails
Thread-Topic: [PATCH AUTOSEL for 4.9 019/293] KEYS: put keyring if
 install_session_keyring_to_cred() fails
Thread-Index: AQHTz5jtGnmuQfwfeEKEfBg5kJRIXA==
Date:   Mon, 9 Apr 2018 00:23:04 +0000
Message-ID: <20180409002239.163177-19-alexander.levin@microsoft.com>
References: <20180409002239.163177-1-alexander.levin@microsoft.com>
In-Reply-To: <20180409002239.163177-1-alexander.levin@microsoft.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: microsoft.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: e15ddc76-bd9c-4377-e724-08d59db090e1
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2018 00:23:04.6435
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0885
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Eric Biggers <ebiggers@google.com>

[ Upstream commit d636bd9f12a66ea3775c9fabbf3f8e118253467a ]

In join_session_keyring(), if install_session_keyring_to_cred() were to
fail, we would leak the keyring reference, just like in the bug fixed by
commit 23567fd052a9 ("KEYS: Fix keyring ref leak in
join_session_keyring()").  Fortunately this cannot happen currently, but
we really should be more careful.  Do this by adding and using a new
error label at which the keyring reference is dropped.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
---
 security/keys/process_keys.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
index 2d35d71d7d9a..88c94e6c2158 100644
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -810,15 +810,14 @@ long join_session_keyring(const char *name)
 		ret =3D PTR_ERR(keyring);
 		goto error2;
 	} else if (keyring =3D=3D new->session_keyring) {
-		key_put(keyring);
 		ret =3D 0;
-		goto error2;
+		goto error3;
 	}
=20
 	/* we've got a keyring - now to install it */
 	ret =3D install_session_keyring_to_cred(new, keyring);
 	if (ret < 0)
-		goto error2;
+		goto error3;
=20
 	commit_creds(new);
 	mutex_unlock(&key_session_mutex);
@@ -828,6 +827,8 @@ long join_session_keyring(const char *name)
 okay:
 	return ret;
=20
+error3:
+	key_put(keyring);
 error2:
 	mutex_unlock(&key_session_mutex);
 error:
--=20
2.15.1