We should be wary about the "high risk defects" recently found in an Android kernel by a code scanner: wary as in aware of and concerned about them, and wary also as in avoiding too much false alarm.
There are no specific security-threatening exploits that take advantage of the Android defects that anyone knows of. The defects are not widely known because they are part of recently drafted code added to a vendor-sponsored version of the Android kernel. The party responsible for the defective code is phone producer HTC, not Google, although other versions of Android are in use by other device manufacturers, and their mobile operating systems will be subject to future scans.
Why was HTC scanned first? Because it sponsors its Droid Incredible operating system as an open source project and recently posted the open source code to its website. Coverity downloaded it and ran its rigorous scan. It expects to find one defect per 1,000 lines of code on average, whether that code is commercial or open source code. The defect rate in HTC's kernel was .47 defects per 1,000 lines, or slightly less than one per 2,000 lines of code. That's still too high for code that is going into devices depended upon daily by thousands or more likely, hundreds of thousands, of users.
It will also be too many once Coverity publishes its findings 3-4 months out. It's giving both the manufacturer and open source project a chance to close the holes before its scan results are aired and the code is tested again.
Open source projects such as the Linux kernel development process and Samba have achieved incredibly low defect rates, not by writing perfect code, but in a disciplined approach to going back and eliminating defects. The fact that open source code is open to an inspector such as Coverity means you, a member of the public, have a chance to learn about its defect rate. Unlike open source code projects, commercial code vendors pay Coverity to scan their code and neither party airs the results.
The fact that open source defects will be publicized provides an incentive to the project's developers to not let them slide. Rather, they know re-inspection is coming, along with chagrin if they are exposed as not caring about or fixing known defects.
But the main point here is the nature of the defects. Though labeled "high risk," they are not the same as operating system or browser exposures that are inviting a visit by known exploits already in circulation. They are risky more for program integrity and continuous operation than security, although at some point, there is a security exposure as well.
