From: sashiko-bot@kernel.org
To: "Ilya Leoshkevich" <iii@linux.ibm.com>
Cc: "Alexander Gordeev" <agordeev@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
linux-s390@vger.kernel.org, "Heiko Carstens" <hca@linux.ibm.com>
Subject: Re: [PATCH] s390/cpacf: Unpoison query results
Date: Thu, 06 Aug 2026 19:14:42 +0000 [thread overview]
Message-ID: <20260806191442.AAFE91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806190223.3292580-1-iii@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The patch resolves KMSAN false positives for CPACF query instructions by unpoisoning the fixed-size query outputs, but fails to implement the same fix for the primary CPACF data processing wrappers (e.g., `cpacf_km`, `cpacf_kmc`, `cpacf_kmctr`, `cpacf_kma`, `cpacf_prno`). These functions execute CPU instructions (like `.insn rre`) that write to output buffers directly. Because the inline assembly clobbers "memory" but does not explicitly bind the destination memory as an output operand (it only binds the register holding the pointer), KMSAN is unaware that the buffer is initialized. If an uninitialized buffer is passed for out-of-place encryption or PRNG generation, later reads from the buffer will trigger false-positive use-of-uninitialized-value warnings.
--
--- Patch [1]: [PATCH] s390/cpacf: Unpoison query results ---
commit a5de23eacfba57cb30b8dc14f4c7ed05cf2e259d
Author: Ilya Leoshkevich <iii@linux.ibm.com>
s390/cpacf: Unpoison query results
Stop KMSAN from complaining about query results being uninitialized.
> diff --git a/arch/s390/include/asm/cpacf.h b/arch/s390/include/asm/cpacf.h
> index a83683169d98d..d4128d3fd5138 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: High]
This is a pre-existing issue, but should we also unpoison the buffers in the
other CPACF data processing wrappers?
The primary CPACF data processing wrappers (such as cpacf_km(), cpacf_kmc(),
cpacf_kmctr(), cpacf_kma(), and cpacf_prno()) execute CPU instructions that
write to output buffers directly. Because the inline assembly clobbers memory
but does not explicitly bind the destination memory as an output operand, KMSAN
remains unaware that the buffer was initialized.
If an uninitialized buffer is passed for out-of-place encryption or PRNG
generation, later reads from the buffer might trigger false-positive
use-of-uninitialized-value warnings.
Would it be helpful to add kmsan_unpoison_memory() to these functions as well
to prevent further false positives?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260806190223.3292580-1-iii@linux.ibm.com?part=1
next prev parent reply other threads:[~2026-08-06 19:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 19:02 [PATCH] s390/cpacf: Unpoison query results Ilya Leoshkevich
2026-08-06 19:14 ` sashiko-bot [this message]
2026-08-07 11:05 ` Ilya Leoshkevich
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=20260806191442.AAFE91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=linux-s390@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