[Webkit-unassigned] [Bug 234916] New: length argument passed to didReceiveData can never be negative.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=234916

            Bug ID: 234916
           Summary: length argument passed to didReceiveData can never be
                    negative.
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jean-yves.avenard at apple.com
            Blocks: 232424

As seen in bug 232424;

We have code pattern such as:
https://webkit-search.igalia.com/webkit/source/Source/WebCore/inspector/agents/InspectorNetworkAgent.cpp#127-136

```
    void didReceiveData(const uint8_t* data, int dataLength) override
    {
        if (!dataLength)
            return;

        if (dataLength == -1)
            dataLength = strlen(reinterpret_cast<const char*>(data));

        m_responseText.append(m_decoder->decode(data, dataLength));
    }
```

If the dataLength argument passed is negative; then the length will be calculated from running strlen on the uint8_t buffer.

We also have this code pattern in:
- XMLHttpRequest::didReceiveData
and:
- WorkerScriptLoader::didReceiveData

The common code path to end in those routines is from : DocumentThreadableLoader::didReceiveData
https://webkit-search.igalia.com/webkit/source/Source/WebCore/loader/DocumentThreadableLoader.cpp#447-455

The data itself originates from the network process where to carry the size it will use either a size_t (unsigned) or a FragmentedSharedBuffer (also unsigned size() ) so the size_t ends up being cast to an int64_t over IPC and cast again to an int.

If the data is cached; it originates from CachedRawResource::didAddClient
https://webkit-search.igalia.com/webkit/source/Source/WebCore/loader/cache/CachedRawResource.cpp#172-177
            if (m_data) {
                m_data->forEachSegment([&](auto& segment) {
                    if (hasClient(*client))
                        client->dataReceived(*this, segment.data(), segment.size());
                });
            }

and here segment.size() returns a size_t

if the data is not cached, it comes from:
void SubresourceLoader::didReceiveBuffer or SubresourceLoader::didReceiveData; which in either case will use an unsigned for the dataLength.

For non-webkit 2 code; the curl library always use size_t to pass the data length ; cocoa platform are using NSData which also uses an unsigned int to specify the size.

In some code such as:
bool FrameLoader::willLoadMediaElementURL
we have length set to -1:
https://webkit-search.igalia.com/webkit/source/Source/WebCore/loader/FrameLoader.cpp#1690

however, in this case the const uint8_t* is null and as such the length parameter is not used.


length/dataLength as used with didReceiveData methods can never be negative.

To simplify bug 232424, as mentioned in the review, we should simplify the code separately and remove the test checking that the length == -1.


Referenced Bugs:

https://bugs.webkit.org/show_bug.cgi?id=232424
[Bug 232424] Have CachedRawResourceClient and related networking actors use SharedBuffer.
-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220106/cafbc356/attachment-0001.htm>