In `evutil_parse_sockaddr_port`, it would `memset` the `out` to zero,
however, the `memset` is unnecessary before `memcpy`, and may cause
undefined behavior if the `outlen` is invalid.
This should close#1573.
Found by oss-fuzz, after coverage had been improved in google/oss-fuzz#11257
v2: adjust test
v3: fix for windows (_get_osfhandle() crashes when called on closed fd)
v4: fix for EVENT__DISABLE_MM_REPLACEMENT
For example for openbsd-cmake-job (7.2, NONE)
This request was automatically failed because there were no enabled runners online to process the request for more than 1 days.
And maybe this will fix the macos builds.
Looks like after upgrading ubuntu from 18.04 (that has 1.9 version of
lvc abi tools) to 20.04 (that has 1.11) the abi-check started to
timeout (works longer then 6 hours, while usually few minutes, and
sometimes even faster was enough).
Unlikely upgrading ubuntu will help, since 22.04 and 20.04 has the same
version, but still, let's try.
Refs: #1463
In buffer.c a variable "flags" and a label "done" are defined but
never used if "EVENT__HAVEMMAP" is not defined.
The code does not work on platforms which do not provide
the function `socketpair()`. Introduce EVENT__HAVE_SOCKETPAIR flag
which determines if `socketpair()` or `evutil_ersatz_socketpair()`
is used.
Looks like there was garbage, since evutil_configure_monotonic_time_()
does not reset evutil_monotonic_timer structure, while in case of
fallback it uses two fields from it:
- last_time
- adjust_monotonic_clock
Fixes: https://github.com/libevent/libevent/issues/1495
/src/le/libevent/bufferevent_ssl.c:863: error: Null Dereference
pointer `bev_ssl` last assigned on line 855 could be null and is dereferenced at line 863, column 6.
861. r2 = start_writing(bev_ssl);
862.
863. if (bev_ssl->underlying) {
^
864. if (events & EV_READ)
865. BEV_RESET_GENERIC_READ_TIMEOUT(bev);
/src/le/libevent/bufferevent_filter.c:234: error: Null Dereference
pointer `bevf` last assigned on line 231 could be null and is dereferenced at line 234, column 6.
232. EVUTIL_ASSERT(bevf);
233.
234. if (bevf->bev.options & BEV_OPT_CLOSE_ON_FREE) {
^
235. /* Yes, there is also a decref in bufferevent_decref_.
236. * That decref corresponds to the incref when we set
Note, that in order to do this evrpc_hook_add_meta() should have return
value, so this is a minor ABI change, which should not affect C ABI, but
still worth to mention.
Anyway this will be done in 2.2 release and unlikely RPC subsystem is
popular.
Currently, libevent's HTTP parser accepts and ignores 0x, +, and whitespace prefixes on chunk sizes. It also ignores - prefixes on chunk sizes of 0. This patch fixes that.
There is a potential danger in the current behavior, which is that there exist HTTP implementations that interpret chunk sizes as their longest valid prefix. For those implementations, 0xa (for example) is equivalent to 0, and this may present a request smuggling risk when those implementations are used in conjunction with libevent. However, as far I'm aware, there is no HTTP proxy that both interprets 0xa as 0 and forwards it verbatim, so I think this is a low-risk bug that is acceptable to report in public.
As acfac7a#r124469888 mentioned, LibeventConfig.cmake is looking for MBedTLS package, even if libevent is not configured to use MBedTLS.
This PR makes MbedTLS and OpenSSL dependencies configurable.
Fixes: #1543
Currently, when libevent parses requests with version `HTTP/4294967295.255`, you end up with `req->major == req->minor == (char)-1`. (At least on linux-gnu-x86_64, where `char` is signed.)
This is sort of weird.
This patch changes the version parser to match the grammar in RFCs 7230 and 9112. (i.e. `HTTP/[0-9].[0-9]`)
EDIT: Technically, a little stronger than the RFC requires, since this patch continues to block major versions greater than 1, which was already what libevent was doing.
The `readv`/`writev` functions are designed for scattered I/O optimally,
their logic in the kernel is more sophisticated, compared to read/write,
which includes extra on-stack `iovec` in the kernel space, importing `iovec`
array from user space to kernel space, reading/writing with `iov_iter`, etc.
As a result, using `readv`/`writev` on single-segment `iovec` will fall into
the special branch in the kernel where it is imported as `ITER_UBUF` differed
from `ITER_IOVEC` for multiple-segments `iovec`.
Thus, it is just not worth calling `readv`/`writev` for single-segment `iovec`,
we should use `read`/`write` instead, to save it from going through the
sophisticated yet unnecessary kernel code path, circumvent a waste of
kernel on-stack memory, copying `iovec` between user space and kernel space, etc.
I sometimes browse and edit C/C++ code with VSCode,
and it would generate some project files in .vscode
which could easily be added and even pushed to a git repo by accident.
It's sort of annoying for programmers who work with VS/VSCode,
IntelliJ/Clion, or other widely-used IDE or editors to prevent
themself from using git command like `git add .` in lib event project.
Therefore, I propose leaving the project files generated by VS/VSCode
and IntelliJ/Clion untracked for libevent project. Hopefully, this can be accepted.
