some special msg onto /initialpose could lead to heap-buffer-overflow bug
#4307
Comments
|
You know what to do 😉 |
|
Ah... I think the situation here might be a bit different and not suitable for validation through In my understanding, And I believe it's more appropriate to perform the check in the callback process of
Overall, I think agreeing on an upper limit for x and implementing it in the callback process of However, I'm still checking the specific line of code where the overflow occurs and haven't confirmed it yet. I think here would be a better method to fix it after a further check. SO, I'd further confirm the specific line of code causing the buffer overflow and investigate why JUST a large value (still in the range of |
Ok! I trust your opinion 😄 Let me know what you think is best! |
|
@GoesM any update? |
|
I'm so sorry for my late work about this issue because I'm struggled by other works. T_T After the updating humble-branch, Additional Information:**which code-line met to I insert code for log as following: void goes_debug(int cnt){
fprintf(stderr, "[GOES|DEBUG]:---------- %d \n", cnt);
}
// Re-compute the cluster statistics for a sample set
void pf_cluster_stats(pf_t * pf, pf_sample_set_t * set)
{
...
...
goes_debug(3);
// Compute cluster stats
for (i = 0; i < set->sample_count; i++) {
...
...
goes_debug(4);
cluster = set->clusters + cidx;
goes_debug(5);
cluster->weight += sample->weight;
goes_debug(6);
weight += sample->weight;
goes_debug(7);
...
...
}
...
}And I catched the log during the crash: [amcl-7] [INFO] [1717073213.332957908] [amcl]: Setting pose (5.019000): -751613824.000 0.378 3.142
[amcl-7] [GOES|DEBUG]:---------- 1
[amcl-7] [GOES|DEBUG]:---------- 2
[amcl-7] [GOES|DEBUG]:---------- 3
[amcl-7] [GOES|DEBUG]:---------- 4
[amcl-7] [GOES|DEBUG]:---------- 5
[amcl-7] [GOES|DEBUG]:---------- 6
[amcl-7] [GOES|DEBUG]:---------- 7
[amcl-7] [GOES|DEBUG]:---------- 4
[amcl-7] [GOES|DEBUG]:---------- 5
[ERROR] [amcl-7]: process has died [pid 111426, exit code 1, cmd '/home/goes/ROS_Workstation/humble_fork/install/nav2_amcl/lib/nav2_amcl/amcl --ros-args --log-level info --ros-args -r __node:=amcl --params-file /tmp/launch_params_t5mx02k0 -r /tf:=tf -r /tf_static:=tf_static'].It proves that the bug occurs in line: navigation2/nav2_amcl/src/pf/pf.c Line 521 in cf3dd55 And it seems like |
|
However, I am not an expert about the pf-calculation , and not clear whether such buffer-overflow is related to the size of map or not ? If related to , I think we could add a check to ensure that the received pose is within the map range ? |
|
Sure! That seems sensible |
Bug report
Required Info:
Steps to reproduce issue
Launch the navigation2 normally, as following steps:
Curious about how nav2 face to topic-interception, i sent validate
/PoseWithCovarianceStampedmsg onto topic/initialpose, which is like this:[notice] the value of
xof thepositionis-751613824.000000, which leads to the heap-buffer-overflow.Expected behavior
Actual behavior
The ASAN reporting a stack-buffer-overflow bug to me as following, and the
nav2_amclstop its work.Additional information
it seems like that a high value of
xcould lead to such bug...The text was updated successfully, but these errors were encountered: