New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Fixed
please use my address
Closed: Aug 28
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 1
Type: Bug-Security

Sign in to add a comment

Issue 877182: Security: Mojo DataPipe*Dispatcher deserialization lacking validation

Reported by, Aug 23 Project Member

Issue description

This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different

Please READ THIS FAQ before filing a bug:

Please see the following link for instructions on filing security bugs:

NOTE: Security bugs are normally made public once a fix has been widely

There's missing validation in the deserialisation routines for both 
DataPipeConsumerDispatcher and DataPipeProducerDispatcher, which take from 
the incoming message a read_offset/write_offset respectively into shared memory.

Providing an offset outside the bounds of the allocated memory will then result
in an OOB read/write when the pipe is used.

// static
DataPipeProducerDispatcher::Deserialize(const void* data,
                                        size_t num_bytes,
                                        const ports::PortName* ports,
                                        size_t num_ports,
                                        ScopedInternalPlatformHandle* handles,
                                        size_t num_handles) {
  if (num_ports != 1 || num_handles != 1 ||
      num_bytes != sizeof(SerializedState)) {
    return nullptr;

  const SerializedState* state = static_cast<const SerializedState*>(data);
  if (!state->options.capacity_num_bytes || !state->options.element_num_bytes ||
      state->options.capacity_num_bytes < state->options.element_num_bytes) {
    return nullptr;

  NodeController* node_controller = Core::Get()->GetNodeController();
  ports::PortRef port;
  if (node_controller->node()->GetPort(ports[0], &port) != ports::OK)
    return nullptr;

  ScopedInternalPlatformHandle buffer_handle;
  std::swap(buffer_handle, handles[0]);
  auto region_handle =
          std::move(buffer_handle), ScopedInternalPlatformHandle());
  auto region = base::subtle::PlatformSharedMemoryRegion::Take(
  auto ring_buffer =
  if (!ring_buffer.IsValid()) {
    DLOG(ERROR) << "Failed to deserialize shared buffer handle.";
    return nullptr;

  scoped_refptr<DataPipeProducerDispatcher> dispatcher =
      new DataPipeProducerDispatcher(node_controller, port,
                                     std::move(ring_buffer), state->options,

    base::AutoLock lock(dispatcher->lock_);
    // BUG: state->write_offset is not trustworthy!
    dispatcher->write_offset_ = state->write_offset;
    dispatcher->available_capacity_ = state->available_capacity;
    dispatcher->peer_closed_ = state->flags & kFlagPeerClosed;
    if (!dispatcher->InitializeNoLock())
      return nullptr;

  return dispatcher;

See the following code for the site of the OOB write

MojoResult DataPipeProducerDispatcher::WriteData(
    const void* elements,
    uint32_t* num_bytes,
    const MojoWriteDataOptions& options) {
  base::AutoLock lock(lock_);
  if (!shared_ring_buffer_.IsValid() || in_transit_)

  if (in_two_phase_write_)
    return MOJO_RESULT_BUSY;

  if (peer_closed_)

  if (*num_bytes % options_.element_num_bytes != 0)
  if (*num_bytes == 0)
    return MOJO_RESULT_OK;  // Nothing to do.

  if ((options.flags & MOJO_WRITE_DATA_FLAG_ALL_OR_NONE) &&
      (*num_bytes > available_capacity_)) {
    // Don't return "should wait" since you can't wait for a specified amount of
    // data.

  DCHECK_LE(available_capacity_, options_.capacity_num_bytes);
  uint32_t num_bytes_to_write = std::min(*num_bytes, available_capacity_);
  if (num_bytes_to_write == 0)

  *num_bytes = num_bytes_to_write;

  uint8_t* data = static_cast<uint8_t*>(ring_buffer_mapping_.memory());

  const uint8_t* source = static_cast<const uint8_t*>(elements);

  DCHECK_LE(write_offset_, options_.capacity_num_bytes);
  uint32_t tail_bytes_to_write =
      std::min(options_.capacity_num_bytes - write_offset_, num_bytes_to_write);
  uint32_t head_bytes_to_write = num_bytes_to_write - tail_bytes_to_write;

  DCHECK_GT(tail_bytes_to_write, 0u);
  // BUG: OOB write here
  memcpy(data + write_offset_, source, tail_bytes_to_write);
  if (head_bytes_to_write > 0)
    memcpy(data, source + tail_bytes_to_write, head_bytes_to_write);

  DCHECK_LE(num_bytes_to_write, available_capacity_);
  available_capacity_ -= num_bytes_to_write;
  write_offset_ =
      (write_offset_ + num_bytes_to_write) % options_.capacity_num_bytes;


  base::AutoUnlock unlock(lock_);

  return MOJO_RESULT_OK;

Mojo is kind of complicated, so I haven't figured out yet whether you can reach
this OOB write in the browser process from a renderer, but you can reach the 
corresponding OOB read in DataPipeConsumerDispatcher.

If you apply the patch and then build chrome, you should be able to trigger a 
browser process crash (with a malformed message from the renderer) by visiting and interacting
with the live demo.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.

Chrome Version: stable
Operating System: [Please indicate OS, version, and service pack level]

Please include a demonstration of the security bug, such as an attached
HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE
make the file as small as possible and remove any content not required to
demonstrate the bug.

Type of crash: browser
Crash State:

Received signal 11 SEGV_ACCERR 7f3a365a2000
    #0 0x55efba71bc31 in __interceptor_backtrace /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/asan/../sanitizer_common/
    #1 0x55efc1b42f9c in base::debug::StackTrace::StackTrace(unsigned long) /ssd/chrome/src/out/asan/../../base/debug/
    #2 0x55efc1b41f1d in PrintBacktraceOutputHandler /ssd/chrome/src/out/asan/../../base/debug/
    #3 0x55efc1b41f1d in Print /ssd/chrome/src/out/asan/../../base/debug/
    #4 0x55efc1b41f1d in base::debug::(anonymous namespace)::StackDumpSignalHandler(int, siginfo_t*, void*) /ssd/chrome/src/out/asan/../../base/debug/
    #5 0x7f3a4d8ae0c0 in __funlockfile ??:?
    #6 0x7f3a4d8ae0c0 in ?? ??:0
    #7 0x7f3a46b5c01e in memcpy /tmp/build-debs.Lfl5zt/glibc-2.24/string/../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:360
    #8 0x7f3a46b5c01e in ?? ??:0
    #9 0x55efba7753b0 in __asan_memcpy _asan_rtl_:3
    #10 0x55efbc4b9911 in mojo::edk::DataPipeConsumerDispatcher::ReadData(MojoReadDataOptions const&, void*, unsigned int*) /ssd/chrome/src/out/asan/../../mojo/edk/system/
    #11 0x55efbc4aeb51 in mojo::edk::Core::ReadData(unsigned int, MojoReadDataOptions const*, void*, unsigned int*) /ssd/chrome/src/out/asan/../../mojo/edk/system/
    #12 0x55efbd9ab9e6 in content::ServiceWorkerDataPipeReader::OnHandleGotSignal(unsigned int) /ssd/chrome/src/out/asan/../../content/browser/service_worker/
    #13 0x55efc2e498f3 in get /ssd/chrome/src/out/asan/../../base/memory/weak_ptr.h:243:12
    #14 0x55efc2e498f3 in operator bool /ssd/chrome/src/out/asan/../../base/memory/weak_ptr.h:256:0
    #15 0x55efc2e498f3 in mojo::SimpleWatcher::OnHandleReady(int, unsigned int, mojo::HandleSignalsState const&) /ssd/chrome/src/out/asan/../../mojo/public/cpp/system/
    #16 0x55efc2e4a1d8 in HandleSignalsState /ssd/chrome/src/out/asan/../../mojo/public/cpp/system/handle_signals_state.h:23:23
    #17 0x55efc2e4a1d8 in mojo::SimpleWatcher::Context::Notify(unsigned int, MojoHandleSignalsState, unsigned int) /ssd/chrome/src/out/asan/../../mojo/public/cpp/system/
    #18 0x55efc2e47a8b in mojo::SimpleWatcher::Context::CallNotify(MojoTrapEvent const*) /ssd/chrome/src/out/asan/../../mojo/public/cpp/system/
    #19 0x55efbc4ffd11 in mojo::edk::WatcherDispatcher::InvokeWatchCallback(unsigned long, unsigned int, mojo::edk::HandleSignalsState const&, unsigned int) /ssd/chrome/src/out/asan/../../mojo/edk/system/
    #20 0x55efbc4feb03 in Unlock /ssd/chrome/src/out/asan/../../base/synchronization/lock_impl.h:70:12
    #21 0x55efbc4feb03 in Release /ssd/chrome/src/out/asan/../../base/synchronization/lock.h:27:0
    #22 0x55efbc4feb03 in ~AutoLock /ssd/chrome/src/out/asan/../../base/synchronization/lock.h:122:0
    #23 0x55efbc4feb03 in mojo::edk::Watch::InvokeCallback(unsigned int, mojo::edk::HandleSignalsState const&, unsigned int) /ssd/chrome/src/out/asan/../../mojo/edk/system/
    #24 0x55efbc4f2627 in mojo::edk::RequestContext::~RequestContext() /ssd/chrome/src/out/asan/../../mojo/edk/system/
    #25 0x55efbc4d39ab in mojo::edk::NodeChannel::OnChannelMessage(void const*, unsigned long, std::__1::vector<mojo::edk::ScopedInternalPlatformHandle, std::__1::allocator<mojo::edk::ScopedInternalPlatformHandle> >) /ssd/chrome/src/out/asan/../../mojo/edk/system/
    #26 0x55efbc4a2859 in mojo::edk::Channel::OnReadComplete(unsigned long, unsigned long*) /ssd/chrome/src/out/asan/../../mojo/edk/system/
    #27 0x55efbc5135bc in mojo::edk::(anonymous namespace)::ChannelPosix::OnFileCanReadWithoutBlocking(int) /ssd/chrome/src/out/asan/../../mojo/edk/system/
    #28 0x55efc1b789b0 in base::MessagePumpLibevent::OnLibeventNotification(int, short, void*) /ssd/chrome/src/out/asan/../../base/message_loop/
    #29 0x55efc1b917b9 in event_process_active /ssd/chrome/src/out/asan/../../base/third_party/libevent/event.c:382:14
    #30 0x55efc1b917b9 in event_base_loop /ssd/chrome/src/out/asan/../../base/third_party/libevent/event.c:521:0
    #31 0x55efc1b79192 in base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) /ssd/chrome/src/out/asan/../../base/message_loop/
    #32 0x55efc1a2ba52 in base::RunLoop::Run() /ssd/chrome/src/out/asan/../../base/
    #33 0x55efbce15dbe in content::BrowserProcessSubThread::IOThreadRun(base::RunLoop*) /ssd/chrome/src/out/asan/../../content/browser/
    #34 0x55efc1ab1a45 in base::Thread::ThreadMain() /ssd/chrome/src/out/asan/../../base/threading/
    #35 0x55efc1b70f65 in CurrentId /ssd/chrome/src/out/asan/../../base/threading/
    #36 0x55efc1b70f65 in base::(anonymous namespace)::ThreadFunc(void*) /ssd/chrome/src/out/asan/../../base/threading/
    #37 0x7f3a4d8a4494 in start_thread ??:0:0
    #38 0x7f3a46bc0a8f in clone ??:0:0
  r8: 000000000000000a  r9: fffff018415e5c03 r10: 00000fe7bea1a453 r11: 0000000000000008
 r12: 0000000000000000 r13: 000000000000029c r14: 00007f3a365a2000 r15: 00007f39f5112000
  di: 00007f39f5112000  si: 00007f3a365a2000  bp: 00007f3a37dffd30  bx: 000055efd331e248
  dx: 000000000000029c  ax: 00007f39f5112000  cx: 0000000000000000  sp: 00007f3a37dff4d8
  ip: 00007f3a46b5c01e efl: 0000000000010287 cgf: 002b000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 00007f3a365a2000
1.4 KB Download

Comment 1 by, Aug 23

Status: Assigned (was: Unconfirmed)

Comment 2 by, Aug 23

Components: Internals>Mojo
Labels: Security_Impact-Stable OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows

Comment 3 by, Aug 24

Labels: Security_Severity-Medium

Comment 4 by, Aug 25

Labels: M-68

Comment 5 by, Aug 25

Project Member
Labels: Pri-1

Comment 6 by, Aug 27

I have a browser process write from the renderer now. To reproduce, apply the attached patch, and then in the first tab run the attached javascript, and this should probably crash. Since it's just writing directly after the mapped shared memory, the crash is not deterministic, but I've attached the ASAN log from running locally under gdb, which makes it more observable for me.
1.2 KB Download
331 bytes View Download
7.4 KB View Download

Comment 7 by, Aug 28

IIRC (and AFAICT looking at the code), the assumption has always been that we would fail to map the memory if the communicated size were larger than the actual buffer object. Thus we should hit this failure mode[1] and ultimately reject the handle on deserialization.

That appears to be an incorrect assumption now, so InitializeNoLock() should also validate the mapped size vs the specified size too. Will make that change.


Comment 8 by, Aug 28

Err, misread. Still, straightforward fix to ensure that write_offset + available_capacity does not exceed the mapped size during deserialization.

Comment 9 by, Aug 28

Comment 10 by, Aug 28

I think this bug should probably be Severity-High?

I don't think that your fix is sufficient to prevent a malicious renderer from exhausting browser process VA space - I was testing this yesterday and the renderer can also simply request some 1gig mappings and cause the browser process to crash.

I think that's harder to fix (since AFAICT at least this code doesn't have any way to determine the true size of the shared memory region being mapped), and might be worth filing a separate lower severity issue for?

Comment 11 by, Aug 28

Project Member
The following revision refers to this bug:

commit 66e24a8793615bd9d5c238b1745b093090e1f72d
Author: Ken Rockot <>
Date: Tue Aug 28 15:10:08 2018

[mojo-core] Validate data pipe endpoint metadata

Ensures that we don't blindly trust specified buffer size and offset
metadata when deserializing data pipe consumer and producer handles.

Bug:  877182 
Change-Id: I30f3eceafb5cee06284c2714d08357ef911d6fd9
Reviewed-by: Reilly Grant <>
Commit-Queue: Ken Rockot <>
Cr-Commit-Position: refs/heads/master@{#586704}

Comment 12 by, Aug 28

Status: Fixed (was: Assigned)

Comment 13 by, Aug 29

Labels: Merge-Request-69

Comment 14 by, Aug 29

Project Member
Labels: -Merge-Request-69 Merge-Review-69 Hotlist-Merge-Review
This bug requires manual review: We are only 5 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit - Your friendly Sheriffbot

Comment 15 by, Aug 29


Comment 16 by, Aug 29

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 17 by, Aug 29

+inferno@ & mbarbella@ for M69 Merge review as awhalley@ is OOO. Pls note CL listed at #11 didn't make it to canary yet.

Comment 18 by, Aug 29

rockot@, pls merge the change listed at #11 to canary branch 3535 so we can trigger new canary from same branch. Thank you.

Comment 19 by, Aug 29

I'm trying to merge now to canary branch.

Comment 20 by, Aug 29

Project Member
Labels: merge-merged-3535
The following revision refers to this bug:

commit 0004aafc512d1033c44401200f7cf94dc2dee209
Author: Ken Rockot <>
Date: Wed Aug 29 16:05:06 2018

[mojo-core] Validate data pipe endpoint metadata

Ensures that we don't blindly trust specified buffer size and offset
metadata when deserializing data pipe consumer and producer handles.

Bug:  877182 
Change-Id: I30f3eceafb5cee06284c2714d08357ef911d6fd9
Reviewed-by: Reilly Grant <>
Commit-Queue: Ken Rockot <>
Cr-Original-Commit-Position: refs/heads/master@{#586704}(cherry picked from commit 66e24a8793615bd9d5c238b1745b093090e1f72d)
Reviewed-by: Krishna Govind <>
Cr-Commit-Position: refs/branch-heads/3535@{#7}
Cr-Branched-From: 4d18295073a6bf8f2f4d26e4e059767e091eaaf3-refs/heads/master@{#586474}

Comment 21 by, Aug 29

Triggered new canary 70.0.3535.5 with merge listed at #20. Pls verify this change on 70.0.3535.5 or higher.

Comment 22 by, Aug 30

Labels: -Merge-Review-69 Merge-Approved-69
Approving merge to M69 branch 3497 per internal mail thread. Pls merge ASAP. Thank you.

Comment 23 by, Aug 30

Project Member
Labels: -merge-approved-69 merge-merged-3497
The following revision refers to this bug:

commit 6502ac5eb169f3356f777b65470f9cfdd534173d
Author: Ken Rockot <>
Date: Thu Aug 30 14:39:11 2018

[mojo-core] Validate data pipe endpoint metadata

Ensures that we don't blindly trust specified buffer size and offset
metadata when deserializing data pipe consumer and producer handles.

(cherry picked from commit 66e24a8793615bd9d5c238b1745b093090e1f72d)

Bug:  877182 
Change-Id: I30f3eceafb5cee06284c2714d08357ef911d6fd9
Reviewed-by: Reilly Grant <>
Commit-Queue: Ken Rockot <>
Cr-Original-Commit-Position: refs/heads/master@{#586704}
Reviewed-by: Ken Rockot <>
Cr-Commit-Position: refs/branch-heads/3497@{#847}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}

Comment 24 by, Sep 4

Labels: Release-0-M69

Comment 25 by, Sep 4

Labels: -Security_Severity-Medium Security_Severity-High

Comment 26 by, Sep 4

Labels: CVE-2018-16068 CVE_description-missing

Comment 27 by, Dec 5

Project Member
Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 28 by, Jan 4

Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment