MAX_DMA_ADDRESS overflow with non-zero arm_dma_zone_size and VMSPLIT_3G

Florian Fainelli f.fainelli at gmail.com
Sun Mar 20 20:46:23 PDT 2022


Hi all,

While debugging numerous KASAN splats with CONFIG_DEBUG_VIRTUAL on ARM 
32-bit with a Raspberry Pi 4B 4GB, it finally clicked that the problem 
is with the use of __virt_to_phys(MAX_DMA_ADDRESS). Since that platform 
has CONFIG_ZONE_DMA enabled, we end-up with:

   #define MAX_DMA_ADDRESS ({ \
           extern phys_addr_t arm_dma_zone_size; \
           arm_dma_zone_size && arm_dma_zone_size < (0x10000000 - 
PAGE_OFFSET) ? \
                   (PAGE_OFFSET + arm_dma_zone_size) : 0xffffffffUL; })

and with arch/arm/mach-bcm/bcm2711.c defining a dma_zone_size of SZ_1G 
and PAGE_OFFSET = 0xC000_0000 we end up with MAX_DMA_ADDRES of 
0x1_0000_0000 which overflows the virtual address size that is 
represented with an unsigned long.

All of the virt_to_phys() and related functions either take a pointer 
size argument (const volatile void *) or an unsigned long argument and 
these are virtual addresses so unable to go over 32-bit anyway.

Since MAX_DMA_ADDRESS is intended to be "This is the maximum virtual 
address which can be DMA'd from.", should we make sure that we clamp it 
below 32-bit in case it overflows?

The splats can be silenced with this too:

diff --git a/arch/arm/mm/physaddr.c b/arch/arm/mm/physaddr.c
index cf75819e4c13..abf071c7c6e9 100644
--- a/arch/arm/mm/physaddr.c
+++ b/arch/arm/mm/physaddr.c
@@ -29,7 +29,7 @@ static inline bool __virt_addr_valid(unsigned long x)
          * actual physical address. Enough code relies on 
__pa(MAX_DMA_ADDRESS)
          * that we just need to work around it and always return true.
          */
-       if (x == MAX_DMA_ADDRESS)
+       if (x == (unsigned long)MAX_DMA_ADDRESS)
                 return true;

         return false;

but this does not permit differentiating a 0 virtual address from 
MAX_DMA_ADDRESS having overflowed.

Thanks!
-- 
Florian



More information about the linux-arm-kernel mailing list