Network stack reset can be used as a system-scale DoS vector

Assuming a remote attacker that can trigger a fault in the network stack at will, they can force the network stack reset to run continuously.

In such a case, the attacker can both prevent the network stack from functioning properly (since it is continuously resetting), as well as the whole system since the reset is resource intensive, leading to other compartments showing higher operation latency, potentially the device running out of battery, etc.

To prevent the reset from being used as a vector for system-wide DoS, we may want to add a mechanism to the reset that detects consecutive resets and throttles the reset rate harmoniously, e.g., first fault triggers an instant reset, second fault wait 500ms before initiating the reset, third reset wait 1s, fourth reset wait 2s, etc. until a threshold where we always wait, e.g., 20s before initiating a reset. We could keep a timestamp to reset that value if the resets are far apart.

Note that adding this shouldn't be hard at all. It would be nice to expose this policy to end-users through configuration.

The issue does not name files, tests, or an entry point. Start by locating the network stack reset path and its configuration surface, then determine how consecutive resets and elapsed time are tracked. Done means repeated resets are rate-limited without preventing recovery, with the policy exposed through configuration and covered by tests.

Written by the indexing model from the issue text.