According this post was "resolved":
The CanDriver has a bug (That can I reproduce) on the management of the hardware RxFifo.
I am using the MQX drivers and have looked through the example code given, unfortunately the example doesn't seem geared towards the RxFIFO and I seem to be doing everything they are in the example. It feels like the hardware thinks message buffers 0-5 are in use when the first message comes in. I have stepped through the code and when the interrupt is fired my message is in the RxFIFO buffer 0 and then when the interrupt is cleared it goes to the end of the fifo and the system reads packets of zeros. After 6 messages are received I finally get my very first message to be processed.
The fsl_flexcan driver in MQX 4.1 has a bug: the interrupt happens when the message comes in, but it doesn't copy out the message before it clears the interrupt. When the driver reads out the message later, it always seems like you're queue-length messages behind.
This has been fixed in Kinetis SDK 1.1.0, but I don't know how that applies to the straight MQX distributions.
This post was written when MQX 4.2 does not exist, but after test, the problem still present on MQX 4.2.
Is anybody has made a patch to resolve this problem?