IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As suggest here:
https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
"You may optionally specify attribute names with ‘__’ preceding and
following the name. This allows you to use them in header files without
being concerned about a possible macro of the same name. For example,
you may use the attribute name __noreturn__ instead of noreturn. "
(cherry picked from commit 012c2f761bf1eb0b9c784b867293f7f1c17c3080)
Compiler flag -Wmaybe-uninitialized is quite noisy and produces many false
positives, especially when optimization flags are enabled (tested gcc 8.2.1),
so let's just disable it in systemd build.
For example, with CFLAGS=-O2, the build produces 11 such warnings and the
default CFLAGS of Fedora's rpmbuild warns about it in 176 places. A look at a
sample of those shows that most are false positives, where the compiler just
can't figure it out correctly. (While fixing those would be nice, I'm not sure
it's a good use of our time.)
The noisy [-Wmaybe-uninitialized] warnings are not just an annoyance, since
they make it harder to spot warnings that indicate actual problems (such as
variable declared but not used.) Silencing those is beneficial, so that
contributors would see warnings where there are actually actionable problems,
so there's a better chance of having those issues addressed before a PR is
pushed.
Tested:
$ CFLAGS='-O2 -Wp,-D_FORTIFY_SOURCE=2' meson build/
$ ninja -C build/
(NOTE: -Wp,-D_FORTIFY_SOURCE=2 prevents [-Wstringop-truncation] warnings.)
With the commands above, the build will not produce any [-Wmaybe-uninitialized]
warnings (or any other warnings), which is not really the case before this commit.
Also tested with rpmbuild on Fedora, after this commit there are no warnings
produced in the build step.
(cherry picked from commit 8794164fed5f0142c34358613f92f4f761af4edd)
Meson added -Doptimization and -Ddebug options, which obviously causes
a conflict with our -Ddebug options. Let's rename it.
Fixes#9883.
(cherry picked from commit 8f6b442a78d0b485f044742ad90b2e8271b4e68e)
On Fedora rawhide, since gnu-efi-3.0.8-3.fc29, many file paths are
changed to use `EFI_MACHINE_TYPE_NAME` instead of `gnu_efi_arch`.
Fixes#8896.
(cherry picked from commit 4b4ee0f781f6eaeb5c0dc8e2f9ea65ff8414356c)
linux/fs.h sys/mount.h, libmount.h and missing.h all include MS_*
definitions.
To avoid problems, only one of linux/fs.h, sys/mount.h and libmount.h
should be included. And missing.h must be included last.
Without this, building systemd may fail with:
In file included from [...]/libmount/libmount.h:31:0,
from ../systemd-238/src/core/manager.h:23,
from ../systemd-238/src/core/emergency-action.h:37,
from ../systemd-238/src/core/unit.h:34,
from ../systemd-238/src/core/dbus-timer.h:25,
from ../systemd-238/src/core/timer.c:26:
[...]/sys/mount.h:57:2: error: expected identifier before numeric constant
(cherry picked from commit 227b8a762fea1458547be2cdf0e6e4aac0079730)
"noreturn" is reserved and can be used in other header files we include:
[ 16s] In file included from /usr/include/gcrypt.h:30:0,
[ 16s] from ../src/journal/journal-file.h:26,
[ 16s] from ../src/journal/journal-vacuum.c:31:
[ 16s] /usr/include/gpg-error.h:1544:46: error: expected ‘,’ or ‘;’ before ‘)’ token
[ 16s] void gpgrt_log_bug (const char *fmt, ...) GPGRT_ATTR_NR_PRINTF(1,2);
Here we include grcrypt.h (which in turns include gpg-error.h) *after* we
"noreturn" was defined in macro.h.
(cherry picked from commit 848e863acc51ecfb0f3955c498874588201d9130)
This patch adds safe_atoux16 for parsing an unsigned hexadecimal 16bit int, and
uses that for parsing USB device and vendor IDs.
This fixes a compile error with gcc-8 because while we know that USB IDs are 2 bytes,
the compiler does not know that.
../src/udev/udev-builtin-hwdb.c:80:38: error: '%04X' directive output may be
truncated writing between 4 and 8 bytes into a region of size between 2 and 6
[-Werror=format-truncation=]
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Signed-off-by: Patrick Uiterwijk <puiterwijk@redhat.com>
(cherry picked from commit 5547c12503a683290eaed47954ffcfb2d1bc03cd)
The test cases from commit 8595102d3ddde6 check for the return value of
syslog_parse_identifier() and will catch the condition that produced
vulnerability from CVE-2018-16866.
Add these tests to our stable branches.
Tested that these tests will fail if the fix for CVE-2018-16866 is missing
from the branch.
The original code didn't account for the fact that strchr() would match on the
'\0' character, making it read past the end of the buffer if no non-whitespace
character was present.
This bug was introduced in commit ec5ff4445cca6a which was first released in
systemd v221 and later fixed in commit 8595102d3ddde6 which was released in
v240, so versions in the range [v221, v240) are affected.
This reverts commit c46365e5c958a79ab12cf164735a6433282ca7df.
floppym wrote:
> Please drop this commit from the v236-stable branch. It actually breaks
> things without a6bcef29579409872735a2cfbf77d1c61ea91332, which was added on
> master after v236.
We should be careful with errno in cleanup functions, and not alter it
under any circumstances. In the safe_close cleanup handlers we are
already safe in that regard, but let's add similar protections on other
cleanup handlers that invoke system calls.
Why bother? Cleanup handlers insert code at function return in
non-obvious ways. Hence, code that sets errno and returns should not be
confused by us overrding the errno from a cleanup handler.
This is a paranoia fix only, I am not aware where this actually mattered
in real-life situations.
(cherry picked from commit dfd14786b5aa49c3c8e3866c0ecfa6d90c531eb6)
Both netinet/icmp6.h and linux/in6.h will define struct in6_addr, and in
user space we want to use the netinet/icmp6.h variant.
Fixes build problem:
In file included from src/libsystemd-network/sd-radv.c:23:0:
/home/hegtvedt/work/os/product/sunrise/root/_build/v2/include/linux/in6.h:30:8:
error: redefinition of 'struct in6_addr'
(cherry picked from commit 8a2b193a55284ecb25e726d5563330787b49e89e)
When loading .netdev files we parse them twice: first we do one parsing
iteration to figure out their "kind", and then we do it again to parse
out the kind's parameters. The first iteration is run with a "short"
NetDev structure, that only covers the generic NetDev properties. Which
should be enough, as we don't parse the per-kind properties. However,
before this patch we'd still try to destruct the per-kind properties
which resulted in memory corruption. With this change we distuingish the
two iterations by the state field, so that the destruction only happens
when the state signals we are running with a full NetDev structure.
Since this is not obvious, let's add a lot of comments.
(cherry picked from commit f3c33b234d9f0256805722f02c7b4c4b59fd6de6)
In general we'd leak anything that was allocated in the first parsing of
netdev, e.g. netdev name, host name, etc. Use normal netdev_unref to make sure
everything is freed.
--- command ---
/home/zbyszek/src/systemd/build2/test-network
--- stderr ---
/etc/systemd/network/wg0.netdev:3: Failed to parse netdev kind, ignoring: wireguard
/etc/systemd/network/wg0.netdev:5: Unknown section 'WireGuard'. Ignoring.
/etc/systemd/network/wg0.netdev:9: Unknown section 'WireGuardPeer'. Ignoring.
NetDev has no Kind configured in /etc/systemd/network/wg0.netdev. Ignoring
/etc/systemd/network/br0.network:13: Unknown lvalue 'NetDev' in section 'Network'
br0: netdev ready
=================================================================
==11666==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7f3a314cf238 in __interceptor_strdup (/lib64/libasan.so.4+0x77238)
#1 0x7f3a30e71ad1 in free_and_strdup ../src/basic/string-util.c:870
#2 0x7f3a30d34fba in config_parse_ifname ../src/shared/conf-parser.c:981
#3 0x7f3a30d2f5b0 in next_assignment ../src/shared/conf-parser.c:155
#4 0x7f3a30d30303 in parse_line ../src/shared/conf-parser.c:273
#5 0x7f3a30d30dee in config_parse ../src/shared/conf-parser.c:390
#6 0x7f3a30d310a5 in config_parse_many_files ../src/shared/conf-parser.c:428
#7 0x7f3a30d3181c in config_parse_many ../src/shared/conf-parser.c:487
#8 0x55b4200f9b00 in netdev_load_one ../src/network/netdev/netdev.c:634
#9 0x55b4200fb562 in netdev_load ../src/network/netdev/netdev.c:778
#10 0x55b4200c607a in manager_load_config ../src/network/networkd-manager.c:1299
#11 0x55b4200818e0 in test_load_config ../src/network/test-network.c:128
#12 0x55b42008343b in main ../src/network/test-network.c:254
#13 0x7f3a305f8889 in __libc_start_main (/lib64/libc.so.6+0x20889)
SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
-------
(cherry picked from commit 281bb5c1102e573accdf665f1ab923e750e09217)
commit 7715629 (networkd: Fix race condition in [RoutingPolicyRule] handling (#7615)).
Does not fix race. Still there is a race in case of bride because the
bride goes down and up .
calling route_configure then link_set_routing_policy_rule and the
link_check_ready makes a race between routing_policy_rule_messages and route_messages.
While bride comes up and we call the call again route_configure if finds
it self in the callback function LINK_STATE_CONFIGURED networkd dies.
Let's handle first routing policy rules then route_configure. This fixes
the crash.
Closes#7797
(cherry picked from commit 27c34f732e7767b5cdc90fe7ad03ae0ea625671c)
When /sys is a symlink to the sysfs mountpoint, e.g. /path/to/sysfs.
Then, device->syspath was set to like /path/to/sysfs/devices/foo/baz.
This converts the path to /sys/devices/foo/baz.
Fixes#7676.
(cherry picked from commit 2e1ec12ec3329dddaa74d3ae1e819505166fe9ad)
On s390x and ppc64, the permissions of the /dev/kvm device are currently
not right as long as the kvm kernel module has not been loaded yet. The
kernel module is using MODULE_ALIAS("devname:kvm") there, so the module
will be loaded on the first access to /dev/kvm. In that case, udev needs
to apply the permission to the static node already (which was created via
devtmpfs), i.e. we have to specify the option "static_node=kvm" in the
udev rule.
Note that on x86, the kvm kernel modules are loaded early instead (via the
MODULE_DEVICE_TABLE(x86cpu, ...) feature checking), so that the right module
is loaded for the Intel or AMD hypervisor extensions right from the start.
Thus the "static_node=kvm" is not required on x86 - but it also should not
hurt here (and using it here even might be more future proof in case the
module loading is also done delayed there one day), so we just add the new
option to the rule here unconditionally.
(cherry picked from commit d35d6249d5a7ed3228b94fc0e36a36bc3fe84482)
The logic was completely borked since
e4d2984bf8514ab576a66d5ac1f1cde746bb32a3, correct that.
CID #1384234
(cherry picked from commit 2ac0ab5921a3153e0334b4342554fc0c87ab01c3)
Currently, if there are two /proc/self/mountinfo entries with the same
mount point path, the mount setup flags computed for the second of
these two entries will overwrite the mount setup flags computed for
the first of these two entries. This is the root cause of issue #7798.
This patch changes mount_setup_existing_unit to prevent the
just_mounted mount setup flag from being overwritten if it is set to
true. This will allow all mount units created from /proc/self/mountinfo
entries to be initialized properly.
Fixes: #7798
(cherry picked from commit 65d36b49508a53e56bae9609ff00fdc3de340608)
According to systemd.preset(5), presets files in /run should take
effect. However, before this patch, preset files in /run were
ignored.
(cherry picked from commit 7c59ab4ba11f7ac2afc3dc4f3ba9c97b72c34750)
Now RuntimeDirectory= does not create 'private' directory.
Thus, it is not neccessary to request new mount namespace.
Follow-up for 8092a48cc1d1fb20b66371576754df831d30a43b.
(cherry picked from commit b43ee82fc1366489963b319dd5f1f22d2833883c)
Including BitsPerSecond or Duplex values in .link files did not work when
set_slinksettings was called because the routine was not copying the base
parameters to the structure given to ioctl. As a result, EINVAL was always
reported, and no change occurred on the Ethernet device.
(cherry picked from commit 94d4acbe4b496c0f0c4e5e2143426751c8c5f9a9)
On a typical system running systemd, the telinit in PATH is very likely to be a symlink
to systemctl. Setting TELINIT to this may result in an infinite recursion if telinit is called
and sd_booted() == 0. This may commonly occur in a chroot environment.
Bug: https://bugs.gentoo.org/642724
[zj:
The path was originally hardcoded as "/lib/upstart/telinit", but was made configurable without
changing the default in 4ad61fd1806dde23d2c99043b4bed91a196d2c82. Then the default was
changed to `/lib/sysvinit/telinit` in abaaabf40a9891014ed4c402d7beb5a67ac256b1. Then it
started being autodetected when meson support was added in
5c23128daba7236a6080383b2a5649033cfef85c. This patch restores the behaviour that was
implemented in configure.ac at the time of its removal.]
(cherry picked from commit 2fa645f1ccbbed95868b0f25017533c8de2bba2b)
Close DHCPv6 client socket file descriptor when
sd_dhcp6_client_stop() is called and not when client_reset() is
called. If left in client_reset(), any internal temporary stopping
of the DHCPv6 client with client_stop() will call client_reset()
after which the DHCPv6 client will not be able to receive any further
DHCPv6 messages.
Similarly, client_start() needs to enable events for the DHCPv6
socket file descriptor since a call to client_stop() will call
client_reset() which will remove it from the main loop. Events should
be turned off when no DHCPv6 messages are expected.
(cherry picked from commit 7ac6c26a22294b3276953c635ac1e91b5d03db18)
Enumerating DNS-SD PTR resource records are a special case and
are supposed to have non-unique keys pointing to services of the
same type running on different hosts. There's no need for them
to be checked for conflicts.
Thus don't check for conflicts such RRs.
(cherry picked from commit cfcc8dcc86b4c18cc5885031c661c7f9ae32f781)
Refcounting for a RR's key is done separately from refcounting
for the RR itself, but in dns_scope_notify_conflict() we don't
do that. This may lead to a situation when a RR key put in the
conflict_queue hash as a value's key gets freed upon
cache reduction when it's still referenced by the hash.
Thus increase refcount for the key when putting it into the hash
and unreference it upon removing from the hash.
Closes#6456
(cherry picked from commit 432d108c25a9705f1564d7620c38cdf890df40ba)
The __get_cpuid() function only calls __cpuid() if __get_cpuid_max()
returns a value that is less than or equal to the leaf value.
In QEMU/KVM, I found that the special hypervisor leaf value (0x40000000U)
is always larger than the value retured by __get_cpuid_max().
Avoid this problem by calling the __cpuid() macro directly once we have
checked the hypervisor bit from leaf 1.
Fixes: d31b0033b7743393562a2e9d3c1e74afea981c13
(cherry picked from commit 8481e3e71e704a10af0b6d53d4b015b2b8e1e16b)
This fixes a compiler warning that matters, if people build systemd
without libseccomp.
Follow-up for a6bcef29579409872735a2cfbf77d1c61ea91332
(cherry picked from commit ad552e587f21bf00013d41d48737009a20be6479)
Ignoring errors from these functions may mask errors returned by the
kernel.
Fixes: https://github.com/systemd/systemd/issues/7744
(cherry picked from commit 94d3b60ff6ac7a29b10f16a0a651b1360627f465)
The kernel returns specific error codes which may be lost if we use the
libc buffered io functions.
Fixes: https://github.com/systemd/systemd/issues/7744
(cherry picked from commit 521251d2757295b6e9df4b51c7cb33929fbd65c4)
Ultimately, O_CLOEXEC should be off in fd 0, 1, 2, but when we open
/dev/null here it's unlikely to be < 0, and after dupping the fd to 0,
1, 2 we turn off O_CLOEXEC explicitly anyway.
Unless we know that what we are about to open will return 0, 1 or 2 we
should always set O_CLOEXEC in order to be safe to other threads forking
of subprocesses at the wrong moment.
(cherry picked from commit d8caff6db672ab0f2d8064c61f5ef0e8e8d288ca)
Our own calls return errors in their return values, hence use that
rather than errno when checking errors.
(cherry picked from commit e43bc9f5266c266ff4c84018a0d5f24bd1d125e4)
The boot loader systemd-boot removes ".conf" from file name of entry
configs, and determine which entry is the default entry.
However, bootspec, which is used by systemctl and bootctl did not
remove ".conf", then sometimes bootctl marks wrong entry as default.
This fixes the logic to choose the default entry in bootspec, to
match the logic used in systemd-boot boot loader.
Fixes#7727.
(cherry picked from commit 263195c6ddcc4a29a90e90a73c3fd0fd01b494ca)
