3 ms·

Logic error in a video frame parser written in C, running in ring 0. No bounds checking. Another Friday. Diff: https://android.googlesource.com/kernel/common/+

by tux3 2y ago

Logic error in a video frame parser written in C, running in ring 0. No bounds checking. Another Friday. Diff: https://android.googlesource.com/kernel/common/+/96ad4e759ff4aaa24eb185500c0c28466ae5452a%5E%21/#F0 https://android.googlesource.com/kernel/common/+/96ad4e759ff...

1oooqooq 2y ago
at least better response when they had a remote exploit on the pixel modem os wich allowed full phone takeover and just delayed one update for almost two months and tried to pretend there was nothing to see there.
tialaramex 2y ago
This sort of code (for, you know, Wrangling Untrusted File Formats Safely) should be written in WUFFS. The nice thing about WUFFS for this specific problem is that although it's an entirely safe language† and is exactly the right way to do this, it also transpiles to C, so you can do the "Write file format code" stuff in WUFFS, transpile to C and then just land both in the kernel source. [You might wonder: Why both? Surely the C is enough? No, the GNU GPL says you should provide preferred form for modification and clearly the preferred form for this code is WUFFS source not C, the provided C is just so that people don't need the WUFFS transpiler to build Linux if that's what they're doing] † Entirely safe here meaning these mistakes won't even compile in WUFFS.
- wereHamster 2y ago
  Isn't it tragic that both Android and WUFFS are built by the same company? Sounds almost like the left hand doesn't know what the right hand is doing (or willingly ignores).
  - ajross 2y ago
    Despite the terminology in the article, this isn't an "Android" bug and wasn't "written" by Google. In fact the relevant code predates Android entirely.
ajross 2y ago
Not to interrupt your righteous indignity, but this bug is ancient. The relevant bug appears to be unchanged since this file was merged in June 2008. Writing it in Rust or whatever wasn't really an option. This attitude sort of irks me. It's not enough in a modern world of outrageous complexity to pronounce what should have been done. Someone needs to be actually doing it. I mean, let's be specific here: where exactly is the memory-safe USB UVC driver you think Android should be shipping? And if it doesn't exist, why doesn't it exist yet? That seems, IMHO, to be a more serious roadblock than the bug itself.
- tux3 2y ago
  >let's be specific here: where exactly is the memory-safe USB UVC driver you think Android should be shipping? I'm okay with Android shipping Linux. I have no problem with the choices that were made in the past. Still, we are forced to observe yet again the problems caused by old parsers written in plain C. Most bugs are in new code, so one hopes that we will eventually run out of buffer overflows in 2008 UVC drivers. Without having to call for rewriting everything all at once. But if and when we have to write new code, let's not make the same mistake again. I reserve all my righteous indignation for people who do not learn from the mistakes of the past.
  - ajross 2y ago
    Right, but what I'm saying is that people aren't writing that new code because no one wants to. Basically: If half the energy spent on righteous tut-tutting about Rust (or whatever) was given to writing memory-safe implementation of "boring" stuff like webcam drivers and not the sexy junk that ends up on HN, there'd be a lot less need for the irksome tut-tutting. Basically I think this says more about the psychology of the tut-tut set than it does development practice.
    - tux3 2y ago
      It isn't that there is a shortage of developers willing to write code. No, the kernel has entirely too many developers submitting to relatively few maintainers. So I don't take the psychology point at all. We already have more developers than we can handle. The problem is elsewhere. We have another thread at the moment about opposition to Rust drivers in the kernel. Writing the boring code is, I think, the easy part. Getting it past the old guard is another fight entirely. And not always fought on technical grounds. For every unit of energy that is spent writing code, twice that amount will be drained in endless bickering about whether modernity shall be permitted. And till the barriers disappear, the flow of exhausting discourse will continue crashing against the immovable wall of how it used to be.

by tux3 2y ago

1oooqooq 2y ago

at least better response when they had a remote exploit on the pixel modem os wich allowed full phone takeover and just delayed one update for almost two months and tried to pretend there was nothing to see there.

tialaramex 2y ago

This sort of code (for, you know, Wrangling Untrusted File Formats Safely) should be written in WUFFS. The nice thing about WUFFS for this specific problem is that although it's an entirely safe language† and is exactly the right way to do this, it also transpiles to C, so you can do the "Write file format code" stuff in WUFFS, transpile to C and then just land both in the kernel source. [You might wonder: Why both? Surely the C is enough? No, the GNU GPL says you should provide preferred form for modification and clearly the preferred form for this code is WUFFS source not C, the provided C is just so that people don't need the WUFFS transpiler to build Linux if that's what they're doing] † Entirely safe here meaning these mistakes won't even compile in WUFFS.

wereHamster 2y ago
Isn't it tragic that both Android and WUFFS are built by the same company? Sounds almost like the left hand doesn't know what the right hand is doing (or willingly ignores).
- ajross 2y ago
  Despite the terminology in the article, this isn't an "Android" bug and wasn't "written" by Google. In fact the relevant code predates Android entirely.

ajross 2y ago

Not to interrupt your righteous indignity, but this bug is ancient. The relevant bug appears to be unchanged since this file was merged in June 2008. Writing it in Rust or whatever wasn't really an option. This attitude sort of irks me. It's not enough in a modern world of outrageous complexity to pronounce what should have been done. Someone needs to be actually doing it. I mean, let's be specific here: where exactly is the memory-safe USB UVC driver you think Android should be shipping? And if it doesn't exist, why doesn't it exist yet? That seems, IMHO, to be a more serious roadblock than the bug itself.

tux3 2y ago
>let's be specific here: where exactly is the memory-safe USB UVC driver you think Android should be shipping? I'm okay with Android shipping Linux. I have no problem with the choices that were made in the past. Still, we are forced to observe yet again the problems caused by old parsers written in plain C. Most bugs are in new code, so one hopes that we will eventually run out of buffer overflows in 2008 UVC drivers. Without having to call for rewriting everything all at once. But if and when we have to write new code, let's not make the same mistake again. I reserve all my righteous indignation for people who do not learn from the mistakes of the past.
- ajross 2y ago
  Right, but what I'm saying is that people aren't writing that new code because no one wants to. Basically: If half the energy spent on righteous tut-tutting about Rust (or whatever) was given to writing memory-safe implementation of "boring" stuff like webcam drivers and not the sexy junk that ends up on HN, there'd be a lot less need for the irksome tut-tutting. Basically I think this says more about the psychology of the tut-tut set than it does development practice.
  - tux3 2y ago
    It isn't that there is a shortage of developers willing to write code. No, the kernel has entirely too many developers submitting to relatively few maintainers. So I don't take the psychology point at all. We already have more developers than we can handle. The problem is elsewhere. We have another thread at the moment about opposition to Rust drivers in the kernel. Writing the boring code is, I think, the easy part. Getting it past the old guard is another fight entirely. And not always fought on technical grounds. For every unit of energy that is spent writing code, twice that amount will be drained in endless bickering about whether modernity shall be permitted. And till the barriers disappear, the flow of exhausting discourse will continue crashing against the immovable wall of how it used to be.