Frantisek Sumsal
a56d7db48f
Turns out that clang's interprocedural analysis is quite smart and can look through our expand_to_usable() trick, which then causes crashes with _FORTIFY_SOURCE=3. clang's interprocedural analysis can see that expand_to_usable() simply returns its first argument, so it replaces all uses of the return value with that argument (the original realloc() result). This effectively bypasses expand_to_usable()'s alloc_size attribute, causing the fortify check to use the (smaller) size from realloc() instead, which eventually leads to a false-positive buffer overflow: $ build/test-varlink-idl /* test_parse_format */ ... *** buffer overflow detected ***: terminated Aborted (core dumped) build/test-varlink-idl This is not an issue with gcc (at least not yet), since gcc sees expand_to_usable() as an opaque user-defined allocation-like function and simply trusts the alloc_size attribute that comes with it. To fix this, let's add a simple no-op barrier to malloc_sizeof_safe() that clobbers the input pointer, which causes __builtin_dynamic_object_size() to return (size_t)-1 - this is interpreted as an "unknown" size by the following fortify check which is then skipped instead of triggering the assertion. Similarly, test-alloc-util now doesn't call malloc_usable_size() directly but instead goes through malloc_sizeof_safe(), so it's also guarded by the barrier. This follows the already established pile of similar workaround for the same class of issues we encountered with gcc, namely [0], which prompted [1], that was later reverted in [2], and then followed by another couple of fixes in [3] and [4]. Resolves: #43178 [0] https://github.com/systemd/systemd/issues/22801 [1] https://github.com/systemd/systemd/commit/0bd292567a543d124cd303f7dd61169a209cae64 [2] https://github.com/systemd/systemd/commit/2cfb790391958ada34284290af1f9ab863a515c7 [3] https://github.com/systemd/systemd/commit/7929e180aa47a2692ad4f053afac2857d7198758 [4] https://github.com/systemd/systemd/commit/4f79f545b3c46c358666c9f5f2b384fe50aac4b4
System and Service Manager
Details
Most documentation is available on systemd's website.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release