Invalid read in oxide::CompositorOutputSurfaceGL::DiscardBuffer

Bug #1442398 reported by Chris Coulson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Fix Released
High
Chris Coulson
1.6
Fix Released
High
Chris Coulson

Bug Description

I'm seeing errors like this in valgrind:

==6299== Invalid read of size 4
==6299== at 0x825ACAD: gpu::gles2::GLES2Implementation::DeleteTexturesHelper(int, unsigned int const*) (gles2_implementation.cc:3371)
==6299== by 0x72B1349: oxide::CompositorOutputSurfaceGL::DiscardBuffer(oxide::CompositorOutputSurfaceGL::BufferData*) (oxide_compositor_output_surface_gl.cc:190)
==6299== by 0x72B13AF: oxide::CompositorOutputSurfaceGL::DiscardBackbuffer() [clone .part.14] (oxide_compositor_output_surface_gl.cc:92)
==6299== by 0x72B181F: DiscardBackbuffer (stl_construct.h:102)
==6299== by 0x72B181F: oxide::CompositorOutputSurfaceGL::~CompositorOutputSurfaceGL() (oxide_compositor_output_surface_gl.cc:205)
==6299== by 0x72B1838: oxide::CompositorOutputSurfaceGL::~CompositorOutputSurfaceGL() (oxide_compositor_output_surface_gl.cc:211)
==6299== by 0x7C2E002: operator() (scoped_ptr.h:128)
==6299== by 0x7C2E002: ~scoped_ptr_impl (scoped_ptr.h:222)
==6299== by 0x7C2E002: ~scoped_ptr (scoped_ptr.h:312)
==6299== by 0x7C2E002: cc::LayerTreeHostImpl::~LayerTreeHostImpl() (layer_tree_host_impl.cc:254)
==6299== by 0x7C2E258: cc::LayerTreeHostImpl::~LayerTreeHostImpl() (layer_tree_host_impl.cc:279)
==6299== by 0x7C4A811: operator() (scoped_ptr.h:128)
==6299== by 0x7C4A811: reset (scoped_ptr.h:248)
==6299== by 0x7C4A811: reset (scoped_ptr.h:377)
==6299== by 0x7C4A811: operator= (scoped_ptr.h:371)
==6299== by 0x7C4A811: cc::ThreadProxy::LayerTreeHostClosedOnImplThread(cc::CompletionEvent*) (thread_proxy.cc:1263)
==6299== by 0x72FFA88: Run (callback.h:396)
==6299== by 0x72FFA88: base::debug::TaskAnnotator::RunTask(char const*, char const*, base::PendingTask const&) (task_annotator.cc:63)
==6299== by 0x7321583: base::MessageLoop::RunTask(base::PendingTask const&) (message_loop.cc:445)
==6299== by 0x7321860: base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) (message_loop.cc:454)
==6299== by 0x7321D5A: base::MessageLoop::DoWork() (message_loop.cc:566)
==6299== by 0x73223B8: base::MessagePumpDefault::Run(base::MessagePump::Delegate*) (message_pump_default.cc:32)
==6299== by 0x73347D7: base::RunLoop::Run() (run_loop.cc:55)
==6299== by 0x731E594: base::MessageLoop::Run() (message_loop.cc:303)
==6299== by 0x734E4E4: Run (thread.cc:185)
==6299== by 0x734E4E4: base::Thread::ThreadMain() (thread.cc:239)
==6299== by 0x734ACFE: base::(anonymous namespace)::ThreadFunc(void*) (platform_thread_posix.cc:77)
==6299== by 0xBC400A4: start_thread (pthread_create.c:309)
==6299== by 0xB96DCFC: clone (clone.S:111)
==6299== Address 0x24da88a0 is 400 bytes inside a block of size 480 free'd
==6299== at 0x4C2C2E0: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6299== by 0x72B13E0: deallocate (new_allocator.h:110)
==6299== by 0x72B13E0: _M_deallocate_node (stl_deque.h:544)
==6299== by 0x72B13E0: _M_pop_front_aux (deque.tcc:528)
==6299== by 0x72B13E0: pop_front (stl_deque.h:1438)
==6299== by 0x72B13E0: pop (stl_queue.h:244)
==6299== by 0x72B13E0: oxide::CompositorOutputSurfaceGL::DiscardBackbuffer() [clone .part.14] (oxide_compositor_output_surface_gl.cc:91)
==6299== by 0x72B181F: DiscardBackbuffer (stl_construct.h:102)
==6299== by 0x72B181F: oxide::CompositorOutputSurfaceGL::~CompositorOutputSurfaceGL() (oxide_compositor_output_surface_gl.cc:205)
==6299== by 0x72B1838: oxide::CompositorOutputSurfaceGL::~CompositorOutputSurfaceGL() (oxide_compositor_output_surface_gl.cc:211)
==6299== by 0x7C2E002: operator() (scoped_ptr.h:128)
==6299== by 0x7C2E002: ~scoped_ptr_impl (scoped_ptr.h:222)
==6299== by 0x7C2E002: ~scoped_ptr (scoped_ptr.h:312)
==6299== by 0x7C2E002: cc::LayerTreeHostImpl::~LayerTreeHostImpl() (layer_tree_host_impl.cc:254)
==6299== by 0x7C2E258: cc::LayerTreeHostImpl::~LayerTreeHostImpl() (layer_tree_host_impl.cc:279)
==6299== by 0x7C4A811: operator() (scoped_ptr.h:128)
==6299== by 0x7C4A811: reset (scoped_ptr.h:248)
==6299== by 0x7C4A811: reset (scoped_ptr.h:377)
==6299== by 0x7C4A811: operator= (scoped_ptr.h:371)
==6299== by 0x7C4A811: cc::ThreadProxy::LayerTreeHostClosedOnImplThread(cc::CompletionEvent*) (thread_proxy.cc:1263)
==6299== by 0x72FFA88: Run (callback.h:396)
==6299== by 0x72FFA88: base::debug::TaskAnnotator::RunTask(char const*, char const*, base::PendingTask const&) (task_annotator.cc:63)
==6299== by 0x7321583: base::MessageLoop::RunTask(base::PendingTask const&) (message_loop.cc:445)
==6299== by 0x7321860: base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) (message_loop.cc:454)
==6299== by 0x7321D5A: base::MessageLoop::DoWork() (message_loop.cc:566)
==6299== by 0x73223B8: base::MessagePumpDefault::Run(base::MessagePump::Delegate*) (message_pump_default.cc:32)
==6299== by 0x73347D7: base::RunLoop::Run() (run_loop.cc:55)
==6299== by 0x731E594: base::MessageLoop::Run() (message_loop.cc:303)
==6299== by 0x734E4E4: Run (thread.cc:185)
==6299== by 0x734E4E4: base::Thread::ThreadMain() (thread.cc:239)
==6299== by 0x734ACFE: base::(anonymous namespace)::ThreadFunc(void*) (platform_thread_posix.cc:77)
==6299== by 0xBC400A4: start_thread (pthread_create.c:309)
==6299== by 0xB96DCFC: clone (clone.S:111)

This looks like fallout from http://bazaar.launchpad.net/~oxide-developers/oxide/oxide.trunk/revision/1017, which is only on trunk

Changed in oxide:
importance: Undecided → High
status: New → Triaged
assignee: nobody → Chris Coulson (chrisccoulson)
milestone: none → branch-1.7
status: Triaged → In Progress
Changed in oxide:
status: In Progress → Fix Released
information type: Public → Public Security
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

This actually isn't a regression - it looks like it's always been there

summary: - Out of bounds read in oxide::CompositorOutputSurfaceGL::DiscardBuffer
+ Invalid read in oxide::CompositorOutputSurfaceGL::DiscardBuffer
information type: Public Security → Public
Revision history for this message
Chris Coulson (chrisccoulson) wrote :

There isn't really a security impact from this - the data read isn't exposed anywhere and although it can occasionally result in a crash, this can't really be triggered from web content

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.