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

[Alexandra Winter <wintera@linux.ibm.com>]

On 05.09.26 11:45, sashiko-bot@kernel.org wrote:
> 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?
> 

Fix for this is is already in netdev:
 https://git.kernel.org/netdev/net/c/907a56ab3eb8