Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Unsafe error path calling kfree() on memory allocated via folio_alloc().
--

commit 71f881ca9b5f87a2235598ada197106f8482dccb
Author: Alexandra Winter <wintera@linux.ibm.com>

    dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()
    
    dibs->lock is acquired in process context and interrupt context
    (ism_handle_irq()). So always use spin_lock_irqsave() in process context.
    
    Note that this is not a real deadlock, as dibs_lo devices don't have
    any interrupt context.

[ ... ]

> diff --git a/drivers/dibs/dibs_loopback.c b/drivers/dibs/dibs_loopback.c
> index 649e4e375be33..44a2e74c2efcb 100644
> --- a/drivers/dibs/dibs_loopback.c
> +++ b/drivers/dibs/dibs_loopback.c

[ ... ]

While reviewing this commit, I noticed a pre-existing issue in the related
ism_alloc_dmb() function:

drivers/s390/net/ism_drv.c:ism_alloc_dmb() {
[ ... ]
	folio = folio_alloc(GFP_KERNEL | __GFP_NOWARN | __GFP_NOMEMALLOC |
			    __GFP_NORETRY, get_order(dmb->dmb_len));

	if (!folio) {
		rc = -ENOMEM;
		goto out_bit;
	}

	dmb->cpu_addr = folio_address(folio);
	dmb->dma_addr = dma_map_page(&ism->pdev->dev,
				     virt_to_page(dmb->cpu_addr), 0,
				     dmb->dmb_len, DMA_FROM_DEVICE);
	if (dma_mapping_error(&ism->pdev->dev, dmb->dma_addr)) {
		rc = -ENOMEM;
		goto out_free;
	}

	return 0;

out_free:
	kfree(dmb->cpu_addr);
[ ... ]
}

[Severity: High]
This is a pre-existing issue, but does calling kfree() on memory directly
allocated by folio_alloc() cause a kernel panic due to invalid slab metadata?

When dma_map_page() fails, the execution jumps to the out_free label, which
incorrectly calls kfree(dmb->cpu_addr) instead of using folio_put() as seen
in ism_free_dmb().

If a user exhausts DMA mapping space (e.g., filling up the IOMMU or exhausting
bounce buffers), could this error path be triggered resulting in a denial of
service?

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