Chromium

Setting milestone because of s0/s1 severity.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security Impact hotlist or the Severity field, and remove the ReleaseBlock hotlist.

Setting Priority to P1 to match Severity s1. If this is incorrect, please reset the priority. The automation bot account won't make this change again.

Bumping the priority of this issue since it will affect an upcoming release.

Writing some thoughts before I can try and work through this tomorrow and reproduce it:

1. This is a DCHECK during serialization of a paint op buffer, so from a security POV, it would be limited to the browser process and not the privileged GPU process.
2. The specific DCHECK is DCHECK(use_paint_cache == UsePaintCache::kEnabled || !options_.paint_cache->Get(PaintCacheDataType::kPath, id));, which means use_paint_cache is disabled but the options_.paint_cache somehow has an entry for the path anyways. I'm not entirely sure the full implications, but I believe this just means we would inline the paint here regardless and the DCHECK is showing that we are wasting space in the cache.
3. I'm not sure how the options' paint cache gets an entry like that since the only stores into it are guarded by use_paint_cache being enabled, unless there are multiple write calls to the same path but the use_paint_cache parameter is changing between them. I need to explore that possibility more.

Looping in @wangxianzhu in case it's related to https://chromium-review.googlesource.com/c/chromium/src/+/5381519, which looks like it's the most recent code to touch that function.

https://chromium-review.googlesource.com/c/chromium/src/+/5381519 is unlikely to affect the use_paint_cache logic.

I'm boosting the severity on this for now, because according to #7 this is a DCHECK during serialization of a paint op buffer, allowing for a write in the browser process, reachable directly from web content would be Critical severity in terms of the security perspective.

still looking for someone who can triage best, but re:#1 in comment 7, we would expect security impact from both Browser and GPU processes (the latter due to its access to the Browser process)

UsePaintCache::kDisabled is used in BaseRenderingContext2D only. Can a path be used in two paint operations, one with cache enabled and one disabled?

I don't see any security impact of the DCHECK. It seems safe to remove the DCHECK?

I'm updating the OSes for visibility to the release team (once there is a fix); please update if I've incorrectly added a platform that is not affected

This is a critical security issue. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Severity field or update the Security Impact hotlist, and remove the ReleaseBlock label.

Can a path be used in two paint operations, one with cache enabled and one disabled?

https://developer.mozilla.org/en-US/docs/Web/API/Path2D

Path2D might make this possible. It looks fill() and stroke() use the value of features::kPath2DPaintCache whereas clip() uses UsePaintCache::kEnabled every time.

Looking at the testcase, it would be possible for a path to get cached using clip() but fail this check with fill() or stroke() on the same path. Perhaps swapping the logic for clip() would resolve things. I'll give it a try.

@junov would absolutely know the answer here.

My limited understanding of this code and what the DCHECK is checking for lines up with comment #12, where maybe we can just remove the DCHECK? Passing over to @junov as the identified expert.

This CL fixes the problem without removing the dcheck:

https://chromium-review.googlesource.com/c/chromium/src/+/5716900

updating this as fixed based on c#18 so the bots can do the needful going to let it get a bit of bake time before we merge to M127, the RC for which will need to be recut so this fix can be released, so we'll want to ensure there are no issues given that this will be fairly immediately released in Stable

I'm a little confused about what's happening in this bug so I'm going to reopen it for discussion.

The original clusterfuzz report is for a SkAssert in the gpu process:-

FilterResult FilterResult::insetByPixel() const {
    // This assumes that the image is pixel aligned with its layer bounds, which is validated in
    // the call to subset().
    auto insetBounds = fLayerBounds;
    insetBounds.inset(LayerSpace<SkISize>({1, 1}));
     // Shouldn't be calling this except in situations where padding was explicitly added before.
    SkASSERT(!insetBounds.isEmpty());
    return this->subset(fLayerBounds.topLeft(), insetBounds);
}

