[PATCH net v2] s390/ism: Zerorize dmb at allocation

[PATCH net v2] s390/ism: Zerorize dmb at allocation

[Alexandra Winter]

Sashiko reported [1] that 'Missing __GFP_ZERO in folio_alloc() causes
uninitialized kernel memory to be exposed in the receive message buffer'.
An ism dmb is receive-only, so the data is not leaked to a remote peer. In
general the smc kernel module (dibs client) will only push newly received
data to userspace. We still should not have uninitialized data in a receive
buffer.

Since
commit 750afb08ca71 ("cross-tree: phase out dma_zalloc_coherent()")
dma_alloc_coherent no longer required the __GFP_ZERO flag, but when
commit 83781384a96b ("s390/ism: Properly fix receive message buffer allocation")
switched to folio_alloc(), it should have added back the __GFP_ZERO flag.

Add __GFP_ZERO flag and state in dibs.h that register_dbm() provides
a zerorized buffer (dibs_lo already does).

Link: https://lore.kernel.org/linux-s390/20260903143746.A5CC41F00A3A@smtp.kernel.org/ [1]
Fixes: 83781384a96b ("s390/ism: Properly fix receive message buffer allocation")
Cc: stable@vger.kernel.org
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Julian Ruess <julianr@linux.ibm.com>
---
v1->v2: CC Stable
---
 drivers/s390/net/ism_drv.c | 3 ++-
 include/linux/dibs.h       | 6 +++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/s390/net/ism_drv.c b/drivers/s390/net/ism_drv.c
index 035b233abb4e..405abd99c820 100644
--- a/drivers/s390/net/ism_drv.c
+++ b/drivers/s390/net/ism_drv.c
@@ -256,7 +256,8 @@ static int ism_alloc_dmb(struct ism_dev *ism, struct dibs_dmb *dmb)
 		return -EINVAL;
 
 	folio = folio_alloc(GFP_KERNEL | __GFP_NOWARN | __GFP_NOMEMALLOC |
-			    __GFP_NORETRY, get_order(dmb->dmb_len));
+			    __GFP_NORETRY | __GFP_ZERO,
+			    get_order(dmb->dmb_len));
 
 	if (!folio) {
 		rc = -ENOMEM;
diff --git a/include/linux/dibs.h b/include/linux/dibs.h
index d3e0777f25ae..0c10c224bcca 100644
--- a/include/linux/dibs.h
+++ b/include/linux/dibs.h
@@ -261,12 +261,12 @@ struct dibs_dev_ops {
 	 *	@vlan_id: deprecated, ignored if device does not support vlan
 	 * Upon return in addition the following fields will be valid:
 	 *	@dmb_tok: for usage by remote and local devices and clients
-	 *	@cpu_addr: allocated buffer
+	 *	@cpu_addr: allocated, zerorized buffer
 	 *	@idx: dmb index, unique per dibs device
 	 *	@dma_addr: to be used by device driver,if applicable
 	 *
-	 * Allocate a dmb buffer and register it with this device and for this
-	 * client.
+	 * Allocate and zerorize a dmb buffer and register it with this device
+	 * and for this client.
 	 * Return: zero on success
 	 */
 	int (*register_dmb)(struct dibs_dev *dev, struct dibs_dmb *dmb,
-- 
2.53.0

Re: [PATCH net v2] s390/ism: Zerorize dmb at allocation

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH net v2] s390/ism: Zerorize dmb at allocation

[Alexandra Winter]

On 28.09.26 17:19, netdev-bot+sinfo@kernel.org wrote:
> Hi!
> 
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
> 
>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.
> 
> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
> 
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.


For reference:

On 28.09.26 17:14, Alexandra Winter wrote:
> Sashiko reported [1] that 'Missing __GFP_ZERO in folio_alloc() causes
> uninitialized kernel memory to be exposed in the receive message buffer'.
> An ism dmb is receive-only, so the data is not leaked to a remote peer. In
> general the smc kernel module (dibs client) will only push newly received
> data to userspace. We still should not have uninitialized data in a receive
> buffer.


As mentioned in the commit message this issue was reported by Sashiko and found
valid by me. I do not see a simple reproducer.

Alexandra