Exploiting stack buffer overflows on an Arduino
Your question can be read two ways, DarkCoffee:

If a particular Arduino based device can be induced to overflow its stack, can it be exploited?

Yes, it is possible to exploit a stack overflow on an Arduino.

One possible attack is the return oriented programming method, which requires sufficiently complex firmware. So, one defense here is to keep your firmware as simple as possible. It is highly unlikely that the Arduino "hello world" sketch is vulnerable. That shouldn't be much comfort to you, though, because an LED blinker isn't terribly useful. Useful firmware will have more functions, and therefore more function tails to harvest for use in an abstract machine.

The Arduino also has a boot loader, which inherently has the power to overwrite firmware. It may be possible to exploit it to overwrite existing benign but vulnerable firmware with malign firmware.

My reading of the first page of the INRIA attack paper leads me to believe it combines both approaches: return oriented programming to execute enough code to activate the self-flashing ability of the microcontroller so that arbitrary code can be permanently loaded.

Are there stack overflow attacks on Arduinos in general?

I'm not aware of any attack that works on all Arduino based devices. Again, the "hello world" LED blinker sketch is probably invulnerable, simply because it is too trivial to be vulnerable.

The more code you write, the more likely it is that you will create a vulnerability.

Note that writing 5,000 lines of code then replacing 2 kLOC with 1,000 new lines isn't a net savings of 1&nbsp;kLOC from a security standpoint. If those 5&nbsp;kLOC were secure and you messed up while writing some of the new 1&nbsp;kLOC, it's still a vulnerability. The moral of the story is that the most secure code tends to be that which is stared at the longest, and that means keeping it unchanged as long as possible.

Obviously, every vulnerability should be patched ASAP. This is no argument for keeping old vulnerabilities around. It's an argument against adding features thoughtlessly to code you believe secure though inspection, audit, and analysis.