Linux Security Modules development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
Cc: linux-security-module@vger.kernel.org
Subject: Re: [PATCH v4 9/9] pseries/plpks/wrapkey: expose PKWM wrapping key management to userspace via sysfs
Date: Sat, 17 Oct 2026 18:51:50 +0000	[thread overview]
Message-ID: <sashiko-outbox-175762@kernel.org> (raw)
In-Reply-To: <20261017183853.596052-10-ssrish@linux.ibm.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] powerpc/pseries/plpks: use-after-free of plpks_kobj in plpks_init_child_kobj()
- [Medium] powerpc/pseries: wrapkey_sysfs_init() does not ensure default key exists
--

commit 81ec5557b710c94f51afed01c64f4716ffcf0140
Author: Srish Srinivasan <ssrish@linux.ibm.com>

pseries/plpks/wrapkey: expose PKWM wrapping key management to userspace via sysfs

This commit adds a sysfs interface under /sys/firmware/plpks/wrapkey to allow
userspace to create, revoke, unrevoke, delete, and list PKWM wrapping keys by
label.

> diff --git a/Documentation/ABI/testing/sysfs-firmware-plpks b/Documentation/ABI/testing/sysfs-firmware-plpks
> index cba061e4eee2a..4144e868da1b1 100644
> --- a/Documentation/ABI/testing/sysfs-firmware-plpks
> +++ b/Documentation/ABI/testing/sysfs-firmware-plpks

[ ... ]

> +What:		/sys/firmware/plpks/wrapkey/list_active
> +Date:		August 2026
> +Contact:	Srish Srinivasan <ssrish@linux.ibm.com>
> +Description:	(RO) List the labels of active, non-revoked wrapping keys. The
> +		default wrapping key, named "default-wrapping-key", is always
> +		included in this list.
> +
> +		For example:
> +
> +			cat /sys/firmware/plpks/wrapkey/list_active

[ ... ]

> diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
> index 7d125e288f6ef..14d2eed4d881a 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -215,3 +215,18 @@ config PPC_SVM
>  	 those guests.
>  
>  	 If unsure, say "N".
> +
> +config PLPKS_WRAPKEY_SYSFS
> +	bool "Enable sysfs interface for managing PKWM wrapping keys"
> +	default n
> +	depends on PSERIES_PLPKS
> +	depends on SYSFS
> +	depends on TRUSTED_KEYS_PKWM
> +	help
> +	  The PKWM trusted source supports user-created wrapping keys that are
> +	  managed by the OS. These wrapping keys can be created, revoked,
> +	  unrevoked, and deleted through sysfs. Their labels can also be viewed
> +	  through sysfs.
> +
> +	  Say Y if PLPKS and PKWM are enabled and you want to isolate trusted
> +	  keys using user-created wrapping keys.

[ ... ]

