Null-Dereference bug in hash.c

[happy??????]

The maintainers of bison:
 
 
 
Hello. I am Zu-Ming Jiang, a master student at Tsinghua University
 
 
 
I find a null dereference bug in hash.c
 
 
 
Describe the bug??
 
the calloc() in the call stack shown below may fail:
 
# 1Call calloc() in hash_initialize(), at hash.c: 626
 
#2 Call hash_initialize() in symbols_new(), at symtab.c: 781
 
#3 Call symbols_new() in reader(), at reader.c: 714
 
#4 Call  reader() in  main(), at main.c: 104
 
 
 
If the calloc() in this call stack fails, It will make the global variable 
semantic_type_table become NULL.
 
 
 
And then, the program will call check_and_convert_grammar() in reader(), at 
reader.c: 741. Finally, the program will call safe_hasher(). The call stack is 
shown below.
 
 
 
#0  0x000055555561acae in safe_hasher (table=0x0, key=0x7fdb30) at 
lib/hash.c:251
 
#1  0x000055555561ab58 in hash_lookup (table=0x0, entry=0x7fdb30) at 
lib/hash.c:263
 
#2  0x00005f49d4 in semantic_type_from_uniqstr (key=0x55555586b630 "", loc=0x0) 
at src/symtab.c:825
 
#3  0x00005f2d37 in semantic_type_get (key=0x555555640115 "", loc=0x0) at 
src/symtab.c:858
 
#4  0x00005f2c04 in symbol_code_props_get (sym=0x555555875720, kind=destructor) 
at src/symtab.c:408
 
#5  0x00005f7524 in symbol_check_defined (sym=0x555555875720) at 
src/symtab.c:527
 
#6  0x00005f552c in symbol_check_defined_processor (sym=0x555555875720, 
null=0x0) at src/symtab.c:567
 
#7 0x00005f5486 in symbols_do (processor=0x5f54d0 
<symbol_check_defined_processor>, processor_data=0x0, table=0x55555586b7a0, 
sorted=0x55555585d080 <symbols_sorted>) at src/symtab.c:931
 
#8  0x00005f5225 in symbols_check_defined () at src/symtab.c:942
 
#9  0x00005c4a82 in check_and_convert_grammar () at bison-reader.s:813
 
#10 0x00005c4658 in reader () at bison-reader.s:741
 
#11 0x0000586144 in main (argc=3, argv=0x7fe308) at src/main.c:104
 
 
 
In semantic_type_from_uniqstr(), the program call hash_lookup() with 
semantic_type_table as the parameter table, so table is NULL in hash_lookup(). 
In hash_lookup(), the program call safe_hasher() with table as the parameter, 
so table is NULL in safe_hasher() too. Finally, the program executes the 
instruction size_t n = table->hasher (key, table->n_buckets) in safe_hasher(), 
as a result of which crash occurs since table is NULL.
 
 
 
Environment:
 
Bison version: 3.4
 
OS: Ubuntu 18.04
 
 
 
Addition:
 
This bug is found by my fuzzing tool and can be triggered at runtime.