From: Harald Freudenberger freude@linux.ibm.com
[ Upstream commit 11aa54ba4cfa5390ea47c9a1fc62502abce1f6b9 ]
The pkey ioctl PKEY_CLR2SECK2 describes in the pkey.h header file the parameter 'keygenflags' which is forwarded to the handler functions which actually deal with the clear key to secure key operation. The ep11 handler module function ep11_clr2keyblob() function receives this parameter but does not forward it to the underlying function ep11_unwrapkey() on invocation. So in the end the user of this ioctl could not forward additional key generation flags to the ep11 implementation and thus was unable to modify the key generation process in any way. So now call ep11_unwrapkey() with the real keygenflags instead of 0 and thus the user of this ioctl can for example via keygenflags provide valid combinations of XCP_BLOB_* flags.
Suggested-by: Ingo Franzki ifranzki@linux.ibm.com Signed-off-by: Harald Freudenberger freude@linux.ibm.com Reviewed-by: Ingo Franzki ifranzki@linux.ibm.com Signed-off-by: Alexander Gordeev agordeev@linux.ibm.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
## BACKPORT RECOMMENDATION: **YES**
## EXTENSIVE ANALYSIS
### Bug Description and Impact
This commit fixes a **functional bug** in the s390 pkey subsystem where the `keygenflags` parameter provided by users through the `PKEY_CLR2SECK2` ioctl is ignored and not forwarded to the underlying EP11 implementation.
**Specific Code Change Analysis** (drivers/s390/crypto/zcrypt_ep11misc.c:1406-1408):
The bug is at line 1408 in the `ep11_clr2keyblob()` function, where `ep11_unwrapkey()` is called. The problematic code was: ```c rc = ep11_unwrapkey(card, domain, kek, keklen, encbuf, encbuflen, 0, def_iv, keybitsize, 0, keybuf, keybufsize, keytype, xflags); ^^ Hardcoded 0 instead of keygenflags parameter ```
The fix changes this to: ```c rc = ep11_unwrapkey(card, domain, kek, keklen, encbuf, encbuflen, 0, def_iv, keybitsize, keygenflags, keybuf, keybufsize, keytype, xflags); ```
### User Impact Analysis
**What Users Cannot Do (Before Fix):** 1. **Cannot customize EP11 AES key attributes** - Users calling PKEY_CLR2SECK2 ioctl cannot specify custom XCP_BLOB_* flags (e.g., XCP_BLOB_ENCRYPT, XCP_BLOB_DECRYPT, XCP_BLOB_PROTKEY_EXTRACTABLE combinations) 2. **Stuck with default attributes** - All generated keys use the hardcoded defaults (0x00200c00 = XCP_BLOB_ENCRYPT | XCP_BLOB_DECRYPT | XCP_BLOB_PROTKEY_EXTRACTABLE) 3. **API version selection may be suboptimal** - The EP11 API version selection in `_ep11_unwrapkey()` (zcrypt_ep11misc.c:1100-1101) depends on keygenflags, and passing 0 always selects EP11_API_V4
**What the Fix Enables:** - Users can now properly control key generation attributes via the documented PKEY_CLR2SECK2 ioctl interface - Correct API version selection based on user-provided flags - Full functionality as documented in arch/s390/include/uapi/asm/pkey.h:290-292
### Historical Context
**Bug Introduction:** Commit 55d0a513a0e202 (December 6, 2019) - "s390/pkey/zcrypt: Support EP11 AES secure keys" - This was a major feature addition (1007 insertions) that added EP11 AES secure key support - The bug existed from day one - the keygenflags parameter was received but never forwarded - **Bug age: Nearly 6 years** (2019-12-06 to 2025-08-13) - **Affected versions: v5.10 onwards** (all stable kernels from v5.10 to v6.17+)
**Similar Bug Pattern:** Commit deffa48fb014f (August 29, 2019) fixed an identical issue for CCA cipher keys where keygenflags were not handled correctly, showing this is a recurring pattern in the s390 crypto subsystem.
### Backport Suitability Assessment
**✓ Fixes Important User-Visible Bug:** - YES - Breaks documented ioctl interface functionality - Users cannot access advertised EP11 key generation customization features
**✓ Small and Contained Change:** - YES - Only **1 functional line changed** (passing keygenflags instead of 0) - Additional changes are just code reformatting (line breaks for readability) - Change is in drivers/s390/crypto/zcrypt_ep11misc.c:1408 only
**✓ Minimal Regression Risk:** - **VERY LOW RISK** - The change makes the code do what it was supposed to do from the beginning - Forwards an existing parameter that was already being received but ignored - No new code paths introduced - No changes to data structures or API signatures - Default behavior preserved (when keygenflags=0, defaults are still used via ternary in _ep11_unwrapkey)
**✓ No Architectural Changes:** - YES - Pure parameter forwarding fix - No changes to subsystem architecture
**✓ Confined to Subsystem:** - YES - Only affects s390 pkey/zcrypt EP11 crypto subsystem - No cross-subsystem dependencies
**✗ Explicit Stable Tree Marking:** - NO "Cc: stable@vger.kernel.org" tag present - NO "Fixes:" tag present - However, this is likely an oversight given the clear bug fix nature
### Security Implications
**Low Security Risk, Potential Security Enhancement:** 1. **No new vulnerabilities introduced** - The fix enables intended functionality 2. **May improve security posture** - Users can now properly configure key attributes like encryption/decryption capabilities and extractability 3. **Restores documented interface contract** - Users get the security controls they were promised in the API
### Dependencies and Prerequisites
**No prerequisites identified:** - Function signature of `ep11_clr2keyblob()` has included keygenflags parameter since v5.10 - Function signature of `ep11_unwrapkey()` has included keygenflags parameter since v5.10 - No ABI changes - No new kernel features required - Clean application to stable trees expected
### Related Work
The fix commit (11aa54ba4cfa5390ea47c9a1fc62502abce1f6b9) was authored on 2025-08-13 and committed to mainline on 2025-08-28, making it very recent. It has already been backported to at least one stable tree (commit 6b78f84e140b4a3e with "Upstream commit" marker).
### Recommendation Summary
This commit is an **excellent candidate for backporting** to stable kernel trees because:
1. ✅ Fixes a clear, long-standing functional bug (6 years) 2. ✅ Extremely small, surgical change (1 line functional change) 3. ✅ Affects documented user-facing API (PKEY_CLR2SECK2 ioctl) 4. ✅ Zero architectural impact 5. ✅ Very low regression risk 6. ✅ Restores intended functionality without breaking existing users 7. ✅ Confined to s390 crypto subsystem 8. ✅ Follows stable tree best practices (important bugfix, minimal risk)
**Backport Target:** All stable trees containing the original bug (v5.10+, specifically kernels containing commit 55d0a513a0e202)
drivers/s390/crypto/zcrypt_ep11misc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/crypto/zcrypt_ep11misc.c b/drivers/s390/crypto/zcrypt_ep11misc.c index 3bf09a89a0894..e92e2fd8ce5da 100644 --- a/drivers/s390/crypto/zcrypt_ep11misc.c +++ b/drivers/s390/crypto/zcrypt_ep11misc.c @@ -1405,7 +1405,9 @@ int ep11_clr2keyblob(u16 card, u16 domain, u32 keybitsize, u32 keygenflags, /* Step 3: import the encrypted key value as a new key */ rc = ep11_unwrapkey(card, domain, kek, keklen, encbuf, encbuflen, 0, def_iv, - keybitsize, 0, keybuf, keybufsize, keytype, xflags); + keybitsize, keygenflags, + keybuf, keybufsize, + keytype, xflags); if (rc) { ZCRYPT_DBF_ERR("%s importing key value as new key failed, rc=%d\n", __func__, rc);