Find it did not provide any possible suspect.
Assigning to the concern owner from CL --
https://chromium.googlesource.com/chromium/src/+log/4af1869e97cdf585994c422c22423f6d6fcf68ce..9be83c0490323e941cabd41da1edf5b6079a954b?pretty=fuller

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/656b55356751d12fd8c643f927691275ef10dded

@mmoroz -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

Passing this over to sqlite3 OWNERS.

FYI, I don't see the same crash on OSS-Fuzz (maybe different versions matter), but I've uploaded a testcase manually, let's see: https://clusterfuzz-external.appspot.com/testcase?key=5641089482489856&noredirect=1

Looks like upstream version is not affected.

There were two similar reports earlier:

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=214

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=222

SELECT  time(1,8||"0E065 year");|"SC
-> SELECT time(1, "80E65 year");

80E65 is parsed into a double r, so it should be representable.  So then p->Y += (int)r is going to be undefined either in the cast, or in the addition.  I'm not sure how this is reporting -2^31.

Upstream "fixes" this by defining ranges for different transforms, with "year" at 14713.

I'm not sure this is actionable, we'll get a fix if/when we do an upgrade, meanwhile I don't think it's exploitable (if we have code relying on SQLite's time handling rather than base/time, we're doing things very incorrectly).

ClusterFuzz has detected this issue as fixed in range 458107:458176.

Detailed report: https://clusterfuzz.com/testcase?key=6237856210354176

Fuzzer: libfuzzer_sqlite3_ossfuzz_fuzzer
Job Type: libfuzzer_chrome_ubsan
Platform Id: linux

Crash Type: Integer-overflow
Crash Address: 
Crash State:
  parseModifier
  isDate
  timeFunc
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=433990:434098
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_ubsan&range=458107:458176

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv94Jen3b1iSWvx1OmP7l4QvisTwWpfcvrOH7iIvouXfnycd6RA-48p8rRgPK4PYHZx1q7S8OGNWndqmntZtLZte2lN7HOHWUKMH_F_0wIsvluujdcfHYo61h1yHCsJFZj5BEAQADMeIYF-ReMWl8sgM7VZqduQOIHt0n0kazqo3p4q9BGwdp5oKg-PqvRxV3oXCqJnGGK40EXQnSQ2aQm-U8-CTxBpNfRw3DXFleJ5x_fZ1VgCycjSJugCSazSRU5VrJsP2KtIZTCueMh3BS5xW00vNRckpn9Qffo8sKtb3--0Q0oaylE0j1Z9bczQGILGI14dvASkik8VhnqsLAd5oqo8D4jKSSmzUEtuuIqKyRp7WuQLw?testcase_id=6237856210354176


See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md 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 6237856210354176 is verified as fixed, so closing issue.

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