linux-kernel - [PATCH] dma-buf: dma-heap: Add a size limitation for allocation

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

Message-ID: <20211217094104.24977-1-guangming.cao@mediatek.com>
Date:   Fri, 17 Dec 2021 17:41:04 +0800
From:   <guangming.cao@...iatek.com>
To:     Sumit Semwal <sumit.semwal@...aro.org>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Liam Mark <lmark@...eaurora.org>,
        "Laura Abbott" <labbott@...hat.com>,
        Brian Starkey <Brian.Starkey@....com>,
        "John Stultz" <john.stultz@...aro.org>,
        Christian König <christian.koenig@....com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        "open list:DMA-BUF HEAPS FRAMEWORK" <linux-media@...r.kernel.org>,
        "open list:DMA-BUF HEAPS FRAMEWORK" <dri-devel@...ts.freedesktop.org>,
        "moderated list:DMA-BUF HEAPS FRAMEWORK" 
        <linaro-mm-sig@...ts.linaro.org>,
        open list <linux-kernel@...r.kernel.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-arm-kernel@...ts.infradead.org>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>
CC:     <wsd_upstream@...iatek.com>, Bo Song <bo.song@...iatek.com>,
        Libo Kang <libo.kang@...iatek.com>,
        jianjiao zeng <jianjiao.zeng@...iatek.com>,
        mingyuan ma <mingyuan.ma@...iatek.com>,
        Yunfei Wang <yf.wang@...iatek.com>,
        Guangming <Guangming.Cao@...iatek.com>
Subject: [PATCH] dma-buf: dma-heap: Add a size limitation for allocation

From: Guangming <Guangming.Cao@...iatek.com>

Currently, there is no size check for allocation.

If the alloc size is larger than DRAM, it will cause OOM issue.
Besides, if it runs on a process that won't be killed by OOM flow, it will
cause a kernel exception finally,  and we couldn't find the correct
memory usage by dma-buf dump api such as "dma_buf_debug_show" since the
allocation is still on going and the corresponding dmabuf is not exported.

However, it sounds not simple enough to adding a count to count how many
pages has been allocated before allocating done.
So adding a size limitation here to prevent this case.

Signed-off-by: Guangming <Guangming.Cao@...iatek.com>
Signed-off-by: jianjiao zeng <jianjiao.zeng@...iatek.com>
---
 drivers/dma-buf/dma-heap.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 56bf5ad01ad5..8b75998a106c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -107,6 +107,9 @@ static long dma_heap_ioctl_allocate(struct file *file, void *data)
 	if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
 		return -EINVAL;
 
+	if (heap_allocation->len / PAGE_SIZE > totalram_pages() / 2)
+		return -EINVAL;
+
 	fd = dma_heap_buffer_alloc(heap, heap_allocation->len,
 				   heap_allocation->fd_flags,
 				   heap_allocation->heap_flags);
-- 
2.17.1