Original commit message:

    [stack-traces] Fix overflow in Error.stackTraceLimit trimming

    When stack traces are captured for uncaught exceptions (enabled via
    Isolate::SetCaptureStackTraceForUncaughtExceptions, e.g. by the
    inspector or by Node.js's --trace-uncaught), CaptureAndSetErrorStack
    reuses the simple stack trace and trims it to Error.stackTraceLimit.

    Error.stackTraceLimit counts frames, but the raw call site data stores
    CallSiteInfo::Fields::kCount slots per frame, so the trim multiplied the
    limit by kCount: once in the uint32_t comparison against the array
    length and once, as int, to compute the new length. GetStackTraceLimit
    clamps the limit to [0, INT_MAX], so for very large limits the uint32_t
    product can wrap to a value below the array length. The trim branch is
    then taken although the limit exceeds the number of captured frames,
    and the int multiplication of the new length overflows.

    On main (kCount == 5) the product first wraps at 858993460. That limit
    trimmed the raw data to 4 slots (no complete frame) and 858993461 to 9
    slots (one frame), so error.stack silently lost frames. Infinity, the
    value from the Node.js report, is clamped to INT_MAX; its wrapped
    product (2147483643) is not below the array length, so on main it does
    not take the trim branch and does not reach the signed overflow.

    Fix this by comparing the limit with the number of frames in the raw
    data (length / kCount), and only multiplying once the limit is known to
    be smaller than the frame count. The resulting length is then bounded
    by the existing array length and cannot overflow. Behavior for limits
    that did not overflow is unchanged, since the raw data length is always
    a multiple of kCount.

    This regressed with https://crrev.com/c/7673818 (ebd15783b7b,
    "[objects]: Defer CallSiteInfo creation"), which switched from one
    CallSiteInfo per frame to kCount raw slots per frame.

    This is the underlying cause of Node.js issue 66074. The symptom there
    differs from main: Node's V8 14.6 backport of that change has
    kCount == 6 and uses int for the comparison and for RightTrim, so the
    product overflows for limits above 357913941. For many of those,
    including Infinity (INT_MAX * 6 wraps to -6), the result is negative
    and fails "Check failed: new_capacity > 0." in RightTrim. Comparing in
    frames avoids the overflow in both cases.

    The new cctest CaptureStackTraceForUncaughtExceptionHugeStackTraceLimit
    enables capture for uncaught exceptions and checks that limits of
    858993460, 858993461 and Infinity yield the same error.stack as a limit
    of 10, and that a limit of 1 still trims to a single frame. 858993460
    and 858993461 are the first limits whose product with kCount wraps
    around uint32_t; both fail without this change. The new test and the
    existing stack trace tests also pass in a UBSan build, with no
    diagnostics.

    Bug: 565047704
    Refs: #66074
    Change-Id: I3422ca1de6a7dd9448c7fd53fb9bc5e40e2a17c1
    Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8426465
    Reviewed-by: Patrick Thier <pthier@chromium.org>
    Reviewed-by: Leszek Swirski <leszeks@chromium.org>
    Auto-Submit: eliau elkouby (‫אליהו אלקובי‬‎) <eliau.elkouby@gmail.com>
    Commit-Queue: Patrick Thier <pthier@chromium.org>
    Cr-Commit-Position: refs/heads/main@{#110043}

Refs: v8/v8@786c1c2
Fixes: #66074
Assisted-by: a closed-source coding agent
Signed-off-by: Eliau Elkouby <145869377+eliau2005@users.noreply.github.com>