* [Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
2022-05-24 8:42 [Bug sanitizer/105714] New: ASan in gcc trunk missed a buffer-overflow at -Os shaohua.li at inf dot ethz.ch
@ 2022-05-24 8:52 ` marxin at gcc dot gnu.org
2022-05-24 9:06 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-05-24 8:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714
Martin Liška <marxin at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-05-24
Summary|ASan in gcc trunk missed a |[12/13 Regression] ASan in
|buffer-overflow at -Os |gcc trunk missed a
| |buffer-overflow at -Os
| |since
| |r12-5138-ge82c382971664d6f
CC| |aldyh at gcc dot gnu.org,
| |amacleod at redhat dot com
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r12-5138-ge82c382971664d6f.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
2022-05-24 8:42 [Bug sanitizer/105714] New: ASan in gcc trunk missed a buffer-overflow at -Os shaohua.li at inf dot ethz.ch
2022-05-24 8:52 ` [Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f marxin at gcc dot gnu.org
@ 2022-05-24 9:06 ` jakub at gcc dot gnu.org
2022-05-24 9:27 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-24 9:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'll have a look...
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
2022-05-24 8:42 [Bug sanitizer/105714] New: ASan in gcc trunk missed a buffer-overflow at -Os shaohua.li at inf dot ethz.ch
2022-05-24 8:52 ` [Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f marxin at gcc dot gnu.org
2022-05-24 9:06 ` jakub at gcc dot gnu.org
@ 2022-05-24 9:27 ` jakub at gcc dot gnu.org
2022-05-24 9:54 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-24 9:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is we have:
<bb 6> [local count: 354334800]:
# h_21 = PHI <h_15(6), 0(5)>
*c.3_5 = *d.2_4;
h_15 = h_21 + 1;
if (h_15 != 3)
goto <bb 6>; [75.00%]
else
goto <bb 7>; [25.00%]
<bb 7> [local count: 118111600]:
*c.3_5 = MEM[(struct a *)&b + 12B];
_13 = c.3_5->x;
return _13;
We instrument in the *c.3_5 = *d.2_4 both the load and store, but then
when considering instrumentation of *c.3_5 = MEM[(struct a *)&b + 12B];
has_stmt_been_instrumented_p returns true because *c.3_5 has been indeed
instrumented in a dominating bb. But the rhs hasn't been...
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
2022-05-24 8:42 [Bug sanitizer/105714] New: ASan in gcc trunk missed a buffer-overflow at -Os shaohua.li at inf dot ethz.ch
` (2 preceding siblings ...)
2022-05-24 9:27 ` jakub at gcc dot gnu.org
@ 2022-05-24 9:54 ` jakub at gcc dot gnu.org
2022-05-25 10:08 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-24 9:54 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53028
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53028&action=edit
gcc13-pr105714.patch
Untested fix.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug sanitizer/105714] [12/13 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
2022-05-24 8:42 [Bug sanitizer/105714] New: ASan in gcc trunk missed a buffer-overflow at -Os shaohua.li at inf dot ethz.ch
` (3 preceding siblings ...)
2022-05-24 9:54 ` jakub at gcc dot gnu.org
@ 2022-05-25 10:08 ` cvs-commit at gcc dot gnu.org
2022-05-25 14:11 ` [Bug sanitizer/105714] [12 " jakub at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-25 10:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:af02daff557a0abbf5521c143f1cdda406848a9b
commit r13-756-gaf02daff557a0abbf5521c143f1cdda406848a9b
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed May 25 12:05:08 2022 +0200
asan: Fix up instrumentation of assignments which are both loads and stores
[PR105714]
On the following testcase with -Os asan pass sees:
<bb 6> [local count: 354334800]:
# h_21 = PHI <h_15(6), 0(5)>
*c.3_5 = *d.2_4;
h_15 = h_21 + 1;
if (h_15 != 3)
goto <bb 6>; [75.00%]
else
goto <bb 7>; [25.00%]
<bb 7> [local count: 118111600]:
*c.3_5 = MEM[(struct a *)&b + 12B];
_13 = c.3_5->x;
return _13;
It instruments the
*c.3_5 = *d.2_4;
assignment by adding
.ASAN_CHECK (7, c.3_5, 4, 4);
.ASAN_CHECK (6, d.2_4, 4, 4);
before it (which later lowers to checking the corresponding shadow
memory). But when considering instrumentation of
*c.3_5 = MEM[(struct a *)&b + 12B];
it doesn't instrument anything, because it sees that *c.3_5 store is
already instrumented in a dominating block and so there is no need
to instrument *c.3_5 store again (i.e. add another
.ASAN_CHECK (7, c.3_5, 4, 4);
). That is true, but misses the fact that we still want to
instrument the MEM[(struct a *)&b + 12B] load.
The following patch fixes that by changing has_stmt_been_instrumented_p
to consider both store and load in the assignment if it does both
(returning true iff both have been instrumented).
That matches how we handle e.g. builtin calls, where we also perform AND
of all the memory locs involved in the call.
I've verified that we still don't add the redundant
.ASAN_CHECK (7, c.3_5, 4, 4);
call but just add
_18 = &MEM[(struct a *)&b + 12B];
.ASAN_CHECK (6, _18, 4, 4);
to instrument the load.
2022-05-25 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105714
* asan.cc (has_stmt_been_instrumented_p): For assignments which
are both stores and loads, return true only if both destination
and source have been instrumented.
* gcc.dg/asan/pr105714.c: New test.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug sanitizer/105714] [12 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
2022-05-24 8:42 [Bug sanitizer/105714] New: ASan in gcc trunk missed a buffer-overflow at -Os shaohua.li at inf dot ethz.ch
` (4 preceding siblings ...)
2022-05-25 10:08 ` cvs-commit at gcc dot gnu.org
@ 2022-05-25 14:11 ` jakub at gcc dot gnu.org
2022-05-30 3:36 ` cvs-commit at gcc dot gnu.org
2022-05-30 7:58 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-25 14:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[12/13 Regression] ASan in |[12 Regression] ASan in gcc
|gcc trunk missed a |trunk missed a
|buffer-overflow at -Os |buffer-overflow at -Os
|since |since
|r12-5138-ge82c382971664d6f |r12-5138-ge82c382971664d6f
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.
The bug really exists in older releases too, just this testcase doesn't trigger
it in gcc 11 or older.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug sanitizer/105714] [12 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
2022-05-24 8:42 [Bug sanitizer/105714] New: ASan in gcc trunk missed a buffer-overflow at -Os shaohua.li at inf dot ethz.ch
` (5 preceding siblings ...)
2022-05-25 14:11 ` [Bug sanitizer/105714] [12 " jakub at gcc dot gnu.org
@ 2022-05-30 3:36 ` cvs-commit at gcc dot gnu.org
2022-05-30 7:58 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-30 3:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:120d99a3ec3f13766e13b40e48b0614242447fea
commit r12-8433-g120d99a3ec3f13766e13b40e48b0614242447fea
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed May 25 12:05:08 2022 +0200
asan: Fix up instrumentation of assignments which are both loads and stores
[PR105714]
On the following testcase with -Os asan pass sees:
<bb 6> [local count: 354334800]:
# h_21 = PHI <h_15(6), 0(5)>
*c.3_5 = *d.2_4;
h_15 = h_21 + 1;
if (h_15 != 3)
goto <bb 6>; [75.00%]
else
goto <bb 7>; [25.00%]
<bb 7> [local count: 118111600]:
*c.3_5 = MEM[(struct a *)&b + 12B];
_13 = c.3_5->x;
return _13;
It instruments the
*c.3_5 = *d.2_4;
assignment by adding
.ASAN_CHECK (7, c.3_5, 4, 4);
.ASAN_CHECK (6, d.2_4, 4, 4);
before it (which later lowers to checking the corresponding shadow
memory). But when considering instrumentation of
*c.3_5 = MEM[(struct a *)&b + 12B];
it doesn't instrument anything, because it sees that *c.3_5 store is
already instrumented in a dominating block and so there is no need
to instrument *c.3_5 store again (i.e. add another
.ASAN_CHECK (7, c.3_5, 4, 4);
). That is true, but misses the fact that we still want to
instrument the MEM[(struct a *)&b + 12B] load.
The following patch fixes that by changing has_stmt_been_instrumented_p
to consider both store and load in the assignment if it does both
(returning true iff both have been instrumented).
That matches how we handle e.g. builtin calls, where we also perform AND
of all the memory locs involved in the call.
I've verified that we still don't add the redundant
.ASAN_CHECK (7, c.3_5, 4, 4);
call but just add
_18 = &MEM[(struct a *)&b + 12B];
.ASAN_CHECK (6, _18, 4, 4);
to instrument the load.
2022-05-25 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105714
* asan.cc (has_stmt_been_instrumented_p): For assignments which
are both stores and loads, return true only if both destination
and source have been instrumented.
* gcc.dg/asan/pr105714.c: New test.
(cherry picked from commit af02daff557a0abbf5521c143f1cdda406848a9b)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug sanitizer/105714] [12 Regression] ASan in gcc trunk missed a buffer-overflow at -Os since r12-5138-ge82c382971664d6f
2022-05-24 8:42 [Bug sanitizer/105714] New: ASan in gcc trunk missed a buffer-overflow at -Os shaohua.li at inf dot ethz.ch
` (6 preceding siblings ...)
2022-05-30 3:36 ` cvs-commit at gcc dot gnu.org
@ 2022-05-30 7:58 ` jakub at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-30 7:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105714
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed for 12.2 too.
^ permalink raw reply [flat|nested] 9+ messages in thread