-
Notifications
You must be signed in to change notification settings - Fork 97
Description
Hi, I found two cases where the function strdup is called, but their return values are not checked, which may lead to null pointer dereference bug. Can you please help me check it? Thank you for your effort and patience!
Below is the execution sequence of the program that may produce null pointer dereference bug.
CASE 1:
step 1: In the file src/common/pci_dev.c, the function pci_bus_create calls strdup at line 398, which may return NULL. Thus, the receiver d->name may be NULL.
step 2: In the file src/common/dev_c6msfc1.c, the function c6msfc1_init_gt64010 receives the return value of pci_bus_create with vm->pci_bus[0] at line 325, which means vm->pci_bus[0]->name may be NULL, and it uses vm as param at line 330.
step 3 and 4: In the function dev_gt64010_init in src/common/dev_gt.c, vm->pci_bus[0] is assigned to d->bus[0] and d->bus[0] used as param at line 2660.
step 5: In the file src/common/pci_dev.c, the function pci_dev_add uses pci_bus->name as param of fprintf, which may lead to null pointer dereference vulnerability.
CASE2:
In the file src/common/dynamips.c , the function run_hypervisor calls strdup at line 837 without checking its return value, and the receiver is used as param of printf, which may lead to null pointer dereference vulnerability.
However, the return value of strdup is checked in the function atm_bridge_create in src/common/atm_bridge.c at line 110. The same can be found in many other files, such as src/common/dev_ram.c


