Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A 32-bit signed integer truncation in libxml2’s xmlEscapeText function can cause xmlRealloc to return an undersized buffer. This can potentially be exploited by a compromised renderer via the NotificationService.DisplayPersistentNotification Mojo IPC, leading to an out-of-bounds write and a sandbox escape in the browser process.

Affected files:

• third_party/libxml/src/xmlIO.c
• chrome/browser/notifications/win/notification_template_builder.cc
• chrome/browser/notifications/notification_platform_bridge_win.cc
• third_party/libxml/src/entities.c
• third_party/libxml/src/xmlwriter.c
• third_party/libxml/chromium/xml_writer.cc

Estimated timestamp from git blame: 2025-12-04

Vulnerability Description

There is a potential heap buffer overflow in libxml2’s xmlEscapeText function (located at third_party/libxml/src/xmlIO.c:175), which is reachable from the browser process via Windows notifications. The vulnerability stems from a 32-bit signed integer truncation when calculating a reallocation size for an internal buffer.

During string processing, xmlEscapeText calculates newSize for reallocation:

// third_party/libxml/src/xmlIO.c:266-286
if (totalSize > size - used) {
    xmlChar *tmp;
    int newSize; // Vulnerable: declared as signed 32-bit int

    // Insufficient check: only checks against SIZE_MAX, not INT_MAX
    if ((size > (SIZE_MAX - 1) / 2) ||
        (totalSize > (SIZE_MAX - 1) / 2 - size)) {
        xmlFree(buffer);
        return(NULL);
    }
    newSize = size + totalSize; // Truncation from size_t to int
    if (*cur != 0)
        newSize *= 2; // Signed integer overflow/wrap-around
    tmp = xmlRealloc(buffer, newSize + 1);
    // ...
    buffer = tmp;
    size = newSize;
    out = buffer + used;
}

Although the preceding checks ensure size and totalSize do not overflow SIZE_MAX, newSize is declared as a signed 32-bit int. If the sum of size and totalSize exceeds INT_MAX (2.147 GB), the assignment to newSize truncates. Furthermore, if *cur != 0, the multiplication by 2 will cause the negative int to wrap around (in 2’s complement arithmetic) to a small positive value (e.g., -2147483640 * 2 becomes 16).

xmlRealloc will then successfully allocate this tiny buffer. However, the used variable (the offset of data written so far) retains its massive value. The output pointer out = buffer + used will point far beyond the bounds of the newly allocated buffer, resulting in a massive out-of-bounds write during the subsequent memcpy(out, base, unescapedSize).

Reachability and Attack Vector

A compromised renderer can trigger this vulnerability by sending an extremely large string via the NotificationService.DisplayPersistentNotification Mojo IPC.

1. Mojo Limit Bypass: Although Mojo defines a max_message_num_bytes of 256 MB, this limit is only checked on the sending side by triggering a DumpWithoutCrashing(); it does not block the message. The receiving side in the browser process (mojo/core/channel.cc) does not enforce this limit during deserialization.
2. Notification Processing: After verifying the origin holds the Notifications permission, NotificationPlatformBridgeWinImpl::Display calls BuildNotificationTemplate. This invokes base::UTF16ToUTF8, converting the attacker’s UTF-16 payload into a UTF-8 string.
3. Libxml2 Execution: The massive UTF-8 string is passed to XmlWriter::AppendElementContent, which internally calls xmlEscapeText.

By carefully structuring the input string with chunks of normal text interspersed with XML-escapable characters, an attacker can precisely steer the size and used variables in xmlEscapeText up to ~2.145 GB (just under PartitionAlloc’s MaxDirectMapped limit), triggering the truncation and the subsequent undersized allocation.

Exploitability

This vulnerability provides an attacker with a controlled out-of-bounds write deep into the browser process’s heap. Because Chromium’s 64-bit address space relies on predictable heap layouts, an attacker could use standard heap spraying techniques prior to triggering the vulnerability to place target objects (e.g., C++ objects with vftables) at the destination offset. Overwriting these function pointers would lead to arbitrary Remote Code Execution (RCE) in the unsandboxed browser process, constituting a full sandbox escape.

(Note: These are suggested steps; a working proof-of-concept has not been run.)

Suggested Fix

1. Upstream (libxml2): In third_party/libxml/src/xmlIO.c, change the type of newSize from int to size_t at line 268 to prevent truncation.
2. Chromium IPC: Enforce maximum string length limits for title and body in blink.mojom.NotificationService before processing them in the browser process. Additionally, consider strictly enforcing Mojo’s max_message_num_bytes on the receiving end in mojo/core/channel.cc.

Evaluated with Chrome root at commit: a1e33f5848218e21d4a16ae2c1bc94e815c30c7f

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.