From: "Liam R. Howlett" <Liam.Howlett@Oracle.com>
To: Peng Zhang <perlyzhang@gmail.com>
Cc: 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 09:12:58 -0400 [thread overview]
Message-ID: <20230410131258.txkiqa5eudgsrmht@revolver> (raw)
In-Reply-To: <84c50299-5b5b-867e-1e96-2d3a0c6ade2a@gmail.com>
* Peng Zhang <perlyzhang@gmail.com> [230410 08:58]:
>
> 在 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.
Right, at this time it is not the head node, but could it become the
head node with invalid data? I think it can, because we don't
explicitly set it in mas_pop_node()?
In any case, be sure to mention that you make a change like this in the
change log, like "Drop setting the resquest_count as it is unnecessary
because.." in a new paragraph, so that it is not missed.
> >
> > > requested -= count;
> > > }
> > > mas->alloc->total = allocated;
> > > --
> > > 2.20.1
> > >
next prev parent reply other threads:[~2023-04-10 13:13 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
2023-04-10 13:12 ` Liam R. Howlett [this message]
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=20230410131258.txkiqa5eudgsrmht@revolver \
--to=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=perlyzhang@gmail.com \
--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 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.