Memory leaks in LazyPRM.cpp

[wbq1234]

Here are some outputs:

#0 0x7f5dbf085532 in operator new(unsigned long)
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x99532)
#1 0x7f5dbe484b59 in ompl::base::RealVectorStateSpace::allocState() const
/ompl-main/src/ompl/base/spaces/src/RealVectorStateSpace.cpp:274
#2 0x7f5dbe3d7814 in ompl::base::StateSpace::cloneState(ompl::base::State const*) const
/ompl-main/src/ompl/base/src/StateSpace.cpp:228
#3 0x7f5dbe996993 in ompl::base::SpaceInformation::cloneState(ompl::base::State const*) const
/ompl-main/src/ompl/base/SpaceInformation.h:259
#4 0x7f5dbe996993 in ompl::geometric::LazyPRM::solve(ompl::base::PlannerTerminationCondition const&)
/ompl-main/src/ompl/geometric/planners/prm/src/LazyPRM.cpp:368

After our analysis, this crash comes from LazyPRM.cpp. In line 368/343/324 of lazyPRM.cpp, they can apply for memory space. At the same time, the freeMemory() function can release the memory. However, during our testing, the program will still run to LazyPRM.cpp: 368/343/324 (application meomory space) after the last call of freeMemory(), so the memory space is not completely released and causing memory leaks.

[wbq1234]

After tracing and analyzing, we fixed it on LazyPRM.cpp:151,we modified the destructor as flowling:

Call freeMemory() can solve the problem.As we know: the program will still apply for memory for states after the last call of freeMemory().So we can call freeMemory() in the destructor.Finally,the problem will be solved.

[carnil]

This issue was referenced for CVE-2021-41490