Fragile Car Security Exposed: Mazda Infotainment Crash

Fragile Car Security Exposed: Mazda Infotainment Crash

Originally published on BleepingComputer, March 30th, 2022

Another day, another crash in automotive device software.

This time, the bug was found in the infotainment system of older model Mazdas from 2014-2017. Drivers reported that their HD radio receivers crashed when connecting to a local radio station. The radio and its display, bluetooth capabilities, built-in maps, and digital clocks were all fried.

According to reports, the system failure occurred due to a simple coding error that transpired when the radio station transmitted images without the required extension in the file names.

While frustrated Mazda owners waiting for their new $1500 CMU (Connectivity Master Unit) might disagree, this particular bug was relatively harmless – resulting in minimal damage. Unfortunately, chances are we’ll continue to hear reports of software breakdowns in vehicle systems, and as vehicles increasingly rely on code, risks of vulnerabilities affecting security and safety grow exponentially. Who knows how the next bug will impact drivers?


The complete details of the coding error that led to the crash of Mazda CMUs weren’t published, but we can assume that it was a type of NULL dereference vulnerability.

Here’s how that works:

In the C programming language, there is a function called strchr. This function receives two parameters: a pointer to a string and a character, and tries to find the character within the string, returning a pointer to the result found. If the function fails, a NULL pointer is returned. Then, the program will probably try to understand the extension of the specific file that it received.

In order to find the extension, a function similar to strcmp is probably used. This function receives two pointers and compares their contents. Eventually, the comparison is made through a dereferencing pointer. Dereferencing is the action of taking the value that the pointer is pointing at.

In this specific case, the NULL pointer was sent to this function, and while the function tried to dereference the value of the NULL, it got an exception.

This type of vulnerability in the code can be easily avoided by checking if the received pointer is different from NULL.


Preventing this type of issue in the development stage requires software engineers to follow secure coding standards that define how to write code in order to avoid security vulnerabilities in device software. However, while secure coding is key to preventing software vulnerabilities, it’s only one factor.

Coding will always be prone to human errors, even when written by the most experienced programmers. On top of that, most of the products we rely on today rely heavily on a supply chain that includes open source and third-party software that your programmers had no part in writing.


Car manufacturers are investing heavily in sophisticated automated safety controls, from steering and brakes to blind-spot detection and everything in between. Considering the fact that these systems have become increasingly reliant on software, why isn’t the same attention directed at automotive software security?

The cost of a software vulnerability in automotive devices skyrockets if it is discovered after the car hits the road. Beyond the price of pausing production or issuing recalls, software bugs could result in more than the inconvenience of a broken infotainment system. When found in critical safety features, they could actually affect human lives.

Insufficient attention to software security in automotive devices can turn cars into ticking time bombs. Today’s heavily automated cars demand OEMs extend their focus beyond physical car safety to include software security, from the earliest design stages all the way to tracking software versions that are already on the road.


Ensuring safe and vulnerability-free automotive devices requires additional steps beyond secure coding or manual bug tracking. That’s why firmware and code in all devices should be continuously monitored for vulnerabilities, to quickly detect and fix errors. Automated product security helps teams address security risks before – not after – they land companies in the headlines.

An advanced automotive product security platform, like Cybellum enables product security teams to track every single line of code in their software – whether it was created in-house or obtained from a third-party or open source – and ensure that software vulnerabilities are detected and addressed early, before they can cause costly injury to people and serious damage to manufacturers’ reputations.

The latest Mazda infotainment crash proves once again that a simple coding error can cause unforeseen mayhem. Luckily, this time, the damage was limited to infotainment and temporarily frustrated drivers plus a few headlines. Car manufacturers need to start prioritizing device security to ensure all the software their products rely on doesn’t drive them off the road.