Suppress a leak report from openssl:
Direct leak of 192 byte(s) in 1 object(s) allocated from:
#0 0x7f6fe9c6b677 in __interceptor_malloc (/lib64/libasan.so.6+0xb0677)
#1 0x7f6fe4d4046d in CRYPTO_zalloc crypto/mem.c:230
#2 0x7f6fe4d0a91f in ENGINE_new crypto/engine/eng_lib.c:34
#3 0x7f6fe4d0c40d in ENGINE_rdrand crypto/engine/eng_rdrand.c:70
#4 0x7f6fe4d0c40d in engine_load_rdrand_int crypto/engine/eng_rdrand.c:85
#5 0x7f6fe4d370ec in ossl_init_engine_rdrand crypto/init.c:353
#6 0x7f6fe4d370ec in ossl_init_engine_rdrand_ossl_ crypto/init.c:347
#7 0x7f6fe995aace in __pthread_once_slow (/lib64/libpthread.so.0+0x11ace)
#8 0x7f6fe4da68fc in CRYPTO_THREAD_run_once crypto/threads_pthread.c:118
#9 0x7f6fe4d378ec in OPENSSL_init_crypto crypto/init.c:723
#10 0x7f6fe4d378ec in OPENSSL_init_crypto crypto/init.c:620
#11 0x7f6fe5292280 (/usr/lib64/pkcs11/libsofthsm2.so+0x78280)
#12 0x7f6fe5292364 (/usr/lib64/pkcs11/libsofthsm2.so+0x78364)
#13 0x7f6fe526f151 in SoftHSM::C_Initialize(void*) /usr/src/debug/softhsm-2.5.0-4.fc32.3.x86_64/src/lib/SoftHSM.cpp:485
#14 0x7f6fe523cc97 in C_Initialize (/usr/lib64/pkcs11/libsofthsm2.so+0x22c97)
#15 0x7f6fe4ecb233 in initialize_module_inlock_reentrant ../p11-kit/modules.c:738
#16 0x7f6fe4ecb382 in managed_C_Initialize ../p11-kit/modules.c:1584
#17 0x7f6fe4ecdbdf in p11_kit_modules_initialize ../p11-kit/modules.c:2157
#18 0x7f6fe4ecdbdf in p11_kit_modules_initialize ../p11-kit/modules.c:2145
#19 0x7f6fe4ed1a96 in proxy_create ../p11-kit/proxy.c:330
#20 0x7f6fe4ed1a96 in proxy_C_Initialize ../p11-kit/proxy.c:398
#21 0x7f6fe9a343b1 in secmod_ModuleInit /usr/src/debug/nss-3.51.0-1.fc32.x86_64/nss/lib/pk11wrap/pk11load.c:244
#22 0x7f6fe9a34adb in secmod_LoadPKCS11Module /usr/src/debug/nss-3.51.0-1.fc32.x86_64/nss/lib/pk11wrap/pk11load.c:501
#23 0x7f6fe9a419ec in SECMOD_LoadModule /usr/src/debug/nss-3.51.0-1.fc32.x86_64/nss/lib/pk11wrap/pk11pars.c:1840
#24 0x7f6fe9a41b27 in SECMOD_LoadModule /usr/src/debug/nss-3.51.0-1.fc32.x86_64/nss/lib/pk11wrap/pk11pars.c:1876
#25 0x7f6fe9a0dd00 in nss_Init /usr/src/debug/nss-3.51.0-1.fc32.x86_64/nss/lib/nss/nssinit.c:712
#26 0x7f6fe9a0e3ab in NSS_NoDB_Init /usr/src/debug/nss-3.51.0-1.fc32.x86_64/nss/lib/nss/nssinit.c:950
#27 0x55c942e2f1b2 in _nm_crypto_init libnm-core/nm-crypto-nss.c:61
#28 0x55c942d6f2da in nm_crypto_load_and_verify_certificate libnm-core/nm-crypto.c:721
#29 0x55c942c99681 in _cert_impl_set libnm-core/nm-setting-8021x.c:497
#30 0x55c942c9d83b in nm_setting_802_1x_set_ca_cert libnm-core/nm-setting-8021x.c:1033
#31 0x55c942c63513 in _test_8021x_cert_from_files libnm-core/tests/test-keyfile.c:382
#32 0x55c942c6425a in test_8021x_cert libnm-core/tests/test-keyfile.c:436
#33 0x7f6fe965429d in test_case_run ../glib/gtestutils.c:2633
#34 0x7f6fe965429d in g_test_run_suite_internal ../glib/gtestutils.c:2721
(cherry picked from commit 8113bc22d4)
On CentOS 8, many devel packages are not available. Even after
# dnf config-manager --set-enabled PowerTools
certain devel packages are missing. Some of these (libndp-devel,
mobile-broadband-provider-info-devel, teamd-devel) we build in copr
([1]), but libpsl-devel and qt-devel are still missing.
Only install them optionally and allow failure for them not being
present.
[1] https://copr.fedorainfracloud.org/coprs/nmstate/nm-build-deps/repo/epel-8/nmstate-nm-build-deps-epel-8.repo
(cherry picked from commit 1473f00d74)
UBSan marks these:
libnm-core/tests/test-setting.c:2146:2: runtime error: left shift of 65521 by 16 places cannot be represented in type 'int'
#0 0x561739bed935 in test_tc_config_qdisc libnm-core/tests/test-setting.c:2146
(cherry picked from commit 14bf28f109)
UBSan correctly flags this:
clients/cli/devices.c:966:2: runtime error: null pointer passed as argument 2, which is declared to never be null
(cherry picked from commit 18b903943d)
By passing as length of the MAC addresses -1 for both arguments, one
could get through to compare empty strings, NULL, and addresses longer
than the maximum. Such addresses are not valid, and they should never
compare equal (not even to themselves).
This is a change in behavior of public API, but it never made sense to
claim two addresses are equal, when they are not even valid addresses.
Also, avoid undefined behavior with "NULL, -1, NULL, -1" arguments,
where we would call memcmp() with zero length and NULL arguments.
UBSan flags that too.
(cherry picked from commit 54a64edefc)
When configuring with sanitizers enabled, ./configure.ac sets
-DVALGRIND=1 in the CFLAGS.
This causes a compilation error later:
$ /bin/sh ./libtool --tag=CC --mode=compile gcc ... -DVALGRIND=1 ... src/dhcp/nm-dhcp-nettools.c
...
In file included from src/dhcp/nm-dhcp-nettools.c:16:
./shared/systemd/sd-adapt-shared/nm-sd-adapt-shared.h:73: error: "VALGRIND" redefined [-Werror]
#define VALGRIND 0
(cherry picked from commit 3c581cbb78)
Callbacks might reference the main loop when destroying the NMClient
instance. Unref the main loop later.
# G_DEBUG=fatal-warnings valgrind --num-callers=100 nmcli device wifi connect home
^C
Error: nmcli terminated by signal Interrupt (2)
Error: Connection activation failed: (0) No reason given.
==11050== Invalid read of size 4
==11050== at 0x4C90D3D: g_main_loop_quit (in /usr/lib64/libglib-2.0.so.0.6200.6)
==11050== by 0x431435: quit (devices.c:934)
==11050== by 0x43272C: connected_state_cb (devices.c:1919)
==11050== by 0x4BF6741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4C0A603: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4C133AD: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4C139D2: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4BFB1C3: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4BFAAEC: ??? (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x4BFD86A: g_object_thaw_notify (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x48BA040: _nm_client_notify_event_emit (nm-client.c:937)
==11050== by 0x48CA01F: _dbus_handle_changes_commit (nm-client.c:2850)
==11050== by 0x48CC221: _dbus_handle_changes (nm-client.c:2864)
==11050== by 0x48CC833: _init_release_all (nm-client.c:6969)
==11050== by 0x48D2818: dispose (nm-client.c:7826)
==11050== by 0x4BFBC27: g_object_unref (in /usr/lib64/libgobject-2.0.so.0.6200.6)
==11050== by 0x43FF93: nmc_cleanup (nmcli.c:941)
==11050== by 0x4410AD: main (nmcli.c:1005)
==11050== Address 0x54738fc is 12 bytes inside a block of size 16 free'd
==11050== at 0x4839A0C: free (vg_replace_malloc.c:540)
==11050== by 0x4C9649C: g_free (in /usr/lib64/libglib-2.0.so.0.6200.6)
==11050== by 0x4410A3: main (nmcli.c:1004)
==11050== Block was alloc'd at
==11050== at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==11050== by 0x4C96400: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6200.6)
==11050== by 0x4C90A45: g_main_loop_new (in /usr/lib64/libglib-2.0.so.0.6200.6)
==11050== by 0x441020: main (nmcli.c:987)
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/501
(cherry picked from commit 211c6fa795)
When doing a release, we should care about the checksum of the tarball.
Log all of them... also, because fedpkg uses sha512, ftpadmin@gnome uses
sha256, etc.
(cherry picked from commit 3f6f7b06c6)
Reported by coverity:
>>> CID 210230: Control flow issues (UNREACHABLE)
>>> This code cannot be reached: "i = 0;".
Fixes: 09e17888f7 ('libnm: add mapping functions between string and NMClientPermission enum')
(cherry picked from commit a29b13c7f1)
Reported by coverity:
>>> CID 210222: Null pointer dereferences (NULL_RETURNS)
>>> Dereferencing a pointer that might be "NULL" "f" when calling
"fseek".
Fixes: ac5206aa9c ('2007-11-21')
(cherry picked from commit 581aa981c2)
Reported by coverity:
>>> CID 210228: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "dbobj" suggests that it may be null, but it has
already been dereferenced on all paths leading to the check.
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
(cherry picked from commit 272f19108b)
Reported by coverity:
>>> CID 210213 Uninitialized pointer read (UNINIT)
>>> Using uninitialized value iter when calling
_nm_auto_free_variant_iter
Fixes: df1d214b2e ('clients: polkit-agent: implement polkit agent without using libpolkit')
(cherry picked from commit 8cb58ef1eb)
Reported by coverity:
>>> CID 210217: (UNINIT)
>>> Using uninitialized value "identities_gvariant" when calling
"gs_local_variant_unref".
Fixes: df1d214b2e ('clients: polkit-agent: implement polkit agent without using libpolkit')
(cherry picked from commit fbccd24db6)
The manual page claimed that for "connectivitiy-change" actions, the dispatcher
scripts would get as first argument (the device name) "none". That was not done,
only for "hostname" actions.
For consistency, maybe that should be adjusted to also pass "none" for connectivity
change events. However, "none" is really an odd value, if there is no device. Passing
an empty word is IMO nicer. So stick to that behavior, despite being inconsistent.
Also fix the documentation about that.
(cherry picked from commit 0b168f7b99)
Currently any error encountered in n_dhcp4_c_connection_dispatch_io()
causes a dispatch failure and interrupts the library state
machine. The recvmsg() on the socket can fail for different reasons;
one of these is for example that the UDP request previously sent got a
ICMP port-unreachable response. This can be reproduced in the
following way:
ip netns add ns1
ip link add veth0 type veth peer name veth1
ip link set veth1 netns ns1
ip link set veth0 up
cat > dhcpd.conf <<EOF
server-identifier 172.25.0.1;
max-lease-time 120;
default-lease-time 120;
subnet 172.25.0.0 netmask 255.255.255.0 {
range 172.25.0.100 172.25.0.200;
}
EOF
ip -n ns1 link set veth1 up
ip -n ns1 address add dev veth1 172.25.0.1/24
ip netns exec ns1 iptables -A INPUT -p udp --dport 67 -j REJECT
ip netns exec ns1 dhcpd -4 -cf dhcpd.conf -pf /tmp/dhcp-server.pid
If a client is started on veth0, it is able to obtain a lease despite
the firewall rule blocking DHCP, because dhcpd uses a packet
socket. Then it fails during the renewal because the recvmsg() fails:
dhcp4 (veth0): send REQUEST of 172.25.0.178 to 172.25.0.1
dhcp4 (veth0): error -111 dispatching events
dhcp4 (veth0): state changed bound -> fail
The client should consider such errors non fatal and keep running.
https://bugzilla.redhat.com/show_bug.cgi?id=1829178https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/486
(cherry picked from commit c5d1d4c498)
It is very uncommon that a user provides explicit SSIDs to scan.
So, most of the time there is nothing to do here.
(cherry picked from commit d9740d108d)
Only _scan_request_ssids_track() adds elements to the list, and that already
trims the list to a maxium length. In all other cases, we never expect a need
to trim the list.
(cherry picked from commit 3af9209d47)
We make decisions based on the timestamp. We should only fetch the timestamp
once, and make consistent decisions about that. Don't read different timestamps.
(cherry picked from commit a0e115cb44)
