This is severe. We cache the list of names, and we must invalidate the
cache when the names change. Otherwise, out-of-bound access and crash.
Fixes: d0192b698e ('libnm: add nm_setting_option_set(), nm_setting_option_get_boolean(), nm_setting_option_set_boolean()')
Fixes: 150af44e10 ('libnm: add nm_setting_option_get_uint32(), nm_setting_option_set_uint32()')
(cherry picked from commit 22dcfb3a67)
Currently NetworkManager fails to establish a NAP bridge because it never gets
out of the stage2.
This is caused because when making the BlueZ callback reentrant we return
NM_ACT_STAGE_RETURN_POSTPONE even after registration has succeeded.
This patch changes registration to a three state automaton instead of a
boolean. This allows distinguishing when we are waiting for registration
to finish and when it is done and therefore ensures that when the stage2
is called again by the callback the result is success so NetworkManager
can proceed to the IP configuration.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1181
(cherry picked from commit 8f7e295cbf)
We expect to read NUL terminated strings. Upon NUL, we should do
something. Treat it as a line break.
Fixes: 8ae9cf4698 ('Revert "libnm: buffer reads in nm_vpn_service_plugin_read_vpn_details()"')
(cherry picked from commit 6235815248)
This partially reverts commit 4a9fcb0fc3, which replaced one-byte
reads with buffered ones in the VPN service plugin.
Unfortunately the buffering means that commands coming after the magic
"DONE" string were being pulled into the buffer. Secrets agents expect
a "QUIT" to come after the "DONE", and since with buffering "QUIT" was
in the buffer, this led to a twenty-second delay on every VPN
connection using a secrets manager.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1164
Fixes: 4a9fcb0fc3 ('libnm: buffer reads in nm_vpn_service_plugin_read_vpn_details()')
(cherry picked from commit 8ae9cf4698)
The entire point of the dance in nm_platform_ip_address_sync() is to ensure that
conflicting IPv4 addresses are in their right order, that is, they have
the right primary/secondary flag.
Kernel only sets secondary flags for addresses that are in the same
subnet, and we also only care about the relative order of addresses
that are in the same subnet. In particular, because we rely on kernel's
"secondary" flag to implement this.
But kernel only treads addresses as secondary, if they share the exact
same subnet. For example, 192.168.0.5/24 and 192.168.0.6/25 would not
be treated as primary/secondary but just as unrelated addresses, even if
the address cleared of it's host part is the same.
This means, we must not only hash the network part of the addresses, but
also the prefix length. Implement that, by tracking the full NMPObject.
(cherry picked from commit 619dc2fcab)
(cherry picked from commit 0bdb2e97d9)
Fixes: 2f68a50041 ('platform: fix the order of addition of primary and secondary IPv4 addresses')
(cherry picked from commit 40f22e69c8)
(cherry picked from commit 41b56cb2b9)
None of the callers really handle the return value of nm_platform_ip_address_sync()
or whether the function encountered problems. What would they anyway do
about that?
For IPv4 we were already ignoring errors to add addresses, but for IPv6 we
aborted. That seems wrong. As the caller does not really handle errors,
I think we should follow through and add all addresses in case of error.
Still, also collect a overall "success" of the function and return it.
(cherry picked from commit cedaa191d4)
(cherry picked from commit 8736cc8618)
In the past, nm_platform_ip_address_sync() only had the @known_addresses
argument. We would figure out which addresses to delete and which to preserve,
based on what addresses were known. That means, @known_addresses must have contained
all the addresses we wanted to preserve, even the external ones. That approach
was inherently racy.
Instead, nowadays we have the addresses we want to configure (@known_addresses)
and the addresses we want to delete (@prune_addresses). This started to change in
commit dadfc3abd5 ('platform: allow injecting the list of addresses to prune'),
but only commit 58287cbcc0 ('core: rework IP configuration in NetworkManager using
layer 3 configuration') actually changed to pass separate @prune_addresses argument.
However, the order of IP addresses matters and there is no sensible kernel API
to configure the order (short of adding them in the right order), we still need
to look at all the addresses, check their order, and possibly delete some.
That is, we need to handle addresses we want to delete (@prune_addresses)
but still look at all addresses in platform (@plat_addresses) to check
their order.
Now, first handle @prune_addresses. That's simple. These are just the
addresses we want to delete. Second, get the list of all addresses in
platform (@plat_addresses) and check the order.
Note that if there is an external address that interferes with our
desired order, we will leave it untouched. Thus, such external addresses
might prevent us from getting the order as desired. But that's just
how it is. Don't add addresses outside of NetworkManager to avoid that.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
(cherry picked from commit 80f8e23992)
(cherry picked from commit 4c3197b377)
Fixes this error:
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
./configure: line 30294: ,as_fn_error: command not found
checking for a Python interpreter with version >= 3... python
checking for python... /usr/bin/python
Fixes: 3affccf29b ('tests: fix undefined references to pthread')
(cherry picked from commit a8284b1d3b)
According to WPA3_Specification_v3.0 section 2.3, when operating in
WPA3-Personal transition mode an AP:
- shall set MFPC to 1, MFPR to 0.
Therefore, do not operate in WPA3-Personal transition mode when PMF is set to
disabled. This also provides a way to be compatible with some devices that are
not fully compatible with WPA3-Personal transition mode.
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1186
(cherry picked from commit b6eb237a27)
(cherry picked from commit a0988868ba)
We have some reports of APs that advertise WPA2/WPA3 with
MFP-required=0/MFP-capable=0, and reject the association when the
client doesn't support 802.11w.
According to WPA3_Specification_v3.0 section 2.3, when operating in
WPA3-Personal transition mode a STA:
- should allow AKM suite selector: 00-0F-AC:6 (WPA-PSK-SHA256) to be
selected for an association;
- shall negotiate PMF when associating to an AP using SAE.
The first is guaranteed by capability PMF; the second by checking that
the interface supports BIP ciphers suitable for PMF.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/964https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907
(cherry picked from commit 1a7db1d7f7)
Introduce a new capability indicating whether the interface supports
any of the BIP ciphers that can be used for 802.11w (PMF).
(cherry picked from commit cd1e0193ab)
Curl's CURLOPT_RESOLVE expects one list entry per host. That
documentation ([1]) also makes that clear that the form is
"[+]HOST:PORT:ADDRESS[,ADDRESS]".
The way we constructed the list, only the last entry was honored:
<trace> [1647551393.5362] connectivity: (eth0,IPv4,25) adding 'fedoraproject.org:80:18.159.254.57' to curl resolve list
<trace> [1647551393.5363] connectivity: (eth0,IPv4,25) adding 'fedoraproject.org:80:152.19.134.142' to curl resolve list
<trace> [1647551393.5363] connectivity: (eth0,IPv4,25) adding 'fedoraproject.org:80:18.192.40.85' to curl resolve list
...
<trace> [1647551393.5366] connectivity: (eth0,IPv4,25) adding 'fedoraproject.org:80:85.236.55.6' to curl resolve list
<trace> [1647551393.5366] connectivity: (eth0,IPv4,25) adding 'fedoraproject.org:80:38.145.60.20' to curl resolve list
...
<trace> [1647551393.5415] connectivity: (eth0,IPv4,25) libcurl: == Info: Added fedoraproject.org:80:18.159.254.57 to DNS cache\012
<trace> [1647551393.5416] connectivity: (eth0,IPv4,25) libcurl: == Info: RESOLVE fedoraproject.org:80 is - old addresses discarded!\012
<trace> [1647551393.5416] connectivity: (eth0,IPv4,25) libcurl: == Info: Added fedoraproject.org:80:152.19.134.142 to DNS cache\012
<trace> [1647551393.5417] connectivity: (eth0,IPv4,25) libcurl: == Info: RESOLVE fedoraproject.org:80 is - old addresses discarded!\012
...
<trace> [1647551393.5422] connectivity: (eth0,IPv4,25) libcurl: == Info: RESOLVE fedoraproject.org:80 is - old addresses discarded!\012
<trace> [1647551393.5423] connectivity: (eth0,IPv4,25) libcurl: == Info: Added fedoraproject.org:80:38.145.60.20 to DNS cache\012
<trace> [1647551393.5424] connectivity: (eth0,IPv4,25) libcurl: == Info: Hostname fedoraproject.org was found in DNS cache\012
<trace> [1647551393.5424] connectivity: (eth0,IPv4,25) libcurl: == Info: Trying 38.145.60.20:80...\012
There are two possible fixes. Either join all addresses in one
entry, or use the '+' modifier. Do the former.
Now we get:
<trace> [1647551967.0378] connectivity: (eth0,IPv4,25) set curl resolve list to 'fedoraproject.org:80:38.145.60.21,152.19.134.142,152...
...
<trace> [1647551967.0559] connectivity: (eth0,IPv4,25) libcurl: == Info: Added fedoraproject.org:80:38.145.60.21,152.19.134.142,152.1...
<trace> [1647551967.0560] connectivity: (eth0,IPv4,25) libcurl: == Info: Hostname fedoraproject.org was found in DNS cache\012
<trace> [1647551967.0561] connectivity: (eth0,IPv4,25) libcurl: == Info: Trying 38.145.60.21:80...\012
[1] https://curl.se/libcurl/c/CURLOPT_RESOLVE.html
Reported-by: Bastien Nocera <hadess@hadess.net>
Fixes: 2cec94bacc ('connectivity: use systemd-resolved for resolving the check endpoint')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/648#note_1301596https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1153
(cherry picked from commit 14b9a9bd9d)
I think we should move away from using the source-ids.
Having a "GSource*" pointer makes it clearer what this is, compared to a
guint source ID. Also, g_source_remove() always needs to first do a hash
lookup (with locking) to resolve the source ID to the GSource. This is
unnecessary.
(cherry picked from commit ca9c67565a)
I got a report of a scenario where multiple servers reply to a REQUEST
in SELECTING, and all servers send NAKs except the one which sent the
offer, which replies with a ACK. In that scenario, n-dhcp4 is not able
to obtain a lease because it restarts from INIT as soon as the first
NAK is received. For comparison, dhclient can get a lease because it
ignores all NAKs in SELECTING.
Arguably, the network is misconfigured there, but it would be great if
n-dhcp4 could still work in such scenario.
According to RFC 2131, ACK and NAK messages from server must contain a
server-id option. The RFC doesn't explicitly say that the client
should check the option, but I think it's a reasonable thing to do, at
least for NAKs.
This patch stores the server-id of the REQUEST in SELECTING, and
compares it with the server-id from NAKs, to discard other servers'
replies.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1144
(cherry picked from commit 118561e284)
When a NMDevice is involved in a PPPoE activation, it means that the
connection has connection.interface-name=<ethernet-interface>. In such
case, the ppp ifindex should be set as ip-ifindex of the ethernet
device.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
(cherry picked from commit aa9b5e28eb)
It's not going to work.
Fixes: 58287cbcc0 ('core: rework IP configuration in NetworkManager using layer 3 configuration')
(cherry picked from commit 7b2bea7ceb)
Recent python-black (22.0) dropped support for Python 2 and thus fail
for those files. Make the examples Python3 compatible.
(cherry picked from commit 95e6a0a6e2)
nm_g_idle_add_source() is supposed to work like g_idle_add(). Use the correct
priority.
I think this causes little actual problems, because usually we don't
carefully tune the priorities and would be mostly fine with either.
Fixes: 6b18fc252d ('shared: add nm_g_{idle,timeout}_add_source() helpers')
(cherry picked from commit 15e8837945)
Found with `git grep 'GError.*[^,)];'| grep ' *= *NULL;' -v`
Fixes: d689380cfc ('team: support operation without D-Bus')
(cherry picked from commit 43748d2980)
NMClient is strongly tied to the GMainContext with which it was created.
Several operations must only be called from within the context. There
was an assertion for that.
However, creating (and init_async()) should be allowed to call not
from within the GMainContext. So if the current context has no owner
(is not acquired), then it's also OK.
Fix the assertion for that.
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
(cherry picked from commit ae0cc9618c)
Found with `git grep 'GError.*[^,)];'| grep ' *= *NULL;' -v`
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
(cherry picked from commit a9d521bf8c)
When cloud-init job (metadata service crawler) starts, it sends the
SIGTERM signal to nm-cloud-setup and force the nm-cloud-setup to
restart, however, because the error is not initialized as NULL in
`_init_start_cancelled_cb()` before it is set, nm-cloud-setup will hit
a dumped core.
TO fix it, initialize the error as NULL in `_init_start_cancelled_cb()`.
https://bugzilla.redhat.com/show_bug.cgi?id=2027674
Fixes: ce0e898fb4 ('libnm: refactor caching of D-Bus objects in NMClient')
Backtrace:
#0 g_logv (log_domain=0x7f833a872071 "GLib", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=<optimized out>) at ../glib/gmessages.c:1413
#1 0x00007f833a81f043 in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at ../glib/gmessages.c:1451
#2 0x00007f833ab97230 in nm_utils_error_set_cancelled (is_disposing=<optimized out>, instance_name=<optimized out>, error=0x7ffff79cb980) at src/libnm-glib-aux/nm-shared-utils.c:2599
#3 nm_utils_error_set_cancelled (is_disposing=0, instance_name=0x0, error=0x7ffff79cb980) at src/libnm-glib-aux/nm-shared-utils.c:2590
#4 _init_start_cancelled_cb (cancellable=<optimized out>, user_data=0x5640ca292150) at src/libnm-client-impl/nm-client.c:7324
#5 _init_start_cancelled_cb (cancellable=<optimized out>, user_data=0x5640ca292150) at src/libnm-client-impl/nm-client.c:7307
#6 0x00007f833a93094a in _g_closure_invoke_va (param_types=0x0, n_params=<optimized out>, args=0x7ffff79cbb40, instance=0x5640ca267020, return_value=0x0, closure=0x5640ca29d430)
at ../gobject/gclosure.c:873
#7 g_signal_emit_valist (instance=0x5640ca267020, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffff79cbb40) at ../gobject/gsignal.c:3406
#8 0x00007f833a930a93 in g_signal_emit (instance=instance@entry=0x5640ca267020, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3553
#9 0x00007f833a9a6475 in g_cancellable_cancel (cancellable=0x5640ca267020) at ../gio/gcancellable.c:513
#10 g_cancellable_cancel (cancellable=0x5640ca267020) at ../gio/gcancellable.c:487
#11 0x00005640ca1a8bd4 in sigterm_handler (user_data=0x5640ca267020) at src/nm-cloud-setup/main.c:599
#12 0x00007f833a819d4f in g_main_dispatch (context=0x5640ca268ef0) at ../glib/gmain.c:3337
#13 g_main_context_dispatch (context=0x5640ca268ef0) at ../glib/gmain.c:4055
#14 0x00007f833a86e608 in g_main_context_iterate.constprop.0 (context=0x5640ca268ef0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4131
#15 0x00007f833a819463 in g_main_loop_run (loop=0x5640ca24fdb0) at ../glib/gmain.c:4329
#16 0x00005640ca1a6d04 in nmc_client_new_waitsync (cancellable=0x5640ca267020, out_nmc=0x7ffff79cbfa0, error=0x7ffff79cbf98, first_property_name=0x5640ca1b11db "instance-flags",
first_property_name=0x5640ca1b11db "instance-flags") at src/libnm-client-aux-extern/nm-libnm-aux.c:129
#17 0x00005640ca1a3863 in main (argc=1, argv=<optimized out>) at src/nm-cloud-setup/main.c:639
(cherry picked from commit 549761b0ad)
Before, we would just ignore the errors when we passed an invalid value
to a property alias:
$ nmcli c add type ethernet mac Hello
Connection 'ethernet-1' (242eec76-7147-411a-a50b-336cf5bc8137) successfully added.
$ nmcli c show 242eec76-7147-411a-a50b-336cf5bc8137 |grep 802-3-ethernet.mac-address:
802-3-ethernet.mac-address: --
...or crash, because the GError would still be around:
$ nmcli c add type ethernet mac Hello ethernet.mac-address World
(process:734670): GLib-WARNING **: 14:52:51.436: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Error: failed to modify 802-3-ethernet.mac-address: 'World' is not a valid Ethernet MAC.
Error: failed to modify 802-3-ethernet.mac-address: 'Hello' is not a valid Ethernet MAC.
Now we catch it early enough:
$ nmcli c add type ethernet mac Hello
Error: failed to modify 802-3-ethernet.mac-address: 'Hello' is not a valid Ethernet MAC.
Fixes: 40032f4614 ('cli: fix resetting values via property alias')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1134
(cherry picked from commit a7ef068186)
