[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Null-Dereference bug in hash.c

From: happy??????
Subject: Null-Dereference bug in hash.c
Date: Sat, 24 Aug 2019 14:50:37 +0800

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 
#1  0x000055555561ab58 in hash_lookup (table=0x0, entry=0x7fdb30) at 
#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 
#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 
#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.
Bison version: 3.4
OS: Ubuntu 18.04
This bug is found by my fuzzing tool and can be triggered at runtime.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]