The value of setting configKERNEL_INTERRUPT_PRIORITY is interpreted at a low level on Cortex M ports as a priority setting mask, so it must be left shifted to the most significant bits.

REF: "Cortex-M Internal Priority Representation" https://www.freertos.org/RTOS-Cortex-M3-M4.html

The configMAX_SYSCALL_INTERRUPT_PRIORITY and configKERNEL_INTERRUPT_PRIORITY settings found in FreeRTOSConfig.h require their priority values to be specified as the ARM Cortex-M core itself wants them - already shifted to the most significant bits of the byte. That is why configKERNEL_INTERRUPT_PRIORITY, which should be set to the lowest interrupt priority, is set to 255 (1111 1111 in binary) in the FreeRTOSConfig.h header files delivered with each official FreeRTOS demo. The values are specified this way for a number of reasons: The RTOS kernel accesses the ARM Cortex-M3 hardware directly (without going through any third party library function), the RTOS kernel implementation pre-dates most library function implementations, and this was the scheme used by the first ARM Cortex-M3 libraries to come to market.

The line brought in at commit 0ab4bbd9507f2c8fd15ae1ca755aee6334860ad9:

#define configKERNEL_INTERRUPT_PRIORITY 14

is a BUG, since it sets the kernel preemption interrupt to a very high priority (numerically low). This can lead to subtle memory corruption issues which are fairly hard to debug. The proper value consistent with how this priority setting is used by the port and the intention of the mistaken commit to lower the value (raise the logical priority) from the actual lowest priority level of 15 would thus be:

#define configKERNEL_INTERRUPT_PRIORITY   ( 14 << (8 - configPRIO_BITS) )

Background:
I discovered this bug, because I had used the Github main branch as a reference to make my own STM32FreeRTOSConfig.h file. I was experiencing persistent hard faults and submitted this issue for help. Eventually, I solved this problem when I accidentally remade my config from an older stable version before the above mentioned commit. I was confused about why one of my test systems became stable but the other didn't. I eventually diffed the configs to find out this mistaken interrupt priority configuration in the main branch.