зеркало из https://github.com/mozilla/gecko-dev.git
9d31470f82
Normally, when `readlink` is called with a buffer that's smaller than
the symlink target, the string will be silently truncated and `readlink`
returns the number of bytes actually written (== the buffer size); the
caller is expected to detect this and enlarge the buffer as needed.
In the broker protocol, the client sends the buffer size in the request,
and then reads the response directly into the buffer. The bug is that
the broker ignores the requested size and sends the entire response; as
a result, the response is truncated by `recvmsg` and the `MSG_TRUNC`
flag is set. We don't expect `MSG_TRUNC`, so this either sets off a
diagnostic assertion or else fails with the implausible error `EMFILE`
("Too many open files", because it's treated the same as `MSG_CTRUNC`).
The fix simply is for the broker to respect the client's advertised
buffer size as intended; the error handling is also improved.
Note that `EMSGSIZE` is not used as a pseudo-error here, even though
"Message too long" might make sense as an error message, to avoid
confusion with the real `EMSGSIZE` that can be returned by `sendmsg`.
Differential Revision: https://phabricator.services.mozilla.com/D192530
|
||
|---|---|---|
| .. | ||
| certverifier | ||
| ct | ||
| mac/hardenedruntime | ||
| manager | ||
| nss | ||
| rlbox | ||
| sandbox | ||
| .eslintrc.js | ||
| generate_mapfile.py | ||
| moz.build | ||
| nss.symbols | ||