From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel J Blueman Date: Fri, 06 May 2011 02:38:58 +0000 Subject: Re: [2.6.39-rc2, framebuffer] use after free oops Message-Id: List-Id: References: <20110420080535.3edd11ac@pluto.restena.lu> <20110420105631.70695dfa@lxorguk.ukuu.org.uk> In-Reply-To: <20110420105631.70695dfa@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Alan Cox , =?ISO-8859-1?Q?Bruno_Pr=E9mont?= , Paul Mundt , linux-fbdev@vger.kernel.org, Linux Kernel On 20 April 2011 17:56, Alan Cox wrote: > On Wed, 20 Apr 2011 08:05:35 +0200 > Bruno Pr=E9mont wrote: > >> On Wed, 20 Apr 2011 13:50:10 Daniel J Blueman = wrote: >> > Any ideas on how best to address this issue [0], since it causes >> > silent corruption, or at best crashes? >> >> There is probably no easy short-term fix to this... > > The short term fix would be to deliberately leak the buffer. That should > go into 2.6.39-rc right now with a comment explaining the situation. > Otherwise who knows what corruption may occur to user data if unlucky. > > The other 'cheat' might be to tweak the API so the removal API isn't a > 'destroy' interface but a 'shut down' and has a matching 'restart' one > for when the intelfb unloads at which point vga16fb can carry on with the > original fb_info 8) It looks like Andy Whitcroft addressed this issue some time ago, but forgot to send the fix upstream: http://kernel.ubuntu.com/git?p=3Dubuntu/ubuntu-natty.git;a=3Dpatch;h=C5a742= b5f78e161d6a13853a7e3e6e1dfa429e69;hp&a1443f67eea17d4b78ef75df701782cc8bf35b Let's hope it can hit -rc7 since it's been in Ubuntu's kernel tree for considerable time, and fixes a silent corrupter: http://groups.google.com/group/linux.kernel/browse_thread/thread/fc9083f6f3= 80ed5b/f801112b840785cb?show_docid=F801112b840785cb Thanks, Daniel --=20 Daniel J Blueman