From: Coly Li <colyli@suse.de>
To: jes@trained-monkey.org
Cc: linux-raid@vger.kernel.org, Wu Guanghao <wuguanghao3@huawei.com>,
Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>,
Coly Li <colyli@suse.de>
Subject: [PATCH 4/6] isuper-intel.c: fix double free in load_imsm_mpb()
Date: Fri, 3 Mar 2023 16:33:21 +0800 [thread overview]
Message-ID: <20230303083323.3406-5-colyli@suse.de> (raw)
In-Reply-To: <20230303083323.3406-1-colyli@suse.de>
From: Wu Guanghao <wuguanghao3@huawei.com>
In load_imsm_mpb() there is potential double free issue on super->buf.
The first location to free super->buf is from get_super_block() <==
load_and_parse_mpb() <== load_imsm_mpb():
4514 if (posix_memalign(&super->migr_rec_buf, MAX_SECTOR_SIZE,
4515 MIGR_REC_BUF_SECTORS*MAX_SECTOR_SIZE) != 0) {
4516 pr_err("could not allocate migr_rec buffer\n");
4517 free(super->buf);
4518 return 2;
4519 }
If the above error condition happens, super->buf is freed and value 2
is returned to get_super_block() eventually. Then in the following code
block inside load_imsm_mpb(),
5289 error:
5290 if (!err) {
5291 s->next = *super_list;
5292 *super_list = s;
5293 } else {
5294 if (s)
5295 free_imsm(s);
5296 close_fd(&dfd);
5297 }
at line 5295 when free_imsm() is called, super->buf is freed again from
the call chain free_imsm() <== __free_imsm(), in following code block,
4651 if (super->buf) {
4652 free(super->buf);
4653 super->buf = NULL;
4654 }
This patch sets super->buf as NULL after line 4517 in load_imsm_mpb()
to avoid the potential double free().
(Coly Li helps to re-compose the commit log)
Signed-off-by: Wu Guanghao <wuguanghao3@huawei.com>
Reviewed-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
Acked-by: Coly Li <colyli@suse.de>
---
super-intel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/super-intel.c b/super-intel.c
index 89fac626..4a3da847 100644
--- a/super-intel.c
+++ b/super-intel.c
@@ -4515,6 +4515,7 @@ static int load_imsm_mpb(int fd, struct intel_super *super, char *devname)
MIGR_REC_BUF_SECTORS*MAX_SECTOR_SIZE) != 0) {
pr_err("could not allocate migr_rec buffer\n");
free(super->buf);
+ super->buf = NULL;
return 2;
}
super->clean_migration_record_by_mdmon = 0;
--
2.39.2
next prev parent reply other threads:[~2023-03-03 8:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-03 8:33 [PATCH 0/6] rebased patch set from Wu Guanghao Coly Li
2023-03-03 8:33 ` [PATCH 1/6] util.c: code cleanup for parse_layout_faulty() Coly Li
2023-03-03 10:22 ` Paul Menzel
2023-03-03 8:33 ` [PATCH 2/6] util.c: fix memleak in parse_layout_faulty() Coly Li
2023-03-03 8:33 ` [PATCH 3/6] Detail.c: fix memleak in Detail() Coly Li
2023-03-03 8:33 ` Coly Li [this message]
2023-03-03 8:33 ` [PATCH 5/6] super-intel.c: fix memleak in find_disk_attached_hba() Coly Li
2023-03-03 8:33 ` [PATCH 6/6] super-ddf.c: fix memleak in get_vd_num_of_subarray() Coly Li
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=20230303083323.3406-5-colyli@suse.de \
--to=colyli@suse.de \
--cc=jes@trained-monkey.org \
--cc=linux-raid@vger.kernel.org \
--cc=mariusz.tkaczyk@linux.intel.com \
--cc=wuguanghao3@huawei.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;
as well as URLs for NNTP newsgroup(s).