Setting excessively large parameter values causes arithmetic overflow

ArduCopter
1

Specifically, when the copter is flying normally, setting SIM_IMU_POS_X/SIM_IMU_POS_Y/SIM_IMU_POS_Z to 800 triggers a floating-point exception. I have not tested the minimum overflow value.
I found that this is a very common issue. Such problems (arithmetic overflow) have existed for several years. I believe that validity checks should be performed on parameter values to ensure that overly large assignments do not cause the drone to crash. If someone can connect to the copter, they only need to adjust this single parameter to make the drone crash. In some cases, users might even unintentionally set these parameters incorrectly. I think this is catastrophic.
How do you all view this issue?

Additionally, I would like to ask why saving dumpstack and dumpcore fails?
Thanks!

samebug1a2
samebug1a2805Ă—847 59.1 KB

2

We can not and will not bloat embedded firmware with hundreds of limit checks.

The GCS has no memory footprint restrictions and should perform these checks for you.

A proper ArduPilot parameter management application like ArduPilort Methodic Configurator does this for you and additionally makes sure that the parameter is correctly written to the FC.

So this is basically a feature that will not be implemented in Firmware, but is already readlly available in multiple GCS software. ArduPilot Methodic configurator being probably the single one that uses different parameter limits based on the software version loaded in the FC. For example version 4.2.3 will have different parameter limits than 4.6.0 for some of it’s parameters.

3

Hi! Thank you very much for your explanation. To be honest, this is the first time I’ve heard about this application, and it indeed seems to help users operate drones better and more accurately under the premise of “user awareness”. Therefore, I was wondering if it could be recommended to users in the wiki?

However, I still want to express my concerns regarding security. Arithmetic overflows can cause significant harm on regular PCs, and I’ve noticed that the AP has already established connections with ROS/ROS2, which increases the number of interfaces for accessing drones. I just wanted to highlight that this potential risk might lead to security issues in the future (or may already be causing them).

4

If someone can successfully connect to your craft and alter parameters, the least of your concerns is an overflow…

Not that you aren’t raising a valid point, but I think it’s overshadowed by other concerns.

1 Like
5

Thank you. Regarding the attack effects, I agree with your perspective.
Similar to some previous reports on arithmetic overflows, I just wanted to provide some parameters that could trigger arithmetic overflows to help improve the robustness of AP parameters.

6

You are not the first one presenting this very same idea. You are at least the third person.

I gave you a short description of the results and decisions taken after the first reports.

7

I would add that SIM* parametrach are only used in SITL and given that such high value of the offset lead to ridiculous coupling between angular and measured accelerations.
Said error might be even occuring in the SITL code that isn’t compiled for actual vehicles.

If your UAV is exposed to adversary inputs there are many much simpler ways of crashing it that will leave less obvious trail.

8

One important thing I learned from a professional was to refresh parameters after making changes so you can see if the planned changes actually took place, and if the values look correct.

1 Like
9

@xfacta that is the thing that I mentioned above: ArduPilot Methodic configurator does that automatically every time. So you do not need to do that.

But yes, if you use Mission Planner manually refreshing every time is a must.

1 Like