linux-kernel - Re: [PATCH] swiotlb: swiotlb_tbl_map_single() kernel BUG in iommu-helper.h:30

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Fri, 26 Feb 2021 16:28:27 -0500
From:   Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:     Brad Larson <brad@...sando.io>
Cc:     hch@....de, m.szyprowski@...sung.com, robin.murphy@....com,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] swiotlb: swiotlb_tbl_map_single() kernel BUG in
 iommu-helper.h:30

On Fri, Feb 26, 2021 at 01:18:14PM -0800, Brad Larson wrote:
>     On Fri, Feb 26, 2021 at 12:43:07PM -0800, Brad Larson wrote:
>     > Kernel Oops introduced in next-20210222 due to get_max_slots return arg
>     size.
>     > In the function find_slots() variable max_slots is zero when
>     boundary_mask is
>     > 0xffffffffffffffff.
> 
>     I am looking at the stable/for-linus-5.12 and what I sent out for
>     a GIT PULL and I believe this is already squashed in:
> 
>     531 static int find_slots(struct device *dev, phys_addr_t orig_addr,       
>             
>     532                 size_t alloc_size)                                     
>             
>     533 {                                                                     
>              
>     534         unsigned long boundary_mask = dma_get_seg_boundary(dev);       
>             
>     535         dma_addr_t tbl_dma_addr =                                     
>              
>     536                 phys_to_dma_unencrypted(dev, io_tlb_start) &
>     boundary_mask;     
>     537         unsigned long max_slots = get_max_slots(boundary_mask);
> 
>     Could you double-check please?
> 
>  
> Yes this is squashed in the snippet you are showing.  The bug was introduced in
> next-20210222 and is still there when I updated to next-20210226 today. 

Duh! It should be fixed now for the next one. Thank you!