> diff --git a/arch/powerpc/platforms/pseries/plpks-sysfs.c b/arch/powerpc/platforms/pseries/plpks-sysfs.c
> index f2436229f3233..0ca13bb6405f8 100644
> --- a/arch/powerpc/platforms/pseries/plpks-sysfs.c
> +++ b/arch/powerpc/platforms/pseries/plpks-sysfs.c
> @@ -55,6 +55,17 @@ static umode_t plpks_config_attr_is_visible(struct kobject *kobj,
>  	return attr->mode;
>  }
>  
> +int plpks_init_child_kobj(struct kobject *kobj, const struct kobj_type *ktype,
> +			  const char *name)
> +{
> +	kobject_init(kobj, ktype);
> +
> +	if (!plpks_kobj)
> +		return -ENODEV;
> +
> +	return kobject_add(kobj, plpks_kobj, "%s", name);
> +}
> +
>  int plpks_config_create_softlink(struct kobject *from)
>  {
>  	if (!plpks_config_kobj)

[Severity: Medium]
Can plpks_init_child_kobj() dereference a freed plpks_kobj if
plpks_sysfs_init() fails after creating plpks_kobj?

In arch/powerpc/platforms/pseries/plpks-sysfs.c:plpks_sysfs_init():

	plpks_config_kobj = kobject_create_and_add("config", plpks_kobj);
	if (!plpks_config_kobj) {
		pr_err("Failed to create plpks config kobj\n");
		kobject_put(plpks_kobj);
		return -ENOMEM;
	}

	rc = plpks_sysfs_config(plpks_config_kobj);
	if (rc) {
		pr_err("Failed to create attribute group for plpks config\n");
		kobject_put(plpks_config_kobj);
		kobject_put(plpks_kobj);
		return rc;
	}

If either of those steps fails during machine_subsys_initcall, kobject_put()
frees plpks_kobj without resetting the static pointer to NULL. When
wrapkey_sysfs_init() later runs at machine_late_initcall and calls
plpks_init_child_kobj(), the !plpks_kobj check passes and kobject_add()
operates on the dangling plpks_kobj pointer.

> diff --git a/arch/powerpc/platforms/pseries/plpks-wrapkey-sysfs.c b/arch/powerpc/platforms/pseries/plpks-wrapkey-sysfs.c
> new file mode 100644
> index 0000000000000..d810d6d64fb92
> --- /dev/null
> +++ b/arch/powerpc/platforms/pseries/plpks-wrapkey-sysfs.c

[ ... ]

> +static __init int wrapkey_sysfs_init(void)
> +{
> +	int rc;
> +
> +	if (!plpks_revoke_is_supported()) {
> +		pr_err("H_PKS_{UN}REVOKE_OBJECT interface not supported\n");
> +		return -ENODEV;
> +	}
> +
> +	wrapkey_kobj = kzalloc_obj(*wrapkey_kobj);
> +	if (!wrapkey_kobj)
> +		return -ENOMEM;
> +
> +	rc = plpks_init_child_kobj(wrapkey_kobj, &wrapkey_ktype, "wrapkey");
> +
> +	if (rc) {
> +		kobject_put(wrapkey_kobj);
> +		wrapkey_kobj = NULL;
> +	}
> +
> +	return rc;
> +}
> +
> +machine_late_initcall(pseries, wrapkey_sysfs_init);

[Severity: Medium]
Is "default-wrapping-key" guaranteed to exist in PLPKS when
wrapkey_sysfs_init() exposes /sys/firmware/plpks/wrapkey?

Both the commit message and Documentation/ABI/testing/sysfs-firmware-plpks
state that "default-wrapping-key" is always included in list_active, and
create_store() rejects "default-wrapping-key" with -EEXIST.

However, "default-wrapping-key" is only generated in
security/keys/trusted-keys/trusted_pkwm.c:trusted_pkwm_init():

	var = (struct plpks_var) {
		.name = (u8 *)PLPKS_DEFAULT_WRAPKEY_LABEL,
		.namelen = sizeof(PLPKS_DEFAULT_WRAPKEY_LABEL) - 1,
		.policy = PLPKS_WRAPPINGKEY,
		.os = PLPKS_VAR_LINUX,
		.component = PLPKS_WRAPKEY_COMPONENT
	};

	ret = plpks_gen_wrapping_key(&var);

Because CONFIG_PLPKS_WRAPKEY_SYSFS is a bool while CONFIG_TRUSTED_KEYS is
tristate, wrapkey_sysfs_init() runs at machine_late_initcall even when
trusted.ko has not been loaded, or when init_trusted() selects another
trusted key source (such as TPM) earlier in trusted_key_sources[]. On a fresh
LPAR where trusted_pkwm_init() has not run, won't reading list_active omit
"default-wrapping-key" while writing "default-wrapping-key" to create fails
with -EEXIST?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261017183853.596052-1-ssrish@linux.ibm.com?part=9

      reply	other threads:[~2026-10-17 18:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17 18:38 [PATCH v4 0/9] Extend PKWM to support user-created wrapping keys Srish Srinivasan
2026-10-17 18:38 ` [PATCH v4 1/9] pseries/plpks: fix double conversion of write and remove flush errors Srish Srinivasan
2026-10-17 18:43   ` sashiko-bot
2026-10-17 18:38 ` [PATCH v4 2/9] pseries/plpks: fix double conversion of wrapping key " Srish Srinivasan
2026-10-17 18:42   ` sashiko-bot
2026-10-17 18:38 ` [PATCH v4 3/9] pseries/plpks: fix length types for wrapping operations Srish Srinivasan
2026-10-17 18:49   ` sashiko-bot
2026-10-17 18:38 ` [PATCH v4 4/9] keys/trusted_keys: propagate wrapping key generation errors Srish Srinivasan
2026-10-17 18:43   ` sashiko-bot
2026-10-17 18:38 ` [PATCH v4 5/9] keys/trusted_keys: fix PKWM output buffer cleanup Srish Srinivasan
2026-10-17 18:43   ` sashiko-bot
2026-10-17 18:38 ` [PATCH v4 6/9] keys/trusted_keys: clear sensitive PKWM buffers Srish Srinivasan
2026-10-17 18:42   ` sashiko-bot
2026-10-17 18:38 ` [PATCH v4 7/9] pseries/plpks: add HCALLs for PKWM wrapping key life cycle management Srish Srinivasan
2026-10-17 18:54   ` sashiko-bot
2026-10-17 18:38 ` [PATCH v4 8/9] keys/trusted_keys: enable PKWM wrapping key selection by label Srish Srinivasan
2026-10-17 18:44   ` sashiko-bot
2026-10-17 18:38 ` [PATCH v4 9/9] pseries/plpks/wrapkey: expose PKWM wrapping key management to userspace via sysfs Srish Srinivasan
2026-10-17 18:51   ` sashiko-bot [this message]

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-175762@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox