[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all branches where testcase gfortran.dg/pr93337.f90 was committed. Thanks for the report!
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2bfcf6011a6cdce0439e3d1b94bcb5fcf078f4c2 commit r9-9151-g2bfcf6011a6cdce0439e3d1b94bcb5fcf078f4c2 Author: Harald Anlauf Date: Fri Jan 1 18:55:41 2021 +0100 PR fortran/96381 - invalid read in gfc_find_derived_vtab An invalid declaration of a CLASS instance can lead to an internal state with inconsistent attributes during parsing that needs to be handled with sufficient care when processing subsequent statements. Avoid a lookup of the vtab entry for such cases. gcc/fortran/ChangeLog: * class.c (gfc_find_vtab): Add check on attribute is_class. (cherry picked from commit d816b0c144d15e6570eb5b124b9f3ccbe3d40082)
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:78ff090d0a0bb5a77560203b3b49bb7da7fcb88c commit r10-9200-g78ff090d0a0bb5a77560203b3b49bb7da7fcb88c Author: Harald Anlauf Date: Fri Jan 1 18:55:41 2021 +0100 PR fortran/96381 - invalid read in gfc_find_derived_vtab An invalid declaration of a CLASS instance can lead to an internal state with inconsistent attributes during parsing that needs to be handled with sufficient care when processing subsequent statements. Avoid a lookup of the vtab entry for such cases. gcc/fortran/ChangeLog: * class.c (gfc_find_vtab): Add check on attribute is_class. (cherry picked from commit d816b0c144d15e6570eb5b124b9f3ccbe3d40082)
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #5 from anlauf at gcc dot gnu.org --- *** Bug 98263 has been marked as a duplicate of this bug. ***
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d816b0c144d15e6570eb5b124b9f3ccbe3d40082 commit r11-6405-gd816b0c144d15e6570eb5b124b9f3ccbe3d40082 Author: Harald Anlauf Date: Fri Jan 1 18:55:41 2021 +0100 PR fortran/96381 - invalid read in gfc_find_derived_vtab An invalid declaration of a CLASS instance can lead to an internal state with inconsistent attributes during parsing that needs to be handled with sufficient care when processing subsequent statements. Avoid a lookup of the vtab entry for such cases. gcc/fortran/ChangeLog: * class.c (gfc_find_vtab): Add check on attribute is_class.
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-January/055509.html
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 --- Comment #2 from anlauf at gcc dot gnu.org --- The following patch fixes the invalid read: diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c index 5677d920239..783e4c7354b 100644 --- a/gcc/fortran/class.c +++ b/gcc/fortran/class.c @@ -2906,7 +2906,9 @@ gfc_find_vtab (gfc_typespec *ts) case BT_DERIVED: return gfc_find_derived_vtab (ts->u.derived); case BT_CLASS: - if (ts->u.derived->components && ts->u.derived->components->ts.u.derived) + if (ts->u.derived->attr.is_class + && ts->u.derived->components + && ts->u.derived->components->ts.u.derived) return gfc_find_derived_vtab (ts->u.derived->components->ts.u.derived); else return NULL; Not regtested yet.
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-07-30 Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, one can see it in valgrind as well: ==1018== Invalid read of size 1 ==1018==at 0x7F10BB: gfc_find_derived_vtab(gfc_symbol*) (class.c:2269) ==1018==by 0x8484F3: gfc_match_assignment() (match.c:1393) ==1018==by 0x86F742: match_word (parse.c:65) ==1018==by 0x86F742: decode_statement() (parse.c:361) ==1018==by 0x874C14: next_free (parse.c:1315) ==1018==by 0x874C14: next_statement() (parse.c:1547) ==1018==by 0x87675C: parse_spec(gfc_statement) (parse.c:3962) ==1018==by 0x87949C: parse_progunit(gfc_statement) (parse.c:5892) ==1018==by 0x87AB80: gfc_parse_file() (parse.c:6433) ==1018==by 0x8CC54F: gfc_be_parse_file() (f95-lang.c:212) ==1018==by 0xE4C123: compile_file() (toplev.c:458) ==1018==by 0x7D2D91: do_compile (toplev.c:2327) ==1018==by 0x7D2D91: toplev::main(int, char**) (toplev.c:2466) ==1018==by 0x7D6B5E: main (main.c:39) ==1018== Address 0x51264ae is 18 bytes before a block of size 264 free'd ==1018==at 0x48399AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==1018==by 0x7DE7EF: gfc_match_array_spec(gfc_array_spec**, bool, bool) (array.c:802) ==1018==by 0x803396: variable_decl (decl.c:2520) ==1018==by 0x803396: gfc_match_data_decl() (decl.c:6200) ==1018==by 0x86F88D: match_word (parse.c:65) ==1018==by 0x86F88D: decode_statement() (parse.c:376) ==1018==by 0x874C14: next_free (parse.c:1315) ==1018==by 0x874C14: next_statement() (parse.c:1547) ==1018==by 0x876CC4: parse_derived (parse.c:3382) ==1018==by 0x876CC4: parse_spec(gfc_statement) (parse.c:3923) ==1018==by 0x87949C: parse_progunit(gfc_statement) (parse.c:5892) ==1018==by 0x87AB80: gfc_parse_file() (parse.c:6433) ==1018==by 0x8CC54F: gfc_be_parse_file() (f95-lang.c:212) ==1018==by 0xE4C123: compile_file() (toplev.c:458) ==1018==by 0x7D2D91: do_compile (toplev.c:2327) ==1018==by 0x7D2D91: toplev::main(int, char**) (toplev.c:2466) ==1018==by 0x7D6B5E: main (main.c:39)
