88 'high-risk' security defects found in Android kernel

A security audit of the Android kernel has turned up 88 "high-risk defects" with with significant potential to cause security vulnerabilities, data loss, or quality problems such as system crashes.

According to Coverity, a source code analysis firm, the high-risk defects included memory corruption flaws, memory illegal accesses and resource leaks.

The analysis was conducted against the Android kernel 2.6.32 (code named “Froyo”).  This kernel is targeted for smartphones based on the Qualcomm MSM7xxx/QSD8x50 chipset, specifically the HTC Droid Incredible. In addition to the standard kernel, this version includes support for wireless, touchscreen, and camera drivers.

Here's the gist of Coverity's findings:

• The Android kernel used in the HTC Droid Incredible has about half the defects that would be expected for similar software of the same size.
• The Android kernel has better than industry average defect density (one defect for every 1,000 lines of code); however the report discovered 359 defects that are believed to be in the shipping version of the HTC Droid Incredible. We believe the defects we found are a sample of what could be shipping in many OEMs devices and products that leverage the Android platform.
• We found 88 high-risk defects in Android: 25% of the Android defects discovered, including memory corruptions, memory illegal accesses, and resource leaks, are considered high-risk with significant potential to cause security vulnerabilities, data loss, or quality problems such as system crashes. These are traditionally defect types that many of our customers fix and eliminate completely prior to shipping a product.
• Accountability for Android software integrity is fragmented. The problem is no different with Android than what we see across open source. Android is based on Linux, which has thousands of contributors. Compound that with the Android developers from Google, the contributors to Android from the larger development community, and OEMs that supply components for specific configurations of Android to support different types of devices, and the lines of accountability are quickly blurred. It’s not clear who is ultimately accountable, but it is clear that a new level of visibility is needed to provide the OEMs that incorporate Android in their software supply chain with an objective measurement of Android software integrity.