[PATCH v2] s390/cpacf: Unpoison instruction results

[PATCH v2] s390/cpacf: Unpoison instruction results

[Ilya Leoshkevich]

Stop KMSAN from complaining about CPACF outputs being uninitialized.

Do not unpoison variable-length parameter blocks: mapping function
codes (like CPACF_KIMD_SHA_256) to lengths is ugly. Let the callers
handle this once need arises.

Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
v1: https://lore.kernel.org/linux-s390/20260806190223.3292580-1-iii@linux.ibm.com/
v1 -> v2: Unpoison outputs of more instructions (Sashiko).

 arch/s390/include/asm/cpacf.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/s390/include/asm/cpacf.h b/arch/s390/include/asm/cpacf.h
index a83683169d98d..13d6a6344802a 100644
--- a/arch/s390/include/asm/cpacf.h
+++ b/arch/s390/include/asm/cpacf.h
@@ -301,6 +301,7 @@ static __always_inline void __cpacf_query(unsigned int opcode,
 					  cpacf_mask_t *mask)
 {
 	__cpacf_query_insn(opcode, mask, CPACF_FC_QUERY);
+	kmsan_unpoison_memory(mask, sizeof(*mask));
 }
 
 static __always_inline int __cpacf_check_opcode(unsigned int opcode)
@@ -370,6 +371,7 @@ static __always_inline int cpacf_query_func(unsigned int opcode,
 static __always_inline void __cpacf_qai(unsigned int opcode, cpacf_qai_t *qai)
 {
 	__cpacf_query_insn(opcode, qai, CPACF_FC_QUERY_AUTH_INFO);
+	kmsan_unpoison_memory(qai, sizeof(*qai));
 }
 
 /**
@@ -422,6 +424,7 @@ static inline int cpacf_km(unsigned long func, void *param,
 		  [opc] "i" (CPACF_KM)
 		: "cc", "memory", "0", "1");
 
+	kmsan_unpoison_memory(dest, src_len - s.odd);
 	return src_len - s.odd;
 }
 
@@ -454,6 +457,7 @@ static inline int cpacf_kmc(unsigned long func, void *param,
 		  [opc] "i" (CPACF_KMC)
 		: "cc", "memory", "0", "1");
 
+	kmsan_unpoison_memory(dest, src_len - s.odd);
 	return src_len - s.odd;
 }
 
@@ -587,6 +591,7 @@ static inline int cpacf_kmctr(unsigned long func, void *param, u8 *dest,
 		  [opc] "i" (CPACF_KMCTR)
 		: "cc", "memory", "0", "1");
 
+	kmsan_unpoison_memory(dest, src_len - s.odd);
 	return src_len - s.odd;
 }
 
@@ -619,6 +624,7 @@ static inline void cpacf_prno(unsigned long func, void *param,
 		: [fc] "d" (func), [pba] "d" ((unsigned long)param),
 		  [seed] "d" (s.pair), [opc] "i" (CPACF_PRNO)
 		: "cc", "memory", "0", "1");
+	kmsan_unpoison_memory(dest, dest_len);
 }
 
 /**
@@ -731,6 +737,7 @@ static inline void cpacf_kma(unsigned long func, void *param, u8 *dest,
 		: [fc] "d" (func), [pba] "d" ((unsigned long)param),
 		  [opc] "i" (CPACF_KMA)
 		: "cc", "memory", "0", "1");
+	kmsan_unpoison_memory(dest, src_len);
 }
 
 #endif	/* _ASM_S390_CPACF_H */
-- 
2.55.0

Re: [PATCH v2] s390/cpacf: Unpoison instruction results

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] `__cpacf_qai` unpoisons the entire 256-byte `cpacf_qai_t` structure, which could mask kernel stack leaks if a specific instruction's QAI output is smaller than 256 bytes.
--

--- Patch [1]: [PATCH v2] s390/cpacf: Unpoison instruction results ---
commit 587dbefd826fa4c40d5401b72be74dfb37147586
Author: Ilya Leoshkevich <iii@linux.ibm.com>

s390/cpacf: Unpoison instruction results

This commit explicitly unpoisons CPACF instruction outputs to stop KMSAN from
reporting them as uninitialized. It leaves variable-length parameter blocks
for the callers to handle.

Link: https://lore.kernel.org/linux-s390/20260806190223.3292580-1-iii@linux.ibm.com/

