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
prev parent 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