Opened 6 years ago
Closed 4 years ago
#16 closed feature (fixed)
Undetected double free
Reported by: | Henrich Lauko | Owned by: | Henrich Lauko |
---|---|---|---|
Priority: | major | Milestone: | 5.0 |
Component: | LART | Keywords: | |
Cc: |
Description
In current divine, we are not able to detect possible double free here.
#include <stdlib.h> int main() { void *x = malloc(0x1000); free(x); void *y = malloc(0x1000); if (x == y) free(y); free(y); }
Is there a way we would be able to do that?
Change History (4)
comment:1 Changed 6 years ago by
comment:3 Changed 6 years ago by
Component: | VM → LART |
---|---|
Owner: | changed from mornfall to Henrich Lauko |
Type: | defect → feature |
comment:4 Changed 4 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
The comparison is now reported as an error by verify
, so the program is not accidentally accepted. It's then possible to use refinement & symbolic pointers to deal with the comparison, in which case the double free is detected, as desired.
$ divine refine --output testcase.bc --refinement pointers test.c compiling test.c $ divine verify --lamp pointers --symbolic test.bc loading bitcode … DiOS … LART … RR … constants … done booting … done states per second: 20.8333 state count: 5 mips: 0.33 symbolic: 1 error found: yes error trace: | ASSUME (not (= var_1 #x00000000)) ASSUME (and (not (= var_1 #x00000000)) (= #xbf959e0700000000 (concat var_1 #x00000000))) FAULT: invalid pointer passed to __vm_obj_free [0] FATAL: memory error in userspace active stack: - symbol: void __dios::FaultBase::handler<__dios::Context>(_VM_Fault, _VM_Frame*, void (*)()) location: /dios/sys/fault.hpp:118 - symbol: free location: /dios/libc/_PDCLIB/glue.c:49 - symbol: main location: test.c:10 - symbol: __dios_start location: /dios/libc/sys/start.cpp:91 a report was written to test.report
Note: See
TracTickets for help on using
tickets.
This is pretty much a use-case for the pointer domain described in the medium-term roadmap, where objid's are symbolic in numeric contexts but explicit in pointer contexts. There would be some fiddling to do with lifetime overlaps, since we may need to maintain a number of constraints on such symbolic object identifiers (namely that they are distinct from each other if the object lifetimes overlap). This may be a little annoying, but i don't imagine it's a showstopper.