Under preemptive priority scheduling, can a high-priority task ever be blocked by a low-priority one?

Yes, this is priority inversion, and it's the classic subtlety of preemptive priority systems. It happens when a high-priority task needs a resource (a mutex) that a low-priority task currently holds. The high-priority task blocks waiting for the mutex, so far unavoidable, but the real problem is unbounded priority inversion: while the low-priority task holds the lock, a medium-priority task that needs no lock becomes Ready and preempts the low-priority holder (because it outranks it). Now the medium task runs, the low task can't make progress to release the lock, and the high task stays blocked indefinitely behind a task that outranks it too, its effective priority has been inverted below the medium task's. This is exactly what stalled the Mars Pathfinder mission. The standard fix is priority inheritance: while a low-priority task holds a mutex that a higher-priority task is waiting on, the kernel temporarily boosts the holder to the waiter's priority, so no medium task can preempt it; it releases the lock quickly and reverts to its base priority. FreeRTOS mutexes (as opposed to plain binary semaphores) implement this. An alternative is the priority-ceiling protocol. The takeaway is that "highest-priority Ready task runs" is true, but shared resources can make a high-priority task not Ready but Blocked on something a lower task holds, and you need inheritance to bound how long that lasts.