Port, board and/or hardware

stm32

MicroPython version

MicroPython v1.29.0, STM32 port.

Reproduction

This issue is in the STM32 C HAL and does not require Python code to reproduce.

Using MicroPython v1.29.0 for an STM32 target, add a call to mp_hal_get_mac_ascii() with an offset beyond the 12 hexadecimal characters represented by a six-byte MAC address:

char out[2];

mp_hal_get_mac_ascii(MP_HAL_MAC_WLAN0, 12, 1, out);

mp_hal_get_mac_ascii() first creates a six-byte local MAC buffer:

uint8_t mac[6];
mp_hal_get_mac(idx, mac);

It then converts the requested character range using:

dest[i] = hex[mac[chr_off >> 1] >> (4 * (1 - (chr_off & 1))) & 0xf];

For the reproduction above:

chr_off = 12
chr_off >> 1 = 6

so the function evaluates:

mac[6]

even though the valid indices of mac are only 0 through 5.

There is currently no validation that:

chr_off + chr_len <= 12

before indexing the six-byte MAC buffer.

The same issue can be reproduced with any request extending beyond the 12-character hexadecimal MAC representation, for example chr_off = 11, chr_len = 2.

The existing in-tree caller uses chr_off = 8, chr_len = 4 and therefore does not trigger the issue, but mp_hal_get_mac_ascii() is exposed through the STM32 HAL header and does not enforce the valid range for callers.

Expected behaviour

No response

Observed behaviour

mp_hal_get_mac_ascii() reads beyond the end of its local six-byte mac array when the requested hexadecimal slice extends past 12 characters.

For example, with:

mp_hal_get_mac_ascii(MP_HAL_MAC_WLAN0, 12, 1, out);

the function evaluates:

mac[chr_off >> 1]

as:

mac[6]

even though the valid indices are mac[0] through mac[5].

Depending on the build and runtime environment, this may return an incorrect hexadecimal character derived from adjacent stack memory, or be detected as an out-of-bounds read by a memory-safety instrumentation tool.

Additional Information

No, I've provided everything above.

Code of Conduct

Yes, I agree