Skip to contentSkip to conversation

FAILED: patch "[PATCH] cgroup-v1: Require capabilities to set release_agent" failed to apply to 4.9-stable tree

PATCH [email protected] 1 participant 2 messages Feb 4, 2022 – Feb 5, 2022 1 message not in the archive

Subsystems (2)
Stable branch cgroup
lore
Share & tools
lore

[email protected]

author maintainer
#0 lore raw

The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.

thanks,

greg k-h

------------------ original commit in Linus's tree ------------------

From 24f6008564183aa120d07c03d9289519c2fe02af Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <[email protected]>
Date: Thu, 20 Jan 2022 11:04:01 -0600
Subject: [PATCH] cgroup-v1: Require capabilities to set release_agent

The cgroup release_agent is called with call_usermodehelper. The function call_usermodehelper starts the release_agent with a full set fo capabilities. Therefore require capabilities when setting the release_agaent.

Reported-by Tabitha Sable <[email protected]>
Tested-by Tabitha Sable <[email protected]>
Fixes 81a6a5cdd2c5 ("Task Control Groups: automatic userspace notification of idle cgroups")
Cc [email protected] # v2.6.24+
Signed-off-by "Eric W. Biederman" <[email protected]>
Signed-off-by Tejun Heo <[email protected]>
kernel/cgroup/cgroup-v1.c +14 -0
index 41e0837a5a0b..0e877dbcfeea 100644
@@ -549,6 +549,14 @@ static ssize_t cgroup_release_agent_write(struct kernfs_open_file *of,
 
 	BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX);
 
+	/*
+	 * Release agent gets called with all capabilities,
+	 * require capabilities to set release agent.
+	 */
+	if ((of->file->f_cred->user_ns != &init_user_ns) ||
+	    !capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
 	cgrp = cgroup_kn_lock_live(of->kn, false);
 	if (!cgrp)
 		return -ENODEV;

@@ -954,6 +962,12 @@ int cgroup1_parse_param(struct fs_context *fc, struct fs_parameter *param)
 		/* Specifying two release agents is forbidden */
 		if (ctx->release_agent)
 			return invalfc(fc, "release_agent respecified");
+		/*
+		 * Release agent gets called with all capabilities,
+		 * require capabilities to set release agent.
+		 */
+		if ((fc->user_ns != &init_user_ns) || !capable(CAP_SYS_ADMIN))
+			return invalfc(fc, "Setting release_agent not allowed");
 		ctx->release_agent = param->string;
 		param->string = NULL;
 		break;

A message that is not in the archive (sent off-list or not yet received): CAM62SmKNsDeCQuU7CPtu-rZw_58Sb1d917ibWKYAG2yakNU80g@mail.gmail.com

author maintainer
#2 lore raw
Quoted 6 lines · Tabitha Sable

I'm happy to help with this, but I'm not familiar with the conventions for sending in backport diffs.

I've read through the docs on kernelnewbies and found them to be both overwhelmingly big and also not directly relevant to this particular situation. I think if I simply try to follow them I'll foul things up.

Yeah, it's not the same thing at all.

Quoted 3 lines

Can I simply make the changes against the appropriate git branch, build and test, and then email in the diff to [email protected] copying most of what you've put in the original email, greg?

Yes, that's exactly what we need here. Be sure to let me know what the git id of the commit is in Linus's tree so we can properly track it (you can put it in the changelog text somewhere.)

thanks,

greg k-h