wangxianzhu@, would you mind taking a look?

You touched that code some time ago: https://chromium.googlesource.com/chromium/src/+/934f67a68da2054e526e13648c5452e2cf79c211

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

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Haven't found any culprit. All variables accessed by the code seem properly initialized.

Also couldn't reproduce locally with a msan build.

In this case, even if there is any uinitialized value, the value is just used for layout, not used to generate any address for data or code, so it should be free of any security problem.

Based on static code analysis, the use-of-unitialized-value seems a false-positive.

In AffineTransform.cpp:

void AffineTransform::map(double x, double y, double& x2, double& y2) const
{
    x2 = (m_transform[0] * x + m_transform[2] * y + m_transform[4]);
    y2 = (m_transform[1] * x + m_transform[3] * y + m_transform[5]);
}

FloatPoint AffineTransform::mapPoint(const FloatPoint& point) const
{
    double x2, y2;
    map(point.x(), point.y(), x2, y2);  // map() initializes x2 and y2.

    return FloatPoint(narrowPrecisionToFloat(x2), narrowPrecisionToFloat(y2));
}

In FloatConversion.h:

template<>
inline float narrowPrecisionToFloat(double number)
{
    return clampTo<float>(number);
}

In MathExtras.h:

template<typename LimitType, typename ValueType> inline LimitType clampTo(ValueType value, LimitType min = defaultMinimumForClamp<LimitType>(), LimitType max = defaultMaximumForClamp<LimitType>())
{
    ASSERT(!std::isnan(static_cast<double>(value)));
    ASSERT(min <= max); // This also ensures |min| and |max| aren't NaN.
    return ClampToHelper<LimitType, ValueType>::clampTo(value, min, max);
}

....

Then use-of-unitialized-value is reported in a template which accesses |value|, |min| and |max| passed from the above function. I didn't see any chance of uninitialized-value in the above code. This is not related to SVG or paint invalidation because the criticized code accesses values in the stack copied from the local variables (which have been initialized) in AffineTransform::mapPoint() only.

>> seems a false-positive.
This is an extremely rare situation (haven't seen one in years). 

Are m_transform[0] .. m_transform[5] initialized? 

mmoroz@, inferno@ do we have results from the msan+origins build?

Re #8:
m_transform[0..5] should have been initialized by AffineTransform::AffineTransform().

Also the criticized code doesn't access these fields, but the local variables (double x2, y2) in AffineTransform::mapPoint() that are initialized in AffineTransform::map().

ClusterFuzz has detected this issue as fixed in range 411957:412168.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=6059266790391808

Fuzzer: inferno_twister
Job Type: linux_msan_chrome
Platform Id: linux

Crash Type: Use-of-uninitialized-value
Crash Address: 
Crash State:
  blink::AffineTransform::mapRect
  blink::SVGLayoutSupport::transformPaintInvalidationRect
  blink::PaintInvalidationState::computePaintInvalidationRectInBackingForSVG
  
Recommended Security Severity: Medium

Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_msan_chrome&range=411529:411868
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_msan_chrome&range=411957:412168

Minimized Testcase (1.65 Kb): https://cluster-fuzz.appspot.com/download/AMIfv96C2E3046foyI8E2uWqIWiy4N11H32txqQznKedL_8qiUrdZDNY3-ZTYP80AAXX8M-3kvXLRtX1ub61SnhEBpGDmP675x_JZxeFVEv8MIBqSJQeadEKF3IK4rIrYJfP6GDtn6GYQABYp_vf5MNQa_TmU48kiA?testcase_id=6059266790391808

Additional requirements: Requires HTTP

See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase is verified as fixed, closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

Regarding c#9, log for msan-no-origins-linux-release-411910: https://paste.googleplex.com/5259382086434816

log for msan-chained-origins-linux-release-411910: https://paste.googleplex.com/4739302567182336

They crash in different places...

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot