From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Leo Yan <leo.yan@linaro.org>
Cc: Song Liu <songliubraving@fb.com>,
Peter Zijlstra <peterz@infradead.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
linux-kernel@vger.kernel.org, Jin Yao <yao.jin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Andi Kleen <ak@linux.intel.com>,
Eric Saint-Etienne <eric.saint.etienne@oracle.com>,
Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
Ingo Molnar <mingo@redhat.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Alexios Zavras <alexios.zavras@intel.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Namhyung Kim <namhyung@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Thomas Richter <tmricht@linux.ibm.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
"David S. Miller" <davem@davemloft.net>,
Changbin Du <changbin.du@intel.com>,
Alexey Budankov <alexey.budankov@linux.intel.com>
Subject: Re: [PATCH v1 04/11] perf annotate: Smatch: Fix dereferencing freed memory
Date: Wed, 3 Jul 2019 15:43:46 -0300 [thread overview]
Message-ID: <20190703184346.GE10740@kernel.org> (raw)
In-Reply-To: <20190702103420.27540-5-leo.yan@linaro.org>
Em Tue, Jul 02, 2019 at 06:34:13PM +0800, Leo Yan escreveu:
> Based on the following report from Smatch, fix the potential
> dereferencing freed memory check.
>
> tools/perf/util/annotate.c:1125
> disasm_line__parse() error: dereferencing freed memory 'namep'
>
> tools/perf/util/annotate.c
> 1100 static int disasm_line__parse(char *line, const char **namep, char **rawp)
> 1101 {
> 1102 char tmp, *name = ltrim(line);
>
> [...]
>
> 1114 *namep = strdup(name);
> 1115
> 1116 if (*namep == NULL)
> 1117 goto out_free_name;
>
> [...]
>
> 1124 out_free_name:
> 1125 free((void *)namep);
> ^^^^^
> 1126 *namep = NULL;
> ^^^^^^
> 1127 return -1;
> 1128 }
>
> If strdup() fails to allocate memory space for *namep, we don't need to
> free memory with pointer 'namep', which is resident in data structure
> disasm_line::ins::name; and *namep is NULL pointer for this failure, so
> it's pointless to assign NULL to *namep again.
Applied, with this extra comment:
Committer note:
Freeing namep, which is the address of the first entry of the 'struct
ins' that is the first member of struct disasm_line would in fact free
that disasm_line instance, if it was allocated via malloc/calloc, which,
later, would a dereference of freed memory.
_______________________________________________
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: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: Leo Yan <leo.yan@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
Mathieu Poirier <mathieu.poirier@linaro.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Andi Kleen <ak@linux.intel.com>,
"David S. Miller" <davem@davemloft.net>,
Davidlohr Bueso <dave@stgolabs.net>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Jin Yao <yao.jin@linux.intel.com>,
Song Liu <songliubraving@fb.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Alexios Zavras <alexios.zavras@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Changbin Du <changbin.du@intel.com>,
Eric Saint-Etienne <eric.saint.etienne@oracle.com>,
Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
Thomas Richter <tmricht@linux.ibm.com>,
Alexey Budankov <alexey.budankov@linux.intel.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1 04/11] perf annotate: Smatch: Fix dereferencing freed memory
Date: Wed, 3 Jul 2019 15:43:46 -0300 [thread overview]
Message-ID: <20190703184346.GE10740@kernel.org> (raw)
In-Reply-To: <20190702103420.27540-5-leo.yan@linaro.org>
Em Tue, Jul 02, 2019 at 06:34:13PM +0800, Leo Yan escreveu:
> Based on the following report from Smatch, fix the potential
> dereferencing freed memory check.
>
> tools/perf/util/annotate.c:1125
> disasm_line__parse() error: dereferencing freed memory 'namep'
>
> tools/perf/util/annotate.c
> 1100 static int disasm_line__parse(char *line, const char **namep, char **rawp)
> 1101 {
> 1102 char tmp, *name = ltrim(line);
>
> [...]
>
> 1114 *namep = strdup(name);
> 1115
> 1116 if (*namep == NULL)
> 1117 goto out_free_name;
>
> [...]
>
> 1124 out_free_name:
> 1125 free((void *)namep);
> ^^^^^
> 1126 *namep = NULL;
> ^^^^^^
> 1127 return -1;
> 1128 }
>
> If strdup() fails to allocate memory space for *namep, we don't need to
> free memory with pointer 'namep', which is resident in data structure
> disasm_line::ins::name; and *namep is NULL pointer for this failure, so
> it's pointless to assign NULL to *namep again.
Applied, with this extra comment:
Committer note:
Freeing namep, which is the address of the first entry of the 'struct
ins' that is the first member of struct disasm_line would in fact free
that disasm_line instance, if it was allocated via malloc/calloc, which,
later, would a dereference of freed memory.
next prev parent reply other threads:[~2019-07-03 18:44 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 10:34 [PATCH v1 00/11] perf: Fix errors detected by Smatch Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-02 10:34 ` [PATCH v1 01/11] perf report: Smatch: Fix potential NULL pointer dereference Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-02 10:34 ` [PATCH v1 02/11] perf stat: Smatch: Fix use-after-freed pointer Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-03 18:18 ` Arnaldo Carvalho de Melo
2019-07-03 18:18 ` Arnaldo Carvalho de Melo
2019-07-13 10:53 ` [tip:perf/urgent] perf stat: Fix use-after-freed pointer detected by the smatch tool tip-bot for Leo Yan
2019-07-02 10:34 ` [PATCH v1 03/11] perf top: Smatch: Fix potential NULL pointer dereference Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-03 18:30 ` Arnaldo Carvalho de Melo
2019-07-03 18:30 ` Arnaldo Carvalho de Melo
2019-07-13 10:53 ` [tip:perf/urgent] perf top: Fix potential NULL pointer dereference detected by the smatch tool tip-bot for Leo Yan
2019-07-02 10:34 ` [PATCH v1 04/11] perf annotate: Smatch: Fix dereferencing freed memory Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-03 18:43 ` Arnaldo Carvalho de Melo [this message]
2019-07-03 18:43 ` Arnaldo Carvalho de Melo
2019-07-13 10:54 ` [tip:perf/urgent] perf annotate: Fix dereferencing freed memory found by the smatch tool tip-bot for Leo Yan
2019-07-02 10:34 ` [PATCH v1 05/11] perf trace: Smatch: Fix potential NULL pointer dereference Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-03 18:46 ` Arnaldo Carvalho de Melo
2019-07-03 18:46 ` Arnaldo Carvalho de Melo
2019-07-13 10:55 ` [tip:perf/urgent] perf trace: Fix potential NULL pointer dereference found by the smatch tool tip-bot for Leo Yan
2019-07-02 10:34 ` [PATCH v1 06/11] perf hists: Smatch: Fix potential NULL pointer dereference Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-02 11:07 ` Jiri Olsa
2019-07-02 11:07 ` Jiri Olsa
2019-07-02 10:34 ` [PATCH v1 07/11] perf map: " Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-13 10:55 ` [tip:perf/urgent] perf map: Fix potential NULL pointer dereference found by smatch tool tip-bot for Leo Yan
2019-07-02 10:34 ` [PATCH v1 08/11] perf session: Smatch: Fix potential NULL pointer dereference Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-03 19:01 ` Arnaldo Carvalho de Melo
2019-07-03 19:01 ` Arnaldo Carvalho de Melo
2019-07-13 10:57 ` [tip:perf/urgent] perf session: Fix potential NULL pointer dereference found by the smatch tool tip-bot for Leo Yan
2019-07-02 10:34 ` [PATCH v1 09/11] perf intel-bts: Smatch: Fix potential NULL pointer dereference Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-02 10:34 ` [PATCH v1 10/11] perf intel-pt: " Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-02 11:07 ` Adrian Hunter
2019-07-02 11:07 ` Adrian Hunter
2019-07-03 1:35 ` Leo Yan
2019-07-03 1:35 ` Leo Yan
2019-07-03 5:19 ` Adrian Hunter
2019-07-03 5:19 ` Adrian Hunter
2019-07-03 8:16 ` Leo Yan
2019-07-03 8:16 ` Leo Yan
2019-07-03 10:00 ` Daniel Thompson
2019-07-03 10:00 ` Daniel Thompson
2019-07-03 10:28 ` Leo Yan
2019-07-03 10:28 ` Leo Yan
2019-07-02 10:34 ` [PATCH v1 11/11] perf cs-etm: " Leo Yan
2019-07-02 10:34 ` Leo Yan
2019-07-02 17:03 ` Mathieu Poirier
2019-07-02 17:03 ` Mathieu Poirier
2019-07-03 8:22 ` Leo Yan
2019-07-03 8:22 ` Leo Yan
2019-07-02 11:07 ` [PATCH v1 00/11] perf: Fix errors detected by Smatch Jiri Olsa
2019-07-02 11:07 ` Jiri Olsa
2019-07-03 1:48 ` Leo Yan
2019-07-03 1:48 ` Leo Yan
2019-07-03 18:18 ` Arnaldo Carvalho de Melo
2019-07-03 18:18 ` Arnaldo Carvalho de Melo
2019-07-04 7:29 ` Leo Yan
2019-07-04 7:29 ` Leo Yan
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=20190703184346.GE10740@kernel.org \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alexey.budankov@linux.intel.com \
--cc=alexios.zavras@intel.com \
--cc=changbin.du@intel.com \
--cc=dave@stgolabs.net \
--cc=davem@davemloft.net \
--cc=eric.saint.etienne@oracle.com \
--cc=jolsa@redhat.com \
--cc=khlebnikov@yandex-team.ru \
--cc=leo.yan@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=mathieu.poirier@linaro.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=songliubraving@fb.com \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=tmricht@linux.ibm.com \
--cc=yao.jin@linux.intel.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.