linux-kernel - Re: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for xen_swiotlb_free

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1528403323.2289.84.camel@codethink.co.uk>
Date:   Thu, 07 Jun 2018 21:28:43 +0100
From:   Ben Hutchings <ben.hutchings@...ethink.co.uk>
To:     Joe Jin <joe.jin@...cle.com>,
        John Sobecki <john.sobecki@...cle.com>,
        Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc:     stable@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for
 xen_swiotlb_free_coherent

On Mon, 2018-05-28 at 11:59 +0200, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Joe Jin <joe.jin@...cle.com>
> 
> commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
> 
> When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
> but Dom Heap is increased by the same size. Tracing raidconfig we found
> that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
> to apply memory. If the memory allocated by Dom0 is not in the DMA area,
> it will exchange memory with Xen to meet the requiment. Later drivers
> call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
> the check condition (dev_addr + size - 1 <= dma_mask) is always false,

I think this was meant to say (dev_addr + size - 1 > dma_mask), i.e.
the condition that is replaced by this commit.  If that's always false,
the new condition (the logical inverse) must always be true.

[...]
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
>  	 * physical address */
>  	phys = xen_bus_to_phys(dev_addr);
>  
> -	if (((dev_addr + size - 1 > dma_mask)) ||
> +	if (((dev_addr + size - 1 <= dma_mask)) ||
>  	    range_straddles_page_boundary(phys, size))
>  		xen_destroy_contiguous_region(phys, order);
>  

So now we will always call xen_destroy_contiguous_region(), whether or
not xen_create_contiguous_region() was called during allocation.  Is
that really the intent?  If so, the entire condition could be removed
to make this clear.

Alternately, if the commit message is correct, the condition could be
simplified to range_straddles_page_boundary(...).

But I'm not at all convinced that either of these is correct.  It seems
like you need to either find a way of distinguishing between memory
allocated with or without the use of xen_create_contiguous_region(), or
to use it unconditionally.

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom