From: <gregkh@linuxfoundation.org>
To: akpm@linux-foundation.org, gregkh@linuxfoundation.org,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
linux@armlinux.org.uk, mark-pk.tsai@mediatek.com,
rppt@kernel.org, rppt@linux.ibm.com, tony@atomide.com,
wangkefeng.wang@huawei.com, yj.chiang@mediatek.com
Cc: <stable-commits@vger.kernel.org>
Subject: Patch "memblock: ensure there is no overflow in memblock_overlaps_region()" has been added to the 5.10-stable tree
Date: Wed, 15 Dec 2021 15:10:10 +0100 [thread overview]
Message-ID: <16395774105643@kroah.com> (raw)
In-Reply-To: <20211213094135.1798-4-mark-pk.tsai@mediatek.com>
This is a note to let you know that I've just added the patch titled
memblock: ensure there is no overflow in memblock_overlaps_region()
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
memblock-ensure-there-is-no-overflow-in-memblock_overlaps_region.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From foo@baz Wed Dec 15 03:01:20 PM CET 2021
From: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Date: Mon, 13 Dec 2021 17:41:33 +0800
Subject: memblock: ensure there is no overflow in memblock_overlaps_region()
To: <stable@vger.kernel.org>
Cc: <rppt@kernel.org>, <akpm@linux-foundation.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, <linux@armlinux.org.uk>, <rppt@linux.ibm.com>, <tony@atomide.com>, <wangkefeng.wang@huawei.com>, <mark-pk.tsai@mediatek.com>, <yj.chiang@mediatek.com>
Message-ID: <20211213094135.1798-4-mark-pk.tsai@mediatek.com>
From: Mike Rapoport <rppt@linux.ibm.com>
[ Upstream commit 023accf5cdc1e504a9b04187ec23ff156fe53d90 ]
There maybe an overflow in memblock_overlaps_region() if it is called with
base and size such that
base + size > PHYS_ADDR_MAX
Make sure that memblock_overlaps_region() caps the size to prevent such
overflow and remove now duplicated call to memblock_cap_size() from
memblock_is_region_reserved().
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/lkml/20210630071211.21011-1-rppt@kernel.org/
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/memblock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -182,6 +182,8 @@ bool __init_memblock memblock_overlaps_r
{
unsigned long i;
+ memblock_cap_size(base, &size);
+
for (i = 0; i < type->cnt; i++)
if (memblock_addrs_overlap(base, size, type->regions[i].base,
type->regions[i].size))
@@ -1792,7 +1794,6 @@ bool __init_memblock memblock_is_region_
*/
bool __init_memblock memblock_is_region_reserved(phys_addr_t base, phys_addr_t size)
{
- memblock_cap_size(base, &size);
return memblock_overlaps_region(&memblock.reserved, base, size);
}
Patches currently in stable-queue which might be from mark-pk.tsai@mediatek.com are
queue-5.10/arm-extend-pfn_valid-to-take-into-account-freed-memory-map-alignment.patch
queue-5.10/arm-ioremap-don-t-abuse-pfn_valid-to-check-if-pfn-is-in-ram.patch
queue-5.10/memblock-free_unused_memmap-use-pageblock-units-instead-of-max_order.patch
queue-5.10/memblock-align-freed-memory-map-on-pageblock-boundaries-with-sparsemem.patch
queue-5.10/memblock-ensure-there-is-no-overflow-in-memblock_overlaps_region.patch
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: <gregkh@linuxfoundation.org>
To: akpm@linux-foundation.org,gregkh@linuxfoundation.org,linux-arm-kernel@lists.infradead.org,linux-mm@kvack.org,linux@armlinux.org.uk,mark-pk.tsai@mediatek.com,rppt@kernel.org,rppt@linux.ibm.com,tony@atomide.com,wangkefeng.wang@huawei.com,yj.chiang@mediatek.com
Cc: <stable-commits@vger.kernel.org>
Subject: Patch "memblock: ensure there is no overflow in memblock_overlaps_region()" has been added to the 5.10-stable tree
Date: Wed, 15 Dec 2021 15:10:10 +0100 [thread overview]
Message-ID: <16395774105643@kroah.com> (raw)
In-Reply-To: <20211213094135.1798-4-mark-pk.tsai@mediatek.com>
This is a note to let you know that I've just added the patch titled
memblock: ensure there is no overflow in memblock_overlaps_region()
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
memblock-ensure-there-is-no-overflow-in-memblock_overlaps_region.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From foo@baz Wed Dec 15 03:01:20 PM CET 2021
From: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Date: Mon, 13 Dec 2021 17:41:33 +0800
Subject: memblock: ensure there is no overflow in memblock_overlaps_region()
To: <stable@vger.kernel.org>
Cc: <rppt@kernel.org>, <akpm@linux-foundation.org>, <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, <linux@armlinux.org.uk>, <rppt@linux.ibm.com>, <tony@atomide.com>, <wangkefeng.wang@huawei.com>, <mark-pk.tsai@mediatek.com>, <yj.chiang@mediatek.com>
Message-ID: <20211213094135.1798-4-mark-pk.tsai@mediatek.com>
From: Mike Rapoport <rppt@linux.ibm.com>
[ Upstream commit 023accf5cdc1e504a9b04187ec23ff156fe53d90 ]
There maybe an overflow in memblock_overlaps_region() if it is called with
base and size such that
base + size > PHYS_ADDR_MAX
Make sure that memblock_overlaps_region() caps the size to prevent such
overflow and remove now duplicated call to memblock_cap_size() from
memblock_is_region_reserved().
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/lkml/20210630071211.21011-1-rppt@kernel.org/
Signed-off-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/memblock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -182,6 +182,8 @@ bool __init_memblock memblock_overlaps_r
{
unsigned long i;
+ memblock_cap_size(base, &size);
+
for (i = 0; i < type->cnt; i++)
if (memblock_addrs_overlap(base, size, type->regions[i].base,
type->regions[i].size))
@@ -1792,7 +1794,6 @@ bool __init_memblock memblock_is_region_
*/
bool __init_memblock memblock_is_region_reserved(phys_addr_t base, phys_addr_t size)
{
- memblock_cap_size(base, &size);
return memblock_overlaps_region(&memblock.reserved, base, size);
}
Patches currently in stable-queue which might be from mark-pk.tsai@mediatek.com are
queue-5.10/arm-extend-pfn_valid-to-take-into-account-freed-memory-map-alignment.patch
queue-5.10/arm-ioremap-don-t-abuse-pfn_valid-to-check-if-pfn-is-in-ram.patch
queue-5.10/memblock-free_unused_memmap-use-pageblock-units-instead-of-max_order.patch
queue-5.10/memblock-align-freed-memory-map-on-pageblock-boundaries-with-sparsemem.patch
queue-5.10/memblock-ensure-there-is-no-overflow-in-memblock_overlaps_region.patch
next prev parent reply other threads:[~2021-12-15 14:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 9:41 [PATCH 5.10 0/5] memblock, arm: fixes for freeing of the memory map Mark-PK Tsai
2021-12-13 9:41 ` Mark-PK Tsai
2021-12-13 9:41 ` [PATCH 5.10 1/5] memblock: free_unused_memmap: use pageblock units instead of MAX_ORDER Mark-PK Tsai
2021-12-13 9:41 ` Mark-PK Tsai
2021-12-15 14:10 ` Patch "memblock: free_unused_memmap: use pageblock units instead of MAX_ORDER" has been added to the 5.10-stable tree gregkh
2021-12-15 14:10 ` gregkh
2021-12-13 9:41 ` [PATCH 5.10 2/5] memblock: align freed memory map on pageblock boundaries with SPARSEMEM Mark-PK Tsai
2021-12-13 9:41 ` Mark-PK Tsai
2021-12-15 14:10 ` Patch "memblock: align freed memory map on pageblock boundaries with SPARSEMEM" has been added to the 5.10-stable tree gregkh
2021-12-15 14:10 ` gregkh
2021-12-13 9:41 ` [PATCH 5.10 3/5] memblock: ensure there is no overflow in memblock_overlaps_region() Mark-PK Tsai
2021-12-13 9:41 ` Mark-PK Tsai
2021-12-15 14:10 ` gregkh [this message]
2021-12-15 14:10 ` Patch "memblock: ensure there is no overflow in memblock_overlaps_region()" has been added to the 5.10-stable tree gregkh
2021-12-13 9:41 ` [PATCH 5.10 4/5] arm: extend pfn_valid to take into account freed memory map alignment Mark-PK Tsai
2021-12-13 9:41 ` Mark-PK Tsai
2021-12-15 14:10 ` Patch "arm: extend pfn_valid to take into account freed memory map alignment" has been added to the 5.10-stable tree gregkh
2021-12-15 14:10 ` gregkh
2021-12-13 9:41 ` [PATCH 5.10 5/5] arm: ioremap: don't abuse pfn_valid() to check if pfn is in RAM Mark-PK Tsai
2021-12-13 9:41 ` Mark-PK Tsai
2021-12-15 14:10 ` Patch "arm: ioremap: don't abuse pfn_valid() to check if pfn is in RAM" has been added to the 5.10-stable tree gregkh
2021-12-15 14:10 ` gregkh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16395774105643@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=mark-pk.tsai@mediatek.com \
--cc=rppt@kernel.org \
--cc=rppt@linux.ibm.com \
--cc=stable-commits@vger.kernel.org \
--cc=tony@atomide.com \
--cc=wangkefeng.wang@huawei.com \
--cc=yj.chiang@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.