[PATCH v3] net/mlx4_en: fix potential use-after-free with dma_unmap_page

[Sarah Newman <srn@prgmr.com>]

On 05/30/2018 10:36 PM, Greg KH wrote:
> On Wed, May 30, 2018 at 06:04:05PM -0700, Sarah Newman wrote:
>> [ Not relevant upstream, therefore no upstream commit. ]
>>
>> To fix, unmap the page as soon as possible.
>>
>> When swiotlb is in use, calling dma_unmap_page means that
>> the original page mapped with dma_map_page must still be valid,
>> as swiotlb will copy data from its internal cache back to the
>> originally requested DMA location.
>>
>> When GRO is enabled, before this patch all references to the
>> original frag may be put and the page freed before dma_unmap_page
>> in mlx4_en_free_frag is called.
>>
>> It is possible there is a path where the use-after-free occurs
>> even with GRO disabled, but this has not been observed so far.
>>
>> The bug can be trivially detected by doing the following:
>>
>> * Compile the kernel with DEBUG_PAGEALLOC
>> * Run the kernel as a Xen Dom0
>> * Leave GRO enabled on the interface
>> * Run a 10 second or more test with iperf over the interface.
>>
>> This bug was likely introduced in
>> commit 4cce66cdd14a ("mlx4_en: map entire pages to increase throughput"),
>> first part of u3.6.
>>
>> It was incidentally fixed in
>> commit 34db548bfb95 ("mlx4: add page recycling in receive path"),
>> first part of v4.12.
> 
> Why not just apply this patch instead?

That patch was part of a major rewrite. There was a 13 patch series and not even the first patch of the series 69ba943151b2e "mlx4: dma_dir is a
mlx4_en_priv attribute" applies cleanly to 4.9. I didn't believe that was appropriate to backport.

> 
>>
>> This version applies to the v4.9 series.
> 
> What about 4.4?  Why not just use 4.14 for this hardware?

I can also submit a patch for 4.4 if that's desired. The differences are minor.

We don't use 4.14 because we want to use a kernel version more widely tested for the majority of features we use. Currently our distribution ships 4.9.

Thanks, Sarah