GPU Stacktrace:

   #0 0x599cfc36bb46 in ___interceptor_backtrace third_party/llvm/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc:4364:13
    #1 0x7fbda52897ec in base::debug::CollectStackTrace(void const**, unsigned long) base/debug/stack_trace_posix.cc:1044:7
    #2 0x7fbda51d351e in base::debug::StackTrace::StackTrace(unsigned long) base/debug/stack_trace.cc:242:20
    #3 0x7fbda51d33b5 in base::debug::StackTrace::StackTrace() base/debug/stack_trace.cc:237:28
    #4 0x7fbda4b23ddf in logging::LogMessage::Flush() base/logging.cc:739:29
    #5 0x7fbda4b23a11 in logging::LogMessage::~LogMessage() base/logging.cc:727:3
    #6 0x7fbd8b6ae3dd in SkAbort_FileLine(char const*, int, char const*, ...) skia/ext/google_logging.cc:42:3
    #7 0x7fbd8cb80682 in skif::FilterResult::insetByPixel() const::$_0::operator()() const third_party/skia/src/core/SkImageFilterTypes.cpp:656:5
    #8 0x7fbd8cb80517 in skif::FilterResult::insetByPixel() const third_party/skia/src/core/SkImageFilterTypes.cpp:656:5
    #9 0x7fbd8cb8015a in skif::FilterResult::insetForSaveLayer() const third_party/skia/src/core/SkImageFilterTypes.cpp:640:32
    #10 0x7fbd8ca5c989 in SkCanvas::internalDrawDeviceWithFilter(SkDevice*, SkDevice*, SkSpan<sk_sp<SkImageFilter>>, SkPaint const&, SkCanvas::DeviceCompatibleWithFilter, SkColorInfo const&, float, bool) third_party/skia/src/core/SkCanvas.cpp:821:33
    #11 0x7fbd8ca55afb in SkCanvas::internalRestore() third_party/skia/src/core/SkCanvas.cpp:1165:23
    #12 0x7fbd8ca57712 in SkCanvas::restore() third_party/skia/src/core/SkCanvas.cpp:472:19
    #13 0x7fbd886fdddd in cc::RestoreOp::Raster(cc::RestoreOp const*, SkCanvas*, cc::PlaybackParams const&) cc/paint/paint_op.cc:1742:11
    #14 0x7fbd8870e04f in cc::(anonymous namespace)::Rasterizer<cc::RestoreOp, false>::Raster(cc::RestoreOp const*, SkCanvas*, cc::PlaybackParams const&) cc/paint/paint_op.cc:195:5
    #15 0x7fbd8870dee9 in cc::(anonymous namespace)::$_46::operator()(cc::PaintOp const*, SkCanvas*, cc::PlaybackParams const&) const cc/paint/paint_op.cc:229:64
    #16 0x7fbd88709ee4 in cc::(anonymous namespace)::$_46::__invoke(cc::PaintOp const*, SkCanvas*, cc::PlaybackParams const&) cc/paint/paint_op.cc:229:64
    #17 0x7fbd8870104b in cc::PaintOp::Raster(SkCanvas*, cc::PlaybackParams const&) const cc/paint/paint_op.cc:2031:3
    #18 0x7fbd1b7c7012 in gpu::raster::RasterDecoderImpl::DoRasterCHROMIUM(unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) gpu/command_buffer/service/raster_decoder.cc:3086:22
    #19 0x7fbd1b7aed26 in gpu::raster::RasterDecoderImpl::HandleRasterCHROMIUM(unsigned int, void const volatile*) gpu/command_buffer/service/raster_decoder_autogen.h:154:3
    #20 0x7fbd1b7df3a0 in gpu::error::Error gpu::raster::RasterDecoderImpl::DoCommandsImpl<false>(unsigned int, void const volatile*, int, int*) gpu/command_buffer/service/raster_decoder.cc:1510:18
    #21 0x7fbd1b7b9bf1 in gpu::raster::RasterDecoderImpl::DoCommands(unsigned int, void const volatile*, int, int*) gpu/command_buffer/service/raster_decoder.cc:1571:12
    #22 0x7fbd86b8384a in gpu::CommandBufferService::Flush(int, gpu::AsyncAPIInterface*) gpu/command_buffer/service/command_buffer_service.cc:231:35
    #23 0x7fbd1a721d17 in gpu::CommandBufferStub::OnAsyncFlush(int, unsigned int, std::__Cr::vector<gpu::SyncToken, std::__Cr::allocator<gpu::SyncToken>> const&) gpu/ipc/service/command_buffer_stub.cc:506:22
    #24 0x7fbd1a720ea1 in gpu::CommandBufferStub::ExecuteDeferredRequest(gpu::mojom::DeferredCommandBufferRequestParams&) gpu/ipc/service/command_buffer_stub.cc:154:7
    #25 0x7fbd1a77b5d7 in gpu::GpuChannel::ExecuteDeferredRequest(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long) gpu/ipc/service/gpu_channel.cc:948:13
    #26 0x7fbd1a7972c4 in void base::internal::DecayedFunctorTraits<void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), base::WeakPtr<gpu::GpuChannel>&&, mojo::StructPtr<gpu::mojom::DeferredRequestParams>&&, unsigned long&&>::Invoke<void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), base::WeakPtr<gpu::GpuChannel> const&, mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long>(void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), base::WeakPtr<gpu::GpuChannel> const&, mojo::StructPtr<gpu::mojom::DeferredRequestParams>&&, unsigned long&&) base/functional/bind_internal.h:738:12
    #27 0x7fbd1a796ffb in void base::internal::InvokeHelper<true, base::internal::FunctorTraits<void (gpu::GpuChannel::*&&)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), base::WeakPtr<gpu::GpuChannel>&&, mojo::StructPtr<gpu::mojom::DeferredRequestParams>&&, unsigned long&&>, void, 0ul, 1ul, 2ul>::MakeItSo<void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), std::__Cr::tuple<base::WeakPtr<gpu::GpuChannel>, mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long>>(void (gpu::GpuChannel::*&&)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), std::__Cr::tuple<base::WeakPtr<gpu::GpuChannel>, mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long>&&) base/functional/bind_internal.h:954:5
    #28 0x7fbd1a796db7 in void base::internal::Invoker<base::internal::FunctorTraits<void (gpu::GpuChannel::*&&)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), base::WeakPtr<gpu::GpuChannel>&&, mojo::StructPtr<gpu::mojom::DeferredRequestParams>&&, unsigned long&&>, base::internal::BindState<true, true, false, void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), base::WeakPtr<gpu::GpuChannel>, mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long>, void ()>::RunImpl<void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), std::__Cr::tuple<base::WeakPtr<gpu::GpuChannel>, mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long>, 0ul, 1ul, 2ul>(void (gpu::GpuChannel::*&&)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), std::__Cr::tuple<base::WeakPtr<gpu::GpuChannel>, mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long>&&, std::__Cr::integer_sequence<unsigned long, 0ul, 1ul, 2ul>) base/functional/bind_internal.h:1067:14
    #29 0x7fbd1a796c09 in base::internal::Invoker<base::internal::FunctorTraits<void (gpu::GpuChannel::*&&)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), base::WeakPtr<gpu::GpuChannel>&&, mojo::StructPtr<gpu::mojom::DeferredRequestParams>&&, unsigned long&&>, base::internal::BindState<true, true, false, void (gpu::GpuChannel::*)(mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long), base::WeakPtr<gpu::GpuChannel>, mojo::StructPtr<gpu::mojom::DeferredRequestParams>, unsigned long>, void ()>::RunOnce(base::internal::BindStateBase*) base/functional/bind_internal.h:980:12
    #30 0x7fbd86bbee13 in base::OnceCallback<void ()>::Run() && base/functional/callback.h:156:12
    #31 0x7fbd86c071b6 in gpu::SchedulerDfs::ExecuteSequence(base::IdType<gpu::SyncPointOrderData, unsigned int, 0u, 1u>) gpu/command_buffer/service/scheduler_dfs.cc:600:24
    #32 0x7fbd86c0434d in gpu::SchedulerDfs::RunNextTask() gpu/command_buffer/service/scheduler_dfs.cc:524:3
    #33 0x7fbd86c11eeb in void base::internal::DecayedFunctorTraits<void (gpu::SchedulerDfs::*)(), gpu::SchedulerDfs*>::Invoke<void (gpu::SchedulerDfs::*)(), gpu::SchedulerDfs*>(void (gpu::SchedulerDfs::*)(), gpu::SchedulerDfs*&&) base/functional/bind_internal.h:738:12
    #34 0x7fbd86c11dad in void base::internal::InvokeHelper<false, base::internal::FunctorTraits<void (gpu::SchedulerDfs::*&&)(), gpu::SchedulerDfs*>, void, 0ul>::MakeItSo<void (gpu::SchedulerDfs::*)(), std::__Cr::tuple<base::internal::UnretainedWrapper<gpu::SchedulerDfs, base::unretained_traits::MayNotDangle, (partition_alloc::internal::RawPtrTraits)0>>>(void (gpu::SchedulerDfs::*&&)(), std::__Cr::tuple<base::internal::UnretainedWrapper<gpu::SchedulerDfs, base::unretained_traits::MayNotDangle, (partition_alloc::internal::RawPtrTraits)0>>&&) base/functional/bind_internal.h:930:12
    #35 0x7fbd86c11b52 in void base::internal::Invoker<base::internal::FunctorTraits<void (gpu::SchedulerDfs::*&&)(), gpu::SchedulerDfs*>, base::internal::BindState<true, true, false, void (gpu::SchedulerDfs::*)(), base::internal::UnretainedWrapper<gpu::SchedulerDfs, base::unretained_traits::MayNotDangle, (partition_alloc::internal::RawPtrTraits)0>>, void ()>::RunImpl<void (gpu::SchedulerDfs::*)(), std::__Cr::tuple<base::internal::UnretainedWrapper<gpu::SchedulerDfs, base::unretained_traits::MayNotDangle, (partition_alloc::internal::RawPtrTraits)0>>, 0ul>(void (gpu::SchedulerDfs::*&&)(), std::__Cr::tuple<base::internal::UnretainedWrapper<gpu::SchedulerDfs, base::unretained_traits::MayNotDangle, (partition_alloc::internal::RawPtrTraits)0>>&&, std::__Cr::integer_sequence<unsigned long, 0ul>) base/functional/bind_internal.h:1067:14
    #36 0x7fbd86c119e9 in base::internal::Invoker<base::internal::FunctorTraits<void (gpu::SchedulerDfs::*&&)(), gpu::SchedulerDfs*>, base::internal::BindState<true, true, false, void (gpu::SchedulerDfs::*)(), base::internal::UnretainedWrapper<gpu::SchedulerDfs, base::unretained_traits::MayNotDangle, (partition_alloc::internal::RawPtrTraits)0>>, void ()>::RunOnce(base::internal::BindStateBase*) base/functional/bind_internal.h:980:12
    #37 0x7fbda4a3af93 in base::OnceCallback<void ()>::Run() && base/functional/callback.h:156:12
    #38 0x7fbda4e8f1c2 in base::TaskAnnotator::RunTaskImpl(base::PendingTask&) base/task/common/task_annotator.cc:203:34
    #39 0x7fbda4f903a8 in void base::TaskAnnotator::RunTask<base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::LazyNow*)::$_3>(perfetto::StaticString, base::PendingTask&, base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::LazyNow*)::$_3&&) base/task/common/task_annotator.h:90:5
    #40 0x7fbda4f8f537 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::LazyNow*) base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:484:23
    #41 0x7fbda4f8e1d6 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:346:40
    #42 0x7fbda4f8fa73 in non-virtual thunk to base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWork() base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:0
    #43 0x7fbda5322e7e in base::MessagePumpGlib::HandleDispatch() base/message_loop/message_pump_glib.cc:649:46
    #44 0x7fbda5324e69 in base::(anonymous namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) base/message_loop/message_pump_glib.cc:274:43
    #45 0x7fbcd954817d in g_main_context_dispatch
    #46 0x7fbcd9548400 in libglib-2.0.so.0.6400.6
    #47 0x7fbcd95484a3 in g_main_context_iteration
    #48 0x7fbda53231c8 in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) base/message_loop/message_pump_glib.cc:683:30
    #49 0x7fbda4f915a3 in base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool, base::TimeDelta) base/task/sequence_manager/thread_controller_with_message_pump_impl.cc:654:12
    #50 0x7fbda4d616c2 in base::RunLoop::Run(base::Location const&) base/run_loop.cc:134:14
    #51 0x7fbd95b1974c in content::GpuMain(content::MainFunctionParams) content/gpu/gpu_main.cc:431:14
    #52 0x7fbd9f9693ea in content::RunZygote(content::ContentMainDelegate*) content/app/content_main_runner_impl.cc:703:14
    #53 0x7fbd9f96a678 in content::RunOtherNamedProcessTypeMain(std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char>> const&, content::MainFunctionParams, content::ContentMainDelegate*) content/app/content_main_runner_impl.cc:807:12
    #54 0x7fbd9f96d24d in content::ContentMainRunnerImpl::Run() content/app/content_main_runner_impl.cc:1175:10
    #55 0x7fbd9f965245 in content::RunContentProcess(content::ContentMainParams, content::ContentMainRunner*) content/app/content_main.cc:333:36
    #56 0x7fbd9f9660f6 in content::ContentMain(content::ContentMainParams) content/app/content_main.cc:346:10
    #57 0x599cfc405c81 in ChromeMain chrome/app/chrome_main.cc:222:12
    #58 0x599cfc4056e2 in main chrome/app/chrome_exe_main_aura.cc:17:10
    #59 0x7fbcc9469083 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/libc-start.c:308:16
    #60 0x599cfc32549a in _start

