03:54 <@solar> dsd_: think there is an overflow in the proc handler of that vesa-tng code you just posted.. A long OEM string looks like it could make that code go poof. 03:55 <@dsd_> solar: i doubt that is new 03:55 <@dsd_> please file a bug for it though, and assign to spock 03:55 <@solar> it's not new. 03:55 <@solar> I can't file bugs.. (bugzilla passwd out of reach till monday) 03:58 <@solar> dsd_: actually all of the sprintf() dont look so hot. granted it's probably hard to trigger as it would require a messed up driver to be loaded. 03:59 <@solar> but then I can't say it for sure.. imo it should get a proper audit.
The problem should be fixed in the latest vesafb-tng patch: http://dev.gentoo.org/~spock/projects/vesafb-tng/archive/vesafb-tng-1.0-rc2-2.6.20-rc2.patch I'm not a security expert, but as far as I can see, security-wise this is a non-issue. The data that is printed into the buffer comes from the Video BIOS, so in order to affect it and exploit the overflow in any way one would need to overwrite the BIOS image in RAM. This of course can be done, but requires root privileges. The only situation in which this could turn into a real problem would thus be a broken or weird BIOS that reports a lot data. To the best of my knowledge, no such BIOS exists :)
Ah, I forgot to add it in the previous comment.. Thanks for pointing out this issue.
thanks