> diff --git a/arch/s390/include/asm/cpacf.h b/arch/s390/include/asm/cpacf.h
> index a83683169d98d..13d6a6344802a 100644
> --- a/arch/s390/include/asm/cpacf.h
> +++ b/arch/s390/include/asm/cpacf.h

[ ... ]

> @@ -370,6 +371,7 @@ static __always_inline int cpacf_query_func(unsigned int opcode,
>  static __always_inline void __cpacf_qai(unsigned int opcode, cpacf_qai_t *qai)
>  {
>  	__cpacf_query_insn(opcode, qai, CPACF_FC_QUERY_AUTH_INFO);
> +	kmsan_unpoison_memory(qai, sizeof(*qai));

[Severity: Medium]
Will unconditionally unpoisoning the entire 256-byte cpacf_qai_t structure
potentially mask kernel stack leaks from KMSAN?

If a specific instruction's QAI output is smaller than 256 bytes, this
unpoison would hide the remaining uninitialized stack bytes. In
arch/s390/kernel/cpacf.c, the uninitialized stack structure is copied
directly to userspace:

arch/s390/kernel/cpacf.c:name##_query_auth_info_raw_read() {
    ...
    cpacf_qai_t qai;
    ...
    if (!cpacf_qai(CPACF_##instruction, &qai))
        return -EOPNOTSUPP;
    return memory_read_from_buffer(buf, count, &offs, &qai,
                                   sizeof(qai));
}

Could this regression lead to uninitialized stack bytes leaking to userspace
via the sysfs attribute without KMSAN detecting it, if any current or future
hardware query instructions write less than the full struct size?

>  }

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

Re: [PATCH v2] s390/cpacf: Unpoison instruction results

[Ilya Leoshkevich]

On 8/7/26 14:38, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] `__cpacf_qai` unpoisons the entire 256-byte `cpacf_qai_t` structure, which could mask kernel stack leaks if a specific instruction's QAI output is smaller than 256 bytes.
> --
> 
> --- Patch [1]: [PATCH v2] s390/cpacf: Unpoison instruction results ---
> commit 587dbefd826fa4c40d5401b72be74dfb37147586
> Author: Ilya Leoshkevich <iii@linux.ibm.com>
> 
> s390/cpacf: Unpoison instruction results
> 
> This commit explicitly unpoisons CPACF instruction outputs to stop KMSAN from
> reporting them as uninitialized. It leaves variable-length parameter blocks
> for the callers to handle.
> 
> Link: https://lore.kernel.org/linux-s390/20260806190223.3292580-1-iii@linux.ibm.com/
> 
>> diff --git a/arch/s390/include/asm/cpacf.h b/arch/s390/include/asm/cpacf.h
>> index a83683169d98d..13d6a6344802a 100644
>> --- a/arch/s390/include/asm/cpacf.h
>> +++ b/arch/s390/include/asm/cpacf.h
> 
> [ ... ]
> 
>> @@ -370,6 +371,7 @@ static __always_inline int cpacf_query_func(unsigned int opcode,
>>   static __always_inline void __cpacf_qai(unsigned int opcode, cpacf_qai_t *qai)
>>   {
>>   	__cpacf_query_insn(opcode, qai, CPACF_FC_QUERY_AUTH_INFO);
>> +	kmsan_unpoison_memory(qai, sizeof(*qai));
> 
> [Severity: Medium]
> Will unconditionally unpoisoning the entire 256-byte cpacf_qai_t structure
> potentially mask kernel stack leaks from KMSAN?
> 
> If a specific instruction's QAI output is smaller than 256 bytes, this
> unpoison would hide the remaining uninitialized stack bytes. In
> arch/s390/kernel/cpacf.c, the uninitialized stack structure is copied
> directly to userspace:
> 
> arch/s390/kernel/cpacf.c:name##_query_auth_info_raw_read() {
>      ...
>      cpacf_qai_t qai;
>      ...
>      if (!cpacf_qai(CPACF_##instruction, &qai))
>          return -EOPNOTSUPP;
>      return memory_read_from_buffer(buf, count, &offs, &qai,
>                                     sizeof(qai));
> }
> 
> Could this regression lead to uninitialized stack bytes leaking to userspace
> via the sysfs attribute without KMSAN detecting it, if any current or future
> hardware query instructions write less than the full struct size?
> 
>>   }

POp documents that code 127 (Query-Authentication-Information) format 0
(and there are no other formats at the moment) blocks are always 256
bytes and all of these bytes are stored. Reserved bytes are stored as 0.