arduino / arduino/ArduinoCore-avr
Potential corruption in attachInterrupt()
- Dominant language
- C
- Stars
- 1.5k
- Forks
- 1.1k
- PR merge metrics
- No merged PRs in 30d
Description
The Arduino reference for `attachInterrupt()` states, in the syntax section, that this function should be called as per:
````
attachInterrupt(digitalPinToInterrupt(pin), ISR, mode); (recommended)
````
However, `digitalPinToInterrupt()` returns `NOT_AN_INTERRUPT` (or -1) if a pin other than 2 or 3 is passed. Within the code for `attachInterrupt()` in `WInterrupts.c`, I see this:
````
void attachInterrupt(uint8_t interruptNum, void (*userFunc)(void), int mode) {
if(interruptNum < EXTERNAL_NUM_INTERRUPTS) {
intFunc[interruptNum] = userFunc;
````
So, if called as recommended, and an invalid pin is passed, the -1is indeed less than `EXTERNAL_NUM_INTERRUPTS` (or 2) and so the access to the array is out of bounds and may corrupt whatever is in memory just before the array.
I suggest the following should (!) fix it:
````
if(interruptNum < EXTERNAL_NUM_INTERRUPTS &&
interruptNum >= 0) {
intFunc[interruptNum] = userFunc;
````
That way, `NOT_AN_INTERRUPT` will be ignored. Just for safety, I would probably do a similar edit to `detachInterrupt()` as it doesn't validate the incoming interrupt number for `NOT_AN_INTERRUPT` either.
Cheers.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in WInterrupts.c with attachInterrupt() and detachInterrupt(), then compare their handling of NOT_AN_INTERRUPT with digitalPinToInterrupt(). Done means invalid interrupt numbers are ignored without an out-of-bounds access or memory corruption, while valid interrupts retain their existing behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100