From: Peng Zhang <perlyzhang@gmail.com>
To: "Liam R. Howlett" <Liam.Howlett@Oracle.com>,
Peng Zhang <zhangpeng.00@bytedance.com>,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org,
stable@vger.kernel.org
Subject: Re: [PATCH 2/2] maple_tree: Fix a potential memory leak, OOB access, or other unpredictable bug
Date: Mon, 10 Apr 2023 20:58:21 +0800 [thread overview]
Message-ID: <84c50299-5b5b-867e-1e96-2d3a0c6ade2a@gmail.com> (raw)
In-Reply-To: <20230410124331.kijufkik2qlxoxjz@revolver>
在 2023/4/10 20:43, Liam R. Howlett 写道:
> * Peng Zhang <zhangpeng.00@bytedance.com> [230407 00:10]:
>> In mas_alloc_nodes(), there is such a piece of code:
>> while (requested) {
>> ...
>> node->node_count = 0;
>> ...
>> }
> You don't need to quote code in your commit message since it is
> available in the change log or in the file itself.
Ok, I will change it in the next version.
>
>> "node->node_count = 0" means to initialize the node_count field of the
>> new node, but the node may not be a new node. It may be a node that
>> existed before and node_count has a value, setting it to 0 will cause a
>> memory leak. At this time, mas->alloc->total will be greater than the
>> actual number of nodes in the linked list, which may cause many other
>> errors. For example, out-of-bounds access in mas_pop_node(), and
>> mas_pop_node() may return addresses that should not be used.
>> Fix it by initializing node_count only for new nodes.
>>
>> Fixes: 54a611b60590 ("Maple Tree: add new data structure")
>> Signed-off-by: Peng Zhang <zhangpeng.00@bytedance.com>
>> Cc: <stable@vger.kernel.org>
>> ---
>> lib/maple_tree.c | 16 ++++------------
>> 1 file changed, 4 insertions(+), 12 deletions(-)
>>
>> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
>> index 65fd861b30e1..9e25b3215803 100644
>> --- a/lib/maple_tree.c
>> +++ b/lib/maple_tree.c
>> @@ -1249,26 +1249,18 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
>> node = mas->alloc;
>> node->request_count = 0;
>> while (requested) {
>> - max_req = MAPLE_ALLOC_SLOTS;
>> - if (node->node_count) {
>> - unsigned int offset = node->node_count;
>> -
>> - slots = (void **)&node->slot[offset];
>> - max_req -= offset;
>> - } else {
>> - slots = (void **)&node->slot;
>> - }
>> -
>> + max_req = MAPLE_ALLOC_SLOTS - node->node_count;
>> + slots = (void **)&node->slot[node->node_count];
> Thanks, this is much cleaner.
>
>> max_req = min(requested, max_req);
>> count = mt_alloc_bulk(gfp, max_req, slots);
>> if (!count)
>> goto nomem_bulk;
>>
>> + if (node->node_count == 0)
>> + node->slot[0]->node_count = 0;
>> node->node_count += count;
>> allocated += count;
>> node = node->slot[0];
>> - node->node_count = 0;
>> - node->request_count = 0;
> Why are we not clearing request_count anymore?
Because the node pointed to by the variable "node"
must not be the head node of the linked list at
this time, we only need to maintain the information
of the head node.
>
>> requested -= count;
>> }
>> mas->alloc->total = allocated;
>> --
>> 2.20.1
>>
next prev parent reply other threads:[~2023-04-10 12:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-07 4:07 [PATCH 1/2] maple_tree: Add a test case to check maple_alloc Peng Zhang
2023-04-07 4:07 ` [PATCH 2/2] maple_tree: Fix a potential memory leak, OOB access, or other unpredictable bug Peng Zhang
2023-04-10 12:43 ` Liam R. Howlett
2023-04-10 12:58 ` Peng Zhang [this message]
2023-04-10 13:12 ` Liam R. Howlett
2023-04-10 13:28 ` Peng Zhang
2023-04-10 15:00 ` Liam R. Howlett
2023-04-10 15:23 ` Peng Zhang
2023-04-08 3:16 ` [PATCH 1/2] maple_tree: Add a test case to check maple_alloc Liam R. Howlett
2023-04-08 3:22 ` Liam R. Howlett
2023-04-10 12:41 ` Liam R. Howlett
2023-04-10 13:02 ` Peng Zhang
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=84c50299-5b5b-867e-1e96-2d3a0c6ade2a@gmail.com \
--to=perlyzhang@gmail.com \
--cc=Liam.Howlett@Oracle.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maple-tree@lists.infradead.org \
--cc=stable@vger.kernel.org \
--cc=zhangpeng.00@bytedance.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®