It does seem bad to assume that the WebUChar array is terminated, as those call sites seem to assume. (Although I have not read and understood them in depth.)

But are there any ways that web contents (as opposed to Chromium C++ in Pepper or DevTools) can cause a |WebKeyboardEvent.text| to not be terminated or even to overflow?

For example, https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/initKeyboardEvent seems pretty tightly specified, and deprecated anyway. Is there another way to control the text field of WebKeyboardEvent from web contents?

+dcheng, who might find this interesting

This doesn't look like a security issue to me, although it isn't hard to imagine scenarios in which it might become one in future. As palmer@ notes, there doesn't seem to be a way for the text to be set from web-based content. It would also be problematic if it could be set by a renderer process and then used as a null-terminated string by a non-renderer process. Fortunately, there is a strong tendency for input events to traverse security boundaries in order of descending privilege.

This possibly causes a vulnerability when running with --site-per-process, because a compromised renderer could send a keyboard event back to the browser process, which causes a non-null-terminated string to be copied. That is not especially concerning because that is not a default flag.

Adjust bug types based on #2.