All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Albert Esteve" <aesteve@redhat.com>, "Tejun Heo" <tj@kernel.org>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Michal Koutný" <mkoutny@suse.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Michal Hocko" <mhocko@kernel.org>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Shakeel Butt" <shakeel.butt@linux.dev>,
	"Muchun Song" <muchun.song@linux.dev>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Brian Starkey" <Brian.Starkey@arm.com>,
	"John Stultz" <jstultz@google.com>,
	"T.J. Mercier" <tjmercier@google.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Paul Moore" <paul@paul-moore.com>,
	"James Morris" <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"Stephen Smalley" <stephen.smalley.work@gmail.com>,
	"Shuah Khan" <shuah@kernel.org>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Ondrej Mosnáček" <omosnacek@gmail.com>,
	"Jens Wiklander" <jenswi@kernel.org>,
	"Sumit Garg" <sumit.garg@kernel.org>
Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
	op-tee@lists.trustedfirmware.org, media-ci@linuxtv.org
Subject: Re: [PATCH v4 7/8] selinux: Restrict dma-buf direct cgroup charging
Date: Thu, 05 Nov 2026 11:12:03 +0000	[thread overview]
Message-ID: <sashiko-outbox-198922@kernel.org> (raw)
In-Reply-To: <20261104-v2_20230123_tjmercier_google_com-v4-7-1819a017000b@redhat.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] selinux: selinux_dma_buf_charge_cgroup() bypasses check on genfscon cgroups
- [Medium] selinux: one-off dma_buf charge_cgroup lacks broader cgroup control design
--

commit d0dd0ed1dd84ec5c8f4de9a298a749d83668b53e
Author: Albert Esteve <aesteve@redhat.com>

selinux: Restrict dma-buf direct cgroup charging

This commit implements the selinux_dma_buf_charge_cgroup() hook and adds the
charge_cgroup permission to the dma_buf security class to restrict which
processes can charge dma-buf memory to a target cgroup.

> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 8f39d91eabc97..2f99eaa910af4 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2210,6 +2210,40 @@ static int selinux_dma_buf_charge_task(const struct cred *from, const struct cre
>  			    SECCLASS_DMA_BUF, DMA_BUF__CHARGE_TASK, NULL);
>  }
>  
> +#ifdef CONFIG_CGROUPS
> +static int selinux_dma_buf_charge_cgroup(const struct cred *cred, struct cgroup *cgrp)
> +{
> +	u32 cgrp_sid, clen;
> +	int rc;
> +	char *context;
> +
> +	rc = kernfs_xattr_get(cgrp->kn, XATTR_NAME_SELINUX, NULL, 0);
> +	if (rc == -ENODATA)
> +		return 0;

[Severity: High]
As reported by Sashiko on v3 [1], in security/selinux/hooks.c, does returning
0 in selinux_dma_buf_charge_cgroup() when kernfs_xattr_get() returns -ENODATA
bypass the permission check for all default-labeled cgroups?

When a process calls ioctl(DMA_HEAP_IOCTL_ALLOC) or
ioctl(DMA_BUF_IOCTL_XFER_CHARGE) with a charge_fd referencing a cgroup
directory, mem_cgroup_get_from_fd() invokes security_dma_buf_charge_cgroup()
-> selinux_dma_buf_charge_cgroup().

In SELinux, cgroup and cgroup2 filesystems are configured with
SE_SBGENFS | SE_SBGENFS_XATTR in selinux_set_mnt_opts() and obtain their
default label (such as cgroup_t) from policy genfscon rules. When a cgroupfs
VFS inode is initialized in inode_doinit_with_dentry(), SELinux computes the
default SID via selinux_genfs_get_sid() and only uses kernfs xattrs as an
optional override:

security/selinux/hooks.c:inode_doinit_with_dentry() {
    ...
			rc = selinux_genfs_get_sid(dentry, sclass,
						   sbsec->flags, &sid);
			if (rc) {
				dput(dentry);
				goto out;
			}

			if ((sbsec->flags & SE_SBGENFS_XATTR) &&
			    (inode->i_opflags & IOP_XATTR)) {
				rc = inode_doinit_use_xattr(inode, dentry,
							    sid, &sid);
    ...
}

When no explicit setxattr() has been performed on the cgroup directory,
inode_doinit_use_xattr() gets -ENODATA and falls back to def_sid in memory
without writing any security.selinux xattr to cgrp->kn:

security/selinux/hooks.c:inode_doinit_use_xattr() {
    ...
	if (rc < 0) {
		kfree(context);
		if (rc != -ENODATA) {
			pr_warn("SELinux: %s:  getxattr returned %d for dev=%s ino=%llu\n",
				__func__, -rc, inode->i_sb->s_id, inode->i_ino);
			return rc;
		}
		*sid = def_sid;
		return 0;
	}
    ...
}

Similarly, selinux_kernfs_init_security() sees -ENODATA on the parent node
and returns 0 without setting an xattr on child cgroup nodes, and if the
cgroup_seclabel policy capability is not enabled, security.selinux xattrs
cannot be set on cgroup directories at all.

Because kernfs_xattr_get(cgrp->kn, XATTR_NAME_SELINUX, NULL, 0) returns
-ENODATA for every cgroup that has not been manually relabeled via
setxattr(), won't selinux_dma_buf_charge_cgroup() skip avc_has_perm() for all
default-labeled cgroup_t cgroups and render policy rules like
"allow allocator_app_t cgroup_t:dma_buf charge_cgroup;" ineffective?

[ ... ]

> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index b4ebedc6e4240..90d1e04c3d27c 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -181,7 +181,7 @@ const struct security_class_mapping secclass_map[] = {
>  	{ "user_namespace", { "create", NULL } },
>  	{ "memfd_file",
>  	  { COMMON_FILE_PERMS, "execute_no_trans", "entrypoint", NULL } },
> -	{ "dma_buf", { "charge_task", NULL } },
> +	{ "dma_buf", { "charge_task", "charge_cgroup", NULL } },

[Severity: Medium]
As reported by Paul Moore on RFC [2], in security/selinux/include/classmap.h
(secclass_map) and security/selinux/hooks.c (selinux_dma_buf_charge_cgroup()),
this adds a narrow dma_buf class permission for cgroup charging invoked from
DMA_HEAP_IOCTL_ALLOC and DMA_BUF_IOCTL_XFER_CHARGE via
mem_cgroup_get_from_fd() -> security_dma_buf_charge_cgroup().

Rather than introducing a one-off dma_buf cgroup charging permission, should
this be part of a broader SELinux access control design covering existing
cgroup control points so that the object class and permission model is
consistent across cgroup operations?

[1] https://lore.kernel.org/r/20261027-v2_20230123_tjmercier_google_com-v3-6-78d2c4cb8647@redhat.com
[2] https://lore.kernel.org/r/16093a0278a6d7d1a0a8bc055c228bed@paul-moore.com

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261104-v2_20230123_tjmercier_google_com-v4-0-1819a017000b@redhat.com?part=7


WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot--- via OP-TEE <op-tee@lists.trustedfirmware.org>
To: "Albert Esteve" <aesteve@redhat.com>, "Tejun Heo" <tj@kernel.org>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	"Michal Koutný" <mkoutny@suse.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	"Sumit Semwal" <sumit.semwal@linaro.org>,
	"Christian König" <christian.koenig@amd.com>,
	"Michal Hocko" <mhocko@kernel.org>,
	"Roman Gushchin" <roman.gushchin@linux.dev>,
	"Shakeel Butt" <shakeel.butt@linux.dev>,
	"Muchun Song" <muchun.song@linux.dev>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	"Brian Starkey" <Brian.Starkey@arm.com>,
	"John Stultz" <jstultz@google.com>,
	"T.J. Mercier" <tjmercier@google.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Paul Moore" <paul@paul-moore.com>,
	"James Morris" <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	"Stephen Smalley" <stephen.smalley.work@gmail.com>,
	"Shuah Khan" <shuah@kernel.org>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Ondrej Mosnáček" <omosnacek@gmail.com>,
	"Jens Wiklander" <jenswi@kernel.org>,
	"Sumit Garg" <sumit.garg@kernel.org>
Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
	op-tee@lists.trustedfirmware.org, media-ci@linuxtv.org
Subject: Re: [PATCH v4 7/8] selinux: Restrict dma-buf direct cgroup charging
Date: Thu, 05 Nov 2026 11:12:03 +0000	[thread overview]
Message-ID: <sashiko-outbox-198922@kernel.org> (raw)
In-Reply-To: <20261104-v2_20230123_tjmercier_google_com-v4-7-1819a017000b@redhat.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] selinux: selinux_dma_buf_charge_cgroup() bypasses check on genfscon cgroups
- [Medium] selinux: one-off dma_buf charge_cgroup lacks broader cgroup control design
--

commit d0dd0ed1dd84ec5c8f4de9a298a749d83668b53e
Author: Albert Esteve <aesteve@redhat.com>

selinux: Restrict dma-buf direct cgroup charging

This commit implements the selinux_dma_buf_charge_cgroup() hook and adds the
charge_cgroup permission to the dma_buf security class to restrict which
processes can charge dma-buf memory to a target cgroup.

> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 8f39d91eabc97..2f99eaa910af4 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2210,6 +2210,40 @@ static int selinux_dma_buf_charge_task(const struct cred *from, const struct cre
>  			    SECCLASS_DMA_BUF, DMA_BUF__CHARGE_TASK, NULL);
>  }
>  
> +#ifdef CONFIG_CGROUPS
> +static int selinux_dma_buf_charge_cgroup(const struct cred *cred, struct cgroup *cgrp)
> +{
> +	u32 cgrp_sid, clen;
> +	int rc;
> +	char *context;
> +
> +	rc = kernfs_xattr_get(cgrp->kn, XATTR_NAME_SELINUX, NULL, 0);
> +	if (rc == -ENODATA)
> +		return 0;

[Severity: High]
As reported by Sashiko on v3 [1], in security/selinux/hooks.c, does returning
0 in selinux_dma_buf_charge_cgroup() when kernfs_xattr_get() returns -ENODATA
bypass the permission check for all default-labeled cgroups?

When a process calls ioctl(DMA_HEAP_IOCTL_ALLOC) or
ioctl(DMA_BUF_IOCTL_XFER_CHARGE) with a charge_fd referencing a cgroup
directory, mem_cgroup_get_from_fd() invokes security_dma_buf_charge_cgroup()
-> selinux_dma_buf_charge_cgroup().

In SELinux, cgroup and cgroup2 filesystems are configured with
SE_SBGENFS | SE_SBGENFS_XATTR in selinux_set_mnt_opts() and obtain their
default label (such as cgroup_t) from policy genfscon rules. When a cgroupfs
VFS inode is initialized in inode_doinit_with_dentry(), SELinux computes the
default SID via selinux_genfs_get_sid() and only uses kernfs xattrs as an
optional override:

security/selinux/hooks.c:inode_doinit_with_dentry() {
    ...
			rc = selinux_genfs_get_sid(dentry, sclass,
						   sbsec->flags, &sid);
			if (rc) {
				dput(dentry);
				goto out;
			}

			if ((sbsec->flags & SE_SBGENFS_XATTR) &&
			    (inode->i_opflags & IOP_XATTR)) {
				rc = inode_doinit_use_xattr(inode, dentry,
							    sid, &sid);
    ...
}

When no explicit setxattr() has been performed on the cgroup directory,
inode_doinit_use_xattr() gets -ENODATA and falls back to def_sid in memory
without writing any security.selinux xattr to cgrp->kn:

security/selinux/hooks.c:inode_doinit_use_xattr() {
    ...
	if (rc < 0) {
		kfree(context);
		if (rc != -ENODATA) {
			pr_warn("SELinux: %s:  getxattr returned %d for dev=%s ino=%llu\n",
				__func__, -rc, inode->i_sb->s_id, inode->i_ino);
			return rc;
		}
		*sid = def_sid;
		return 0;
	}
    ...
}

Similarly, selinux_kernfs_init_security() sees -ENODATA on the parent node
and returns 0 without setting an xattr on child cgroup nodes, and if the
cgroup_seclabel policy capability is not enabled, security.selinux xattrs
cannot be set on cgroup directories at all.

Because kernfs_xattr_get(cgrp->kn, XATTR_NAME_SELINUX, NULL, 0) returns
-ENODATA for every cgroup that has not been manually relabeled via
setxattr(), won't selinux_dma_buf_charge_cgroup() skip avc_has_perm() for all
default-labeled cgroup_t cgroups and render policy rules like
"allow allocator_app_t cgroup_t:dma_buf charge_cgroup;" ineffective?

[ ... ]

> diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> index b4ebedc6e4240..90d1e04c3d27c 100644
> --- a/security/selinux/include/classmap.h
> +++ b/security/selinux/include/classmap.h
> @@ -181,7 +181,7 @@ const struct security_class_mapping secclass_map[] = {
>  	{ "user_namespace", { "create", NULL } },
>  	{ "memfd_file",
>  	  { COMMON_FILE_PERMS, "execute_no_trans", "entrypoint", NULL } },
> -	{ "dma_buf", { "charge_task", NULL } },
> +	{ "dma_buf", { "charge_task", "charge_cgroup", NULL } },

[Severity: Medium]
As reported by Paul Moore on RFC [2], in security/selinux/include/classmap.h
(secclass_map) and security/selinux/hooks.c (selinux_dma_buf_charge_cgroup()),
this adds a narrow dma_buf class permission for cgroup charging invoked from
DMA_HEAP_IOCTL_ALLOC and DMA_BUF_IOCTL_XFER_CHARGE via
mem_cgroup_get_from_fd() -> security_dma_buf_charge_cgroup().

Rather than introducing a one-off dma_buf cgroup charging permission, should
this be part of a broader SELinux access control design covering existing
cgroup control points so that the object class and permission model is
consistent across cgroup operations?

[1] https://lore.kernel.org/r/20261027-v2_20230123_tjmercier_google_com-v3-6-78d2c4cb8647@redhat.com
[2] https://lore.kernel.org/r/16093a0278a6d7d1a0a8bc055c228bed@paul-moore.com

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261104-v2_20230123_tjmercier_google_com-v4-0-1819a017000b@redhat.com?part=7

  reply	other threads:[~2026-11-05 11:12 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-04 11:09 [PATCH v4 0/8] memcg: dma-buf cgroup accounting and charge transfer Albert Esteve via OP-TEE
2026-11-04 11:09 ` Albert Esteve
2026-11-04 11:09 ` [PATCH v4 1/8] memcg: Add MEMCG_DMABUF accounting infrastructure Albert Esteve via OP-TEE
2026-11-04 11:09   ` Albert Esteve
2026-11-05 11:11   ` sashiko-bot
2026-11-05 11:11     ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 2/8] dma-heap: charge dma-buf memory via explicit memcg Albert Esteve via OP-TEE
2026-11-04 11:09   ` Albert Esteve
2026-11-05 11:11   ` sashiko-bot
2026-11-05 11:11     ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 3/8] dma-buf: transfer memcg charges via DMA_BUF_IOCTL_XFER_CHARGE Albert Esteve via OP-TEE
2026-11-04 11:09   ` Albert Esteve
2026-11-04 13:51   ` Christian König
2026-11-04 13:51     ` Christian König via OP-TEE
2026-11-05 11:11   ` sashiko-bot
2026-11-05 11:11     ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 4/8] security: dma-buf: Add dma_buf_charge_task LSM hook Albert Esteve via OP-TEE
2026-11-04 11:09   ` Albert Esteve
2026-11-05 11:11   ` sashiko-bot
2026-11-05 11:11     ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 5/8] security: dma-buf: Add dma_buf_charge_cgroup " Albert Esteve via OP-TEE
2026-11-04 11:09   ` Albert Esteve
2026-11-05 11:12   ` sashiko-bot
2026-11-04 11:09 ` [PATCH v4 6/8] selinux: Restrict cross-cgroup dma-buf charging Albert Esteve via OP-TEE
2026-11-04 11:09   ` Albert Esteve
2026-11-05 11:12   ` sashiko-bot
2026-11-05 11:12     ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 7/8] selinux: Restrict dma-buf direct cgroup charging Albert Esteve via OP-TEE
2026-11-04 11:09   ` Albert Esteve
2026-11-05 11:12   ` sashiko-bot [this message]
2026-11-05 11:12     ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 8/8] selftests/dmabuf-heaps: Add dma-buf memcg accounting tests Albert Esteve via OP-TEE
2026-11-04 11:09   ` Albert Esteve
2026-11-05 11:12   ` sashiko-bot
2026-11-05 11:12     ` sashiko-bot--- via OP-TEE

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=sashiko-outbox-198922@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Brian.Starkey@arm.com \
    --cc=aesteve@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=benjamin.gaignard@collabora.com \
    --cc=brauner@kernel.org \
    --cc=christian.koenig@amd.com \
    --cc=corbet@lwn.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hannes@cmpxchg.org \
    --cc=jenswi@kernel.org \
    --cc=jmorris@namei.org \
    --cc=jstultz@google.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=media-ci@linuxtv.org \
    --cc=mhocko@kernel.org \
    --cc=mkoutny@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=omosnacek@gmail.com \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=paul@paul-moore.com \
    --cc=rdunlap@infradead.org \
    --cc=roman.gushchin@linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=shakeel.butt@linux.dev \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=sumit.garg@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=tj@kernel.org \
    --cc=tjmercier@google.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.