Along with the GPU SkAssert, there is a renderer DCHECK which is fixed by the patch in comment #20.

void PaintOpWriter::Write(const SkPath& path, UsePaintCache use_paint_cache) {
  auto id = path.getGenerationID();
  if (!options_.for_identifiability_study) {
    Write(id);
  }

  DCHECK(use_paint_cache == UsePaintCache::kEnabled ||
         !options_.paint_cache->Get(PaintCacheDataType::kPath, id));
  if (use_paint_cache == UsePaintCache::kEnabled &&
      options_.paint_cache->Get(PaintCacheDataType::kPath, id)) {
    Write(static_cast<uint32_t>(PaintCacheEntryState::kCached));
    return;
  }

...
    #10 0x7daa9ac521d9 in logging::CheckError::~CheckError() base/check.cc:350:16
    #11 0x7daa7e9bf4bb in cc::PaintOpWriter::Write(SkPath const&, cc::UsePaintCache) cc/paint/paint_op_writer.cc:228:3
    #12 0x7daa7e8f12e4 in cc::DrawPathOp::Serialize(cc::PaintOpWriter&, cc::PaintFlags const*, SkM44 const&, SkM44 const&) const cc/paint/paint_op.cc:557:10
...
    #42 0x7daa9af616c2 in base::RunLoop::Run(base::Location const&) base/run_loop.cc:134:14
    #43 0x7daa95279b56 in content::RendererMain(content::MainFunctionParams) content/renderer/renderer_main.cc:359:16
...
    #49 0x5bd2ba452c81 in ChromeMain chrome/app/chrome_main.cc:222:12

Given that a renderer fix cannot solve a GPU problem - is the GPU problem still there?

I see some crashes in Canary in the asserting function - I'm not familliar with SkASSERT - is it enabled on non-Canary channels or is the SkAssert in insetByPixel something that also needs fixing?

https://crash.corp.google.com/browse?q=product_name%3D%27Chrome%27+AND+EXISTS+%28SELECT+1+FROM+UNNEST%28CrashedStackTrace.StackFrame%29+WHERE+Regexp_Contains%28FunctionName%2C%27FilterResult%3A%3AinsetByPixel%27%29%29&stbtiq=&reportid=219e806b3ae20e74&index=0#4

Ah, I missed the SkASSERT happening in Gpu main. That is a separate issue that needs to be fixed. SkASSERT is roughly equivalent to DCHECK but is defined in the skia repo; it is a no-op in non-debug builds.

The assert was a pre-condition guardrail to make sure the inputs were set up correctly to be inset. However, in the event that they weren't, and the result is an empty subset (the assert tripping), the remaining code in FilterResult::subset() will correctly detect this and just return an empty image. In all likelihood this is the right visual behavior, but should have just been caught earlier in the Skia stack. For a release build that skips the assert, this will be defined behavior that shouldn't lead to any discernible rendering issues or security issues. I wouldn't consider this aspect of the fuzz report to be a stable release blocker.

So, the CL in comment #18 should probably still be merged to m127, but I don't think my follow-up fixes for the SkASSERT will need to be (but am also happy to do so).

Thanks Michael - if we're confident the SkAssert is not dangerous then perhaps this bug can be marked fixed and a sub-issue can be opened for the skassert. If no dangerous behavior can happen in the gpu then this issue can be High severity.

I'm going to go ahead and close this as fixed, since we'll need to backmerge the fix asap (it should get a bit more bake time before we consider that). Please open a new issue for the SkAssert issue.

Filed b/353980389 to track fixing the SkASSERT

Requesting merge to stable (M127) because latest trunk commit (1329058) appears to be after stable branch point (1313161). Merge review required: M127 has already been cut for stable release.

Thank you for fixing this security bug! We aim to ship security fixes as quickly as possible, to limit their opportunity for exploitation as an "n-day" (that is, a bug where git fixes are developed into attacks before those fixes reach users).

We have determined this fix is necessary on milestone(s): [127].

Please answer the following questions so that we can safely process this merge request:

1. Which CLs should be backmerged? (Please include Gerrit links.)
2. Has this fix been verified on Canary to not pose any stability regressions?
3. Does this fix pose any potential non-verifiable stability risks?
4. Does this fix pose any known compatibility risks?
5. Does it require manual verification by the test team? If so, please describe required testing.

reviewing canary data there appear to be no issues related to this fix 127 merge approved for https://crrev.com/c/5716900 -- please merge this fix to branch 6533 at soonest so this fix can be included in the M127 Stable RC recut

LTS Milestone M126

This issue has been flagged as a merge candidate for Chrome OS' LTS channel. If selected, our merge team will handle any additional merges. To help us determine if this issue requires a merge to LTS, please answer this short questionnaire:

1. Was this issue a regression for the milestone it was found in?
2. Is this issue related to a change or feature merged after the latest LTS Milestone?

Thank you for your past fuzzer contributions that resulted in this report. Upon through assessment of the evaluation and outcome, this appears to be a conflict of safe DCHECKs and not an exploitable security issue. As such, this report is unfortunately not eligible for a Chrome VRP reward.

How would you like to be credited for this report?

No credit needed.

This issue requires additional review before it can be merged to the LTS channel. Please answer the following questions to help us evaluate this merge:

1. Number of CLs needed for this fix and links to them.
2. Level of complexity (High, Medium, Low - Explain)
3. Has this been merged to a stable release? beta release?
4. Overall Recommendation (Yes, No)

1. Just https://crrev.com/c/5734492
2. Low, no conflicts
3. 127
4. Yes

@gm...@google.com yes, I will make the merge request.

This issue requires additional review before it can be merged to the LTS channel. Please answer the following questions to help us evaluate this merge:

1. Number of CLs needed for this fix and links to them.
2. Level of complexity (High, Medium, Low - Explain)
3. Has this been merged to a stable release? beta release?
4. Overall Recommendation (Yes, No)

1. https://crrev.com/c/5834804
2. Low, no conflicts
3. 127
4. Yes

This bug has been closed for more than 14 weeks. Removing issue access restrictions.