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

[Ilya Leoshkevich <iii@linux.ibm.com>]

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.