88 'high-risk' security flaws found in Android Kernel

An Android kernel audit uncovered 88 "high-risk flaws" that have significant potential to cause security vulnerabilities, data loss, or quality issues such as system crashes.

According to Coverity, a firm dedicated to code analysis, high-risk flaws include memory corruption failures, illegal memory access, and resource leaks.

The analysis was performed on the kernel 2.6.32 of Android "froyo". This kernel is geared towards smartphones based on the Qualcomm MSM7xxx/QSD8×50 chipset , specifically the HTC Droid Incredible. In addition to the standard kernel , this version includes support for wireless access, touch screen and camera drivers .

Here are the essentials of what Coverity found:

• The Android kernel used in the HTC Droid Incredible has about half the flaws you'd expect in similar software of the same size.
• The Android kernel has a better average than the industry in error density (one defect per 1,000 lines of code); however the report uncovered 359 flaws believed to be in the shipped version of the HTC Droid Incredible. We believe that the defects we found are an example of what could be shipped on many OEM devices and products that rely on the Android platform.
• We found 88 high-risk defects in Android: 25% of the defects discovered in Android, including memory corruptions, illegal memory accesses and resource leaks that are considered high risk with considerable potential to cause security vulnerabilities, data loss, or quality issues such as system crashes. These are types of defects that many of our customers fix and eliminate completely before dispatching a product.
• Responsibility for the integrity of Android software is fragmented. The problem is no different with Android than what we see through open source. Android is based on Linux, which has thousands of contributors. Add to that Google's Android developers, Android contributors from the large developer community, and OEMs that provide components for Android-specific configurations to support different types of devices, and the lines of responsibility quickly become blurred. It's unclear who is ultimately responsible, but it's clear that a new level of visibility is needed to give OEMs incorporating Android into their software supply chain an objective measure of Android software integrity.

See original.