==1345== Invalid read of size 1
==1345== at 0x827DC15: vfprintf (vfprintf.c:1642)
==1345== by 0x8345D04: __vasprintf_chk (vasprintf_chk.c:66)
==1345== by 0x7F882DB: vasprintf (stdio2.h:210)
==1345== by 0x7F882DB: g_vasprintf (gprintf.c:316)
==1345== by 0x7F6319C: g_strdup_vprintf (gstrfuncs.c:507)
==1345== by 0x7F63258: g_strdup_printf (gstrfuncs.c:533)
==1345== by 0x472833: nm_platform_link_to_string (nm-platform.c:2337)
==1345== by 0x472A05: log_link (nm-platform.c:2754)
==1345== by 0x9DC5D5F: ffi_call_unix64 (unix64.S:76)
==1345== by 0x9DC57D0: ffi_call (ffi64.c:525)
==1345== by 0x7CBA553: g_cclosure_marshal_generic (gclosure.c:1448)
==1345== by 0x7CB9D34: g_closure_invoke (gclosure.c:768)
==1345== by 0x7CCB34B: signal_emit_unlocked_R (gsignal.c:3483)
==1345== Address 0xa91b5a0 is 0 bytes inside a block of size 5 free'd
==1345== at 0x4C2ACE9: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==1345== by 0x68E7D6D: link_free_data (link.c:223)
==1345== by 0x6D47B1F: nl_object_free (object.c:186)
==1345== by 0x46C31C: put_nl_object (nm-linux-platform.c:222)
==1345== by 0x46C31C: link_change (nm-linux-platform.c:2354)
==1345== by 0x46C87F: link_set_user_ipv6ll_enabled (nm-linux-platform.c:2583)
==1345== by 0x4476C4: set_nm_ipv6ll (nm-device.c:4418)
==1345== by 0x4476C4: ip6_managed_setup (nm-device.c:7515)
==1345== by 0x453F12: _set_state_full (nm-device.c:7665)
==1345== by 0x4B6609: add_device (nm-manager.c:1885)
==1345== by 0x4B6880: system_create_virtual_device (nm-manager.c:1126)
==1345== by 0x4B6B40: system_create_virtual_devices (nm-manager.c:1163)
==1345== by 0x4B6E00: platform_link_added (nm-manager.c:2213)
==1345== by 0x4B6E00: platform_link_cb (nm-manager.c:2228)
==1345== by 0x9DC5D5F: ffi_call_unix64 (unix64.S:76)
(cherry picked from commit f93f0e0b15)
ndp_close() does not do that -- it only closes the socket. It's safe to call
even if we didn't start solicitation as it has a NULL-check.
==7745== 80 (+80) bytes in 2 (+2) blocks are definitely lost in loss record 3,983 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x6F57A2D: ndp_msgrcv_handler_register (libndp.c:1697)
==7745== by 0x47572E: start (nm-lndp-rdisc.c:691)
==7745== by 0x44A457: addrconf6_start_with_link_ready (nm-device.c:4280)
==7745== by 0x44C1E7: linklocal6_complete (nm-device.c:3931)
==7745== by 0x44C1E7: update_ip_config (nm-device.c:6667)
==7745== by 0x44C2F8: queued_ip_config_change (nm-device.c:6688)
==7745== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==7745== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==7745== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
==7745== by 0x7F451B1: g_main_loop_run (gmain.c:3975)
==7745== by 0x432F74: main (main.c:460)
(cherry picked from commit 5d9f9febfb)
==7745== 37 (+37) bytes in 1 (+1) blocks are definitely lost in loss record 2,679 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x7F4A6F5: g_malloc (gmem.c:97)
==7745== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==7745== by 0x45B097: set_property (nm-dhcp-client.c:851)
==7745== by 0x7CBF688: object_set_property (gobject.c:1415)
==7745== by 0x7CBF688: g_object_new_internal (gobject.c:1808)
==7745== by 0x7CC1194: g_object_new_valist (gobject.c:2034)
==7745== by 0x7CC14D0: g_object_new (gobject.c:1617)
==7745== by 0x45FF9F: client_start (nm-dhcp-manager.c:253)
==7745== by 0x460393: nm_dhcp_manager_start_ip4 (nm-dhcp-manager.c:308)
==7745== by 0x44EB16: dhcp4_start (nm-device.c:3168)
==7745== by 0x44EE15: act_stage3_ip4_config_start (nm-device.c:3440)
==7745== by 0x455C9F: nm_device_activate_stage3_ip4_start (nm-device.c:4657)
(cherry picked from commit c26ef29a47)
==7745== 11 (+11) bytes in 1 (+1) blocks are definitely lost in loss record 408 of 5,735
==7745== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7745== by 0x7F4A6F5: g_malloc (gmem.c:97)
==7745== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==7745== by 0x45C188: nm_dhcp_client_start_ip4 (nm-dhcp-client.c:417)
==7745== by 0x460147: client_start (nm-dhcp-manager.c:268)
==7745== by 0x460393: nm_dhcp_manager_start_ip4 (nm-dhcp-manager.c:308)
==7745== by 0x44EB16: dhcp4_start (nm-device.c:3168)
==7745== by 0x44EE15: act_stage3_ip4_config_start (nm-device.c:3440)
==7745== by 0x455C9F: nm_device_activate_stage3_ip4_start (nm-device.c:4657)
==7745== by 0x456467: nm_device_activate_stage3_ip_config_start (nm-device.c:4801)
==7745== by 0x7F44AEA: g_main_dispatch (gmain.c:3111)
==7745== by 0x7F44AEA: g_main_context_dispatch (gmain.c:3710)
==7745== by 0x7F44E87: g_main_context_iterate.isra.29 (gmain.c:3781)
(cherry picked from commit 76430f9cca)
==4203== 97 (+97) bytes in 2 (+2) blocks are definitely lost in loss record 4,586 of 5,632
==4203== at 0x4C29BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4203== by 0x7F4A6F5: g_malloc (gmem.c:97)
==4203== by 0x7F6301E: g_strdup (gstrfuncs.c:356)
==4203== by 0x47E4C8: nm_settings_connection_set_filename (nm-settings-connection.c:2228)
==4203== by 0x7CBF6EC: object_set_property (gobject.c:1415)
==4203== by 0x7CBF6EC: g_object_new_internal (gobject.c:1828)
==4203== by 0x7CC1194: g_object_new_valist (gobject.c:2034)
==4203== by 0x7CC14D0: g_object_new (gobject.c:1617)
==4203== by 0x12A08193: nm_ifcfg_connection_new (nm-ifcfg-connection.c:229)
==4203== by 0x12A0542B: update_connection (plugin.c:225)
==4203== by 0x12A0696A: add_connection (plugin.c:715)
==4203== by 0x4814BB: nm_settings_add_connection (nm-settings.c:1030)
==4203== by 0x4817DE: pk_add_cb (nm-settings.c:1136)
(cherry picked from commit 9b7c8db16a)
First, configure.ac's grep was wrong and wasn't setting DHCPCD_SUPPORTS_IPV6,
which caused dhcpcd to acquire a DHCPv6 address when NM didn't think that
was going to happen, and thus DHCP options couldn't be parsed.
Second, even if that does happen, don't just assert and quit, but set the
DHCP state to failed.
https://bugzilla.gnome.org/show_bug.cgi?id=743700
(cherry picked from commit 511a7395bf)
Singletons subscribing (and more importantly unsubscribing)
from other singletons should own a reference to them to avoid
errors during destruction.
(cherry picked from commit d4858013cf)
During dipose(), NMDefaultRouteManager unrefed all the source pointers
in its list -- thereby having dangling pointers in the list of entries.
The unrefing can cause the final destruction of the device (during
shutdown), which would again call into NMDefaultRouteManager.
Fix this by ensuring that after disposing starts, all external calls
into NMDefaultRouteManager return early.
#0 0x00007ffff4a2cc60 in g_logv (log_domain=0x535b51 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd530) at gmessages.c:1046
#1 0x00007ffff4a2ce9f in g_log (log_domain=log_domain@entry=0x535b51 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x528f68 "file %s: line %d (%s): should not be reached") at gmessages.c:1079
#2 0x000000000049b83b in _ipx_update_default_route (vtable=vtable@entry=0x7a49c0 <vtable_ip6>, self=0x7d1350 [NMDefaultRouteManager], source=source@entry=0x8b64e0) at nm-default-route-manager.c:659
#3 0x000000000049c652 in nm_default_route_manager_ip6_update_default_route (self=<optimized out>, source=source@entry=0x8b64e0) at nm-default-route-manager.c:819
#4 0x00000000004526a8 in _cleanup_generic_post (self=self@entry=0x8b64e0, deconfigure=deconfigure@entry=0) at devices/nm-device.c:7235
#5 0x0000000000452bc0 in dispose (object=0x8b64e0) at devices/nm-device.c:8324
#6 0x00007ffff4d29cbc in g_object_unref (_object=0x8b64e0) at gobject.c:3133
#7 0x0000000000499091 in _entry_free (entry=0x8bf140) at nm-default-route-manager.c:187
#8 0x00007ffff49fa82b in g_ptr_array_foreach (array=0x81d220, func=0x499080 <_entry_free>, user_data=0x0) at garray.c:1502
#9 0x00007ffff49fa8c0 in ptr_array_free (array=0x81d220, flags=FREE_SEGMENT) at garray.c:1088
#10 0x00007ffff49fa939 in g_ptr_array_free (array=<optimized out>, free_segment=free_segment@entry=1) at garray.c:1075
#11 0x000000000049abcf in dispose (object=0x7d1350 [NMDefaultRouteManager]) at nm-default-route-manager.c:1357
#12 0x00007ffff4d29cbc in g_object_unref (_object=0x7d1350) at gobject.c:3133
#13 0x00007ffff7deb507 in _dl_fini () at dl-fini.c:252
#14 0x00007ffff4658382 in __run_exit_handlers (status=status@entry=0, listp=0x7ffff49d66a0 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#15 0x00007ffff46583d5 in __GI_exit (status=status@entry=0) at exit.c:104
#16 0x0000000000432fd6 in main (argc=1, argv=0x7fffffffdeb8) at main.c:473
(cherry picked from commit 87517714f1)
Tests with assert-logging would never overwrite the logging level,
even if no-expect-message was set. Allow resetting the logging level
if no-expect-message is mixed with explicitly setting up logging.
NMTST_DEBUG='log-level=DEBUG,log-domains=ALL,no-expect-message' make check -C src/tests/config/
(cherry picked from commit 5e74891b58)
NMDevice rechecks available connections when the device moves to the
DISCONNECTED state, but connections are not available if the modem is
PIN locked at that time. Available connections were never re-checked
when the modem was then unlocked while in the DISCONNECTED state.
(cherry picked from commit f3b16fffbd)
The manager wrote the user state to the state file in /var with
the key "WiMAXEnabled", but it was read from the state file as
"WimaxEnabled". Clearly that's not going to work.
(cherry picked from commit b03a4c3f0a)
valgrind complains (rightly):
==7702== 15 bytes in 2 blocks are definitely lost in loss record 411 of 6,278
==7702== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7702== by 0x8151E6E: g_malloc (gmem.c:104)
==7702== by 0x816972E: g_strdup (gstrfuncs.c:364)
==7702== by 0x1D6671: nm_properties_changed_signal_add_property (nm-properties-changed-signal.c:235)
==7702== by 0x1AF2D5: nm_dbus_manager_register_exported_type (nm-dbus-manager.c:867)
==7702== by 0x7EE0D3D: g_type_class_ref (gtype.c:2220)
==7702== by 0x7EC9A78: g_object_new_valist (gobject.c:1928)
==7702== by 0x7EC9C10: g_object_new (gobject.c:1559)
==7702== by 0x14A5FC: new_link (nm-device-bridge.c:482)
==7702== by 0x1CF8FD: platform_link_cb (nm-manager.c:2154)
==7702== by 0x988FD8B: ffi_call_unix64 (unix64.S:76)
==7702== by 0x988F6BB: ffi_call (ffi64.c:522)
(cherry picked from commit 8396c58167)
Routing table entries for a device get flushed when the device is
deactivated, but rules table entries don't, so we have to flush them
by hand.
(cherry picked from commit 8de1bec803)
During queued_ip_config_change(), we eventually call update_ip_config()
and ip4_config_merge_and_apply(). These functions read the IP configuration
from platform and setup the private ip4_config instance.
Trigger this initialization after constructing the device to setup
the IP configuration.
Before, for unmanaged devices we would not call ip4_config_merge_and_apply()
until the first platform change event.
Note that in the worst case we do some unnecessary work due to this,
because queued_ip_config_change() must already be robust to be called
at any time.
(cherry picked from commit ddac52a61e)
Since 0c136c1e2, we also track the default route for devices
without active-connection (unmanaged). They must not be returned
as best_config() or as best_device(), because the caller don't
expect unmanaged devices here.
This also gets closer to the original behavior of get_best_device()
before merging default-route-manager in d4417e3460
where we also would ignore devices depending on the state.
This fixes an assertion when having an interface unmanaged
and activating it externally:
#0 0x00007ffff6806187 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007ffff6807dea in __GI_abort () at abort.c:89
#2 0x00007ffff6c0aec5 in g_assertion_message (domain=domain@entry=0x5332d5 "NetworkManager", file=file@entry=0x539460 "nm-default-route-manager.c", line=line@entry=1056, func=func@entry=0x539920 <__FUNCTION__.28934> "_ipx_get_best_config", message=message@entry=0x8c9cb0 "assertion failed: (req)") at gtestutils.c:2356
#3 0x00007ffff6c0af5a in g_assertion_message_expr (domain=domain@entry=0x5332d5 "NetworkManager", file=file@entry=0x539460 "nm-default-route-manager.c", line=line@entry=1056, func=func@entry=0x539920 <__FUNCTION__.28934> "_ipx_get_best_config", expr=expr@entry=0x53132f "req") at gtestutils.c:2371
#4 0x000000000049a196 in _ipx_get_best_config (self=<optimized out>, ignore_never_default=ignore_never_default@entry=1, out_ip_iface=out_ip_iface@entry=0x7fffffffd310, out_ac=out_ac@entry=0x0, out_device=0x0, out_vpn=0x7fffffffd318, vtable=0x7a0a00 <vtable_ip4>, vtable=0x7a0a00 <vtable_ip4>) at nm-default-route-manager.c:1056
#5 0x000000000049a3f6 in nm_default_route_manager_ip4_get_best_config (self=<optimized out>, ignore_never_default=ignore_never_default@entry=1, out_ip_iface=out_ip_iface@entry=0x7fffffffd310, out_ac=out_ac@entry=0x0, out_device=out_device@entry=0x0, out_vpn=out_vpn@entry=0x7fffffffd318) at nm-default-route-manager.c:1079
#6 0x00000000004b7518 in update_ip4_dns (self=0x7ecac0 [NMPolicy], out_vpn=0x7fffffffd318, out_device=0x0, out_ac=0x0, out_ip_iface=0x7fffffffd310, ignore_never_default=1) at nm-policy.c:390
#7 0x00000000004b7518 in update_ip4_dns (dns_mgr=0x8623a0 [NMDnsManager], policy=0x7ecac0 [NMPolicy]) at nm-policy.c:406
#8 0x00000000004b99d5 in device_ip4_config_changed (device=0x8844b0 [NMDeviceEthernet], new_config=0x908aa0 [NMIP4Config], old_config=0x908aa0 [NMIP4Config], user_data=0x7ecac0) at nm-policy.c:1260
#9 0x000000368f405d60 in ffi_call_unix64 () at /lib64/libffi.so.6
#10 0x000000368f4057d1 in ffi_call () at /lib64/libffi.so.6
#11 0x00007ffff6ee5b8c in g_cclosure_marshal_generic_va (closure=0x886a40, return_value=0x0, instance=0x8844b0, args_list=<optimized out>, marshal_data=0x0, n_params=2, param_types=0x87d3a0) at gclosure.c:1541
#12 0x00007ffff6ee5144 in _g_closure_invoke_va (closure=closure@entry=0x886a40, return_value=return_value@entry=0x0, instance=instance@entry=0x8844b0, args=args@entry=0x7fffffffd810, n_params=<optimized out>, param_types=0x87d3a0) at gclosure.c:831
#13 0x00007ffff6eff900 in g_signal_emit_valist (instance=0x8844b0, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffd810) at gsignal.c:3201
#14 0x00007ffff6f0014f in g_signal_emit (instance=instance@entry=0x8844b0, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3348
#15 0x000000000044a1f4 in nm_device_set_ip4_config (self=self@entry=0x8844b0 [NMDeviceEthernet], new_config=new_config@entry=0x9089a0 [NMIP4Config], default_route_metric=default_route_metric@entry=100, commit=commit@entry=0, reason=reason@entry=0x0) at devices/nm-device.c:5866
#16 0x000000000044a5af in ip4_config_merge_and_apply (self=self@entry=0x8844b0 [NMDeviceEthernet], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at devices/nm-device.c:3037
#17 0x000000000044b4fd in update_ip_config (self=self@entry=0x8844b0 [NMDeviceEthernet], initial=initial@entry=0) at devices/nm-device.c:6617
#18 0x000000000044bc39 in queued_ip_config_change (user_data=<optimized out>) at devices/nm-device.c:6688
#19 0x00007ffff6be4e1b in g_main_context_dispatch (context=0x7ba3a0) at gmain.c:3122
#20 0x00007ffff6be4e1b in g_main_context_dispatch (context=context@entry=0x7ba3a0) at gmain.c:3737
#21 0x00007ffff6be51b0 in g_main_context_iterate (context=0x7ba3a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
#22 0x00007ffff6be54d2 in g_main_loop_run (loop=0x7ba460) at gmain.c:4002
#23 0x000000000043291d in main (argc=1, argv=0x7fffffffdef8) at main.c:442
Fixes: da708059da
(cherry picked from commit aadef137b4)
Since 03a5a85d, NMDeviceTeam was trying to use priv->teamd_pid to
decide whether a teamd_dbus_vanished() call indicated "teamd hasn't
been started yet" or "teamd was previously started and has now
exited". But this resulted in a race condition, where at startup, a
device could call g_dbus_watch_name(), then launch teamd (causing
teamd_pid to get set), and then have gdbus report that teamd hasn't
been started yet before the newly-launched teamd managed to grab the
bus name. Since teamd_pid would already be set when
teamd_dbus_vanished() was called, it would decide that this meant
"teamd was previously started and has now exited", so it would call
teamd_cleanup(), killing the just-started teamd process.
Fix this by having teamd_dbus_vanished() check priv->tdc instead,
which doesn't get set until after the first teamd_dbus_appeared()
call.
(cherry picked from commit f0e74622cc)
We forgot to include the BRIDGE, so that bridge
devices got a default priority (route-metric) of 950
Add it between VLAN and MODEM type.
Also return a different metric for UNKNOWN
device types, but these priorities are not
actually expected.
(cherry picked from commit 8dce71be74)
Use descriptive string value as preferred bond mode representation.
Numeric modes still verify but with NM_SETTING_VERIFY_NORMALIZABLE,
suggesting a normalization action.
https://bugzilla.redhat.com/show_bug.cgi?id=1171009
(cherry picked from commit 3d1b6bd4d8)
