linux-kernel - Re: [PATCH v2] dma-buf/heaps: system_heap: Avoid DoS by limiting single allocations to half of all memory

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: <20230405172524.e25b62e1c548a95564b1d324@linux-foundation.org>
Date:   Wed, 5 Apr 2023 17:25:24 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Jaewon Kim <jaewon31.kim@...sung.com>
Cc:     jstultz@...gle.com, tjmercier@...gle.com, sumit.semwal@...aro.org,
        daniel.vetter@...ll.ch, hannes@...xchg.org, mhocko@...nel.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        jaewon31.kim@...il.com
Subject: Re: [PATCH v2] dma-buf/heaps: system_heap: Avoid DoS by limiting
 single allocations to half of all memory

On Thu,  6 Apr 2023 09:08:54 +0900 Jaewon Kim <jaewon31.kim@...sung.com> wrote:

> Normal free:212600kB min:7664kB low:57100kB high:106536kB
>   reserved_highatomic:4096KB active_anon:276kB inactive_anon:180kB
>   active_file:1200kB inactive_file:0kB unevictable:2932kB
>   writepending:0kB present:4109312kB managed:3689488kB mlocked:2932kB
>   pagetables:13600kB bounce:0kB free_pcp:0kB local_pcp:0kB
>   free_cma:200844kB
> Out of memory and no killable processes...
> Kernel panic - not syncing: System is deadlocked on memory
> 
> An OoM panic was reported, there were only native processes which are
> non-killable as OOM_SCORE_ADJ_MIN.
> 
> After looking into the dump, I've found the dma-buf system heap was
> trying to allocate a huge size. It seems to be a signed negative value.
> 
> dma_heap_ioctl_allocate(inline)
>     |  heap_allocation = 0xFFFFFFC02247BD38 -> (
>     |    len = 0xFFFFFFFFE7225100,
> 
> Actually the old ion system heap had policy which does not allow that
> huge size with commit c9e8440eca61 ("staging: ion: Fix overflow and list
> bugs in system heap"). We need this change again. Single allocation
> should not be bigger than half of all memory.
> 
> ...
>
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -351,6 +351,9 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
>  	struct page *page, *tmp_page;
>  	int i, ret = -ENOMEM;
>  
> +	if (len / PAGE_SIZE > totalram_pages() / 2)
> +		return ERR_PTR(-ENOMEM);
> +

This seems so random.  Why ram/2 rather than ram/3 or 17*ram/35?

Better behavior would be to try to allocate what the caller asked
for and if that doesn't work out, fail gracefully after freeing the
partial allocations which have been performed thus far.  If dma_buf
is changed to do this then that change is useful in many scenarios other
than this crazy corner case.