1958224 - AddressSanitizer: heap-use-after-free [@ RecvdFin] through [@ mozilla::net::Http2Session::ReadyToProcessDataFrame] with READ of size 2

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[Christian Holler (:decoder)]

The attached testcase crashes on mozilla-central revision 20250401-87c6b5c18c28 (fuzzing build).

For detailed crash information, see attachment.

To reproduce the issue, perform the following steps:

1. Download the attached testcase, save as "test.bin".
   2a. Build with --enable-fuzzing (requires Clang and ASan, also build gtests using ./mach gtest dontruntests).
   2b. Alternatively you can download builds from TC using python -mfuzzfetch -a --fuzzing --target firefox gtest (see https://github.com/MozillaSecurity/fuzzfetch).
2. Run FUZZER=NetworkHttp2ProxyHttp2 objdir/dist/bin/firefox test.bin

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 3

[Christian Holler (:decoder)]

I haven't tried to reproduce this, let me know if it doesn't work. I figured the trace in connection with a recent change might be enough to spot what went wrong here.

Comment 4

[Kershaw Chang [:kershaw]]

This is regressed by bug 1874101.

I think the root cause is that we use a hash table to store the mapping between transactions and tunnel streams.
If another transaction uses the same address to create a tunnel stream, we may release the previous one, which leads to this crash.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1874101

Comment 6

[Kershaw Chang [:kershaw]]

Attachment: Bug 1958224 - Use nsTArray to store tunnel streams, r=#necko

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6b24b81749b4
Use nsTArray to store tunnel streams, r=necko-reviewers,valentin

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6b24b81749b4