> However, based on open-source codebases for these different devices' kernels, it appears MediaTek is actively maintaining several different trees for this driver, likely based on the associated kernel version, and these two devices use separate trees.
This one sentence just perfectly sums up everything that's broken in the embedded (i.e. everything non-x86) world. Everyone just forks random stuff at random points in the BSP's life time, and no one makes even the slightest effort to upstream it to mainline Linux (if that's possible at all given that Android's Linux fork itself does a lot of things differently than Linux upstream likes).
> I found two vulnerabilities in this driver. CVE-2023-32837 was a textbook OOB read/write in an array of structs. Various different members of the struct were accessed and modified, creating several different possibilities for exploitation, but also making them significantly more challenging. Interestingly, MediaTek partially fixed this bug in July 2021, although the exact date this patch went out to OEMs is unclear.
And that's the second point of danger. All the forks floating around make distributing patches in an efficient way all but impossible.
The fact that it's Google complaining here makes it all the more hilarious IMHO. Google are the ones who could fix this in an instant: demand upstreaming (or at least, reasonable efforts towards that) as a part of getting the Play Store certification.
A side note towards root exploit hunters: MediaTek's stuff is particularly gory. I'll admit my knowledge is some years dated, but I can't imagine that their code style and code quality has improved over the time...
> This one sentence just perfectly sums up everything that's broken in the embedded (i.e. everything non-x86) world. Everyone just forks random stuff at random points in the BSP's life time
A few years ago I did some work that involved building a custom Android image for a SoC manufacturer that's common in TVs.
The BSPs were provided over FTP as split up archive files, held together by bash scripts and had 100s of .patch files scattered all over the place. I am not sure if still the case, but there was also GPL-affected code (kernel patches/modules) that the were certainly not being open sourced at the time.
For each Android point update there was a new set of archives and painful rebasing of the changes we had made on top.
I know there have been changes since, with GSIs etc, but these to me just seem like band aids on the problem.
This one sentence just perfectly sums up everything that's broken in the embedded (i.e. everything non-x86) world. Everyone just forks random stuff at random points in the BSP's life time, and no one makes even the slightest effort to upstream it to mainline Linux (if that's possible at all given that Android's Linux fork itself does a lot of things differently than Linux upstream likes).
> I found two vulnerabilities in this driver. CVE-2023-32837 was a textbook OOB read/write in an array of structs. Various different members of the struct were accessed and modified, creating several different possibilities for exploitation, but also making them significantly more challenging. Interestingly, MediaTek partially fixed this bug in July 2021, although the exact date this patch went out to OEMs is unclear.
And that's the second point of danger. All the forks floating around make distributing patches in an efficient way all but impossible.
The fact that it's Google complaining here makes it all the more hilarious IMHO. Google are the ones who could fix this in an instant: demand upstreaming (or at least, reasonable efforts towards that) as a part of getting the Play Store certification.
A side note towards root exploit hunters: MediaTek's stuff is particularly gory. I'll admit my knowledge is some years dated, but I can't imagine that their code style and code quality has improved over the time...