Program received signal SIGSEGV, Segmentation fault.
0x000000000041b3e5 in nmt_page_dsl_constructed (object=0x7fffec0228c0 [NmtPageDsl]) at nmt-page-dsl.c:109
109 priv->ethernet_page = nmt_page_ethernet_new (conn, nmt_editor_page_device_get_device_entry (NMT_EDITOR_PAGE_DEVICE (dsl)));
Missing separate debuginfos, use: debuginfo-install libffi-3.0.10-3.fc18.x86_64 newt-0.52.15-1.fc19.x86_64
(gdb) bt
#0 0x000000000041b3e5 in nmt_page_dsl_constructed (object=0x7fffec0228c0 [NmtPageDsl]) at nmt-page-dsl.c:109
#1 0x0000003e9ac161e3 in g_object_newv (object_type=1, object_type@entry=16203872, n_parameters=n_parameters@entry=2, parameters=parameters@entry=0xf74350)
at gobject.c:1741
#2 0x0000003e9ac16560 in g_object_new_valist (object_type=object_type@entry=16203872, first_property_name=first_property_name@entry=0x42e524 "connection",
var_args=var_args@entry=0x7fffffffcef8) at gobject.c:1830
#3 0x0000003e9ac16894 in g_object_new (object_type=16203872, first_property_name=first_property_name@entry=0x42e524 "connection") at gobject.c:1545
#4 0x000000000041b504 in nmt_page_dsl_new (conn=<optimized out>, deventry=deventry@entry=0x974690 [NmtDeviceEntry]) at nmt-page-dsl.c:47
#5 0x000000000041808e in nmt_editor_constructed (object=<optimized out>) at nmt-editor.c:355
#6 0x0000003e9ac161e3 in g_object_newv (object_type=1, object_type@entry=16174256, n_parameters=n_parameters@entry=4, parameters=parameters@entry=0xf6cec0)
at gobject.c:1741
...
(gdb) p priv
$1 = (NmtPageDslPrivate *) 0x0
(cherry picked from commit cf0a87c5e4)
NMRemoteSettings queues a bunch of async NMRemoteConnection creations,
but wasn't doing anything to ensure that it was still alive when they
completed. Pointed out by Cosimo Cecchi.
https://bugzilla.gnome.org/show_bug.cgi?id=742138
In Python 3, dbus.ByteArray() must be created using a byte string,
while strings obtained via DBUS are unicode strings.
This was wrong in WifiAp.__get_props() which broke the test
test_wifi_ap_added_removed().
File "/usr/lib/python3.3/site-packages/dbus/service.py", line 707, in _message_cb
retval = candidate_method(self, *args, **keywords)
File "./NetworkManager/tools/test-networkmanager-service.py", line 102, in GetAll
return self._get_dbus_properties(iface)
File "./NetworkManager/tools/test-networkmanager-service.py", line 96, in _get_dbus_properties
return self.__dbus_ifaces[iface]()
File "./NetworkManager/tools/test-networkmanager-service.py", line 315, in __get_props
props[PP_SSID] = dbus.ByteArray(self.ssid)
TypeError: string argument without an encoding
https://bugzilla.gnome.org/show_bug.cgi?id=739448
(cherry picked from commit c569fc23bf)
When compiling NetworkManager with --enable-gtk-doc outside the
source tree, the generated documents are slightly different from
those generated in tree. This patch fixes that missed COPYING file in
$(top_builddir) and adds $(top_builddir)/libnm-util to DOC_SOURCE_DIR.
https://bugzilla.gnome.org/show_bug.cgi?id=742139
Signed-off-by: You-Sheng Yang <vicamo@gmail.com>
(cherry picked from commit 738649c1d5)
Otherwise it does not register the "options" property and an assertion fails
when the user prints connection that has DHCPv6 options:
$ LIBNM_GLIB_DEBUG=properties-changed nmcli c show yolo
...
libnm-Message: Property 'options' unhandled.
...
(process:13522): libnm-CRITICAL **: nm_dhcp_config_get_options: assertion 'NM_IS_DHCP_CONFIG (config)' failed
(cherry picked from commit 4615d74de0)
The following must not be allowed:
$ nmcli connection modify apath /org/freedesktop/NetworkManager/ActiveConnection/0
(cherry picked from commit 3cbce6994a)
Previously we would only complete connections given by ID.
The following would work:
$ nmcli connection modify id <ID> <TAB>
$ nmcli connection modify <ID> <TAB>
$ nmcli connection modify uuid <UUID> <TAB>
but the following would not work:
$ nmcli connection modify <UUID> <TAB>
(cherry picked from commit 5ef233936a)
If a device assumes a connection without activating a user-requested or
NM-requested connection, then disable_ipv6 is not touched. When the device
is deactivated, it still isn't touched even though userspace IPv6LL
is enabled. This could lead to an user-requested activation with
IPv6 configuration, but disable_ipv6=1.
Whenever userspace IPv6LL is turned on, we should also set disable_ipv6=0
to ensure IPv6 can function. Userspace IPv6LL will ensure that the
interface does not have an address until the user/connection requests
it, which was the only reason that NM touched disable_ipv6 anyway.
fixes:NetworkManager_Test203_testcase_286589
fixes:NetworkManager_Test204_testcase_286590
When userspace IPv6LL capability is compiled into NetworkManager,
during deactivation NM will toggle userspace IPv6LL in some cases.
This causes link change events in the platform, which show up
in nm-device.c::device_link_changed().
When an EXTERNAL_DOWN interface was activated, the EXTERNAL_DOWN
flag was never cleared even if the device was set IFF_UP or if
a connection was activated via D-Bus (which explicitly sets the
device up).
Second, the device_link_changed() code changed device state
whether or not IFF_UP had actually changed, it simply looked at
the current value.
Together, this caused the first activation of an EXTERNAL_DOWN
device to succeed, but the EXTERNAL_DOWN flag was never cleared
even though the activation set the device IFF_UP. When a second
activation request came in, the device was moved to DISCONNECTED
state and IPv6LL genmode was reset, causing device_link_changed()
to run. Since the device had EXTERNAL_DOWN and IFF_UP were still
set, nm_device_set_unmanaged_flag() code was triggered to clear
EXTERNAL_DOWN, which resulted in a state transition to UNAVAILABLE
with a reason of CONNECTION_ASSUMED. This caused the second
activation request to fail because UNAVAILABLE devices cannot
activate connections by definition.
The fix has three parts:
1) Only change EXTERNAL_DOWN if IFF_UP actually changes, to prevent
spurious changes when something other than IFF_UP changes
2) Only clear EXTERNAL_DOWN when IFF_UP changes while the device
is UNMANAGED, since any state higher than UNMANAGED implies that
either an activation request was received (and thus the device
should be managed) or IFF_UP was set
3) Clear EXTERNAL_DOWN (without triggering state changes) when
any state higher than UNAVAILABLE is entered, since this implies
that a connection is activating or the device is no longer
IFF_UP
fixes:NetworkManager_Test108_testcase_303655
https://bugzilla.gnome.org/show_bug.cgi?id=741742
(cherry picked from commit 711a05965b)
On ppc64, `nm` reports the exported symbols as 'D' instead of 'T'.
This caused `make check` to fail.
"D" The symbol is in the initialized data section.
"T" The symbol is in the text (code) section.
(cherry picked from commit 4838543053)
For IPv4 addresses, the binary representation is in network-order,
contrary to host-order. It's better to choose addresses for testing
that are differently on big and little endian systems.
(cherry picked from commit 1bef194302)
s390 does not enable several device plugins, but ADSL and Wi-Fi
plugins are still build. They must be excluded in the spec file,
otherwise rpmbuild fails.
This partly reverts commit 1f631cd08d.
Checking for unpackaged file(s): /usr/lib/rpm/check-files /builddir/build/BUILDROOT/NetworkManager-1.1.0-11242.9709d009d5.el7.s390x
RPM build errors:
error: Installed (but unpackaged) file(s) found:
/usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
/usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Installed (but unpackaged) file(s) found:
/usr/lib64/NetworkManager/libnm-device-plugin-adsl.so
/usr/lib64/NetworkManager/libnm-device-plugin-wifi.so
Child returncode was: 1
(cherry picked from commit 2fc37ce895)
On s390/s390x we would disable hardware plugins, especially %{with_bluetooth} and
%{with_wwan}. Depending on that we would set 'BuildRequires: ModemManager-glib-devel'.
This was not corresponding to the '--with-modem-manager-1' configure
option, hence we did not have ModemManager-glib-devel, but
'--with-modem-manager-1=yes'
(cherry picked from commit 6f343b866e)
In the 'configure.ac' script we already detect the git commit id
for the current source version. When creating a tarball, it is also
included inside the generated 'configure' script.
Add the commit id as a static string to nm-utils.c. That way, having
a build of libnm.so or NetworkManager, you can quickly find the
corresponding git commit:
strings src/NetworkManager | grep NM_GIT_SHA
Note that this only works after a new `autogen.sh` run. Only rebuilding
is not enough. Hence, you must rebuild all to ensure that the correct
commit id is embedded.
https://bugzilla.gnome.org/show_bug.cgi?id=741651
(cherry picked from commit 924f7b2064)
Previously, we would only pass one argument @loc to _nm_log()
which was set to G_STRLOC.
That has the disadvantage, that for every logging line the binary
contains an individual string __FILE__:__LINE__.
By splitting up @loc into @file and @line, we reduce the number
of strings in the NetworkManager binary by about 50k.
https://bugzilla.gnome.org/show_bug.cgi?id=741651
(cherry picked from commit e62aa4165f)
#0 0x00007f6c3aed34e9 in g_logv (log_domain=0x7f6c3ea7341c "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff0a33fb60) at gmessages.c:989
#1 0x00007f6c3aed363f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1025
#2 0x00007f6c3e8ead4f in nm_device_get_iface (self=0x0) at devices/nm-device.c:502
#3 0x00007f6c3e904f59 in nm_device_slave_notify_release (self=0x7f6c3fb48e60, reason=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:1618
#4 0x00007f6c3e8ed69f in nm_device_release_one_slave (self=0x7f6c3fb22670, slave=0x7f6c3fb48e60, configure=1, reason=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:968
#5 0x00007f6c3e904bf7 in slave_state_changed (slave=0x7f6c3fb48e60, slave_new_state=NM_DEVICE_STATE_UNMANAGED, slave_old_state=NM_DEVICE_STATE_ACTIVATED, reason=NM_DEVICE_STATE_REASON_REMOVED, self=0x7f6c3fb22670)
at devices/nm-device.c:1368
#6 0x00007f6c39829d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#7 0x00007f6c398296bc in ffi_call (cif=cif@entry=0x7fff0a340070, fn=0x7f6c3e9049d0 <slave_state_changed>, rvalue=0x7fff0a33ffe0, avalue=avalue@entry=0x7fff0a33ff60) at ../src/x86/ffi64.c:522
#8 0x00007f6c3b1bfad8 in g_cclosure_marshal_generic (closure=0x7f6c3fb5c8c0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#9 0x00007f6c3b1bf298 in g_closure_invoke (closure=0x7f6c3fb5c8c0, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fff0a340270, invocation_hint=invocation_hint@entry=0x7fff0a340210)
at gclosure.c:777
#10 0x00007f6c3b1d135d in signal_emit_unlocked_R (node=node@entry=0x7f6c3faf5d10, detail=detail@entry=0, instance=instance@entry=0x7f6c3fb48e60, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff0a340270) at gsignal.c:3586
#11 0x00007f6c3b1d90f2 in g_signal_emit_valist (instance=instance@entry=0x7f6c3fb48e60, signal_id=signal_id@entry=64, detail=detail@entry=0, var_args=var_args@entry=0x7fff0a3404a8) at gsignal.c:3330
#12 0x00007f6c3b1d98f8 in g_signal_emit_by_name (instance=0x7f6c3fb48e60, detailed_signal=0x7f6c3ea70f83 "state-changed") at gsignal.c:3426
#13 0x00007f6c3e8f894f in _set_state_full (self=0x7f6c3fb48e60, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED, quitting=0) at devices/nm-device.c:7486
#14 0x00007f6c3e8f0706 in nm_device_state_changed (self=0x7f6c3fb48e60, state=NM_DEVICE_STATE_UNMANAGED, reason=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:7623
#15 0x00007f6c3e8f808b in nm_device_set_unmanaged (self=0x7f6c3fb48e60, flag=NM_UNMANAGED_INTERNAL, unmanaged=1, reason=NM_DEVICE_STATE_REASON_REMOVED) at devices/nm-device.c:6652
#16 0x00007f6c3e9943d0 in remove_device (manager=0x7f6c3fb20150, device=0x7f6c3fb48e60, quitting=0, allow_unmanage=1) at nm-manager.c:752
#17 0x00007f6c3e995c29 in platform_link_cb (platform=0x7f6c3fa7a870, ifindex=73, plink=0x7fff0a341260, change_type=NM_PLATFORM_SIGNAL_REMOVED, reason=NM_PLATFORM_REASON_EXTERNAL, user_data=0x7f6c3fb20150) at nm-manager.c:2182
#18 0x00007f6c39829d8c in ffi_call_unix64 () at ../src/x86/unix64.S:76
#19 0x00007f6c398296bc in ffi_call (cif=cif@entry=0x7fff0a340bc0, fn=0x7f6c3e995b60 <platform_link_cb>, rvalue=0x7fff0a340b30, avalue=avalue@entry=0x7fff0a340ab0) at ../src/x86/ffi64.c:522
#20 0x00007f6c3b1bfad8 in g_cclosure_marshal_generic (closure=0x7f6c3fb14cf0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1454
#21 0x00007f6c3b1bf298 in g_closure_invoke (closure=0x7f6c3fb14cf0, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7fff0a340dc0, invocation_hint=invocation_hint@entry=0x7fff0a340d60)
at gclosure.c:777
#22 0x00007f6c3b1d135d in signal_emit_unlocked_R (node=node@entry=0x7f6c3fa76f00, detail=detail@entry=0, instance=instance@entry=0x7f6c3fa7a870, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fff0a340dc0) at gsignal.c:3586
#23 0x00007f6c3b1d90f2 in g_signal_emit_valist (instance=instance@entry=0x7f6c3fa7a870, signal_id=signal_id@entry=2, detail=detail@entry=0, var_args=var_args@entry=0x7fff0a341018) at gsignal.c:3330
#24 0x00007f6c3b1d98f8 in g_signal_emit_by_name (instance=0x7f6c3fa7a870, detailed_signal=0x7f6c3ea5f1fa "link-changed") at gsignal.c:3426
#25 0x00007f6c3e92412a in announce_object (platform=0x7f6c3fa7a870, object=0x7f6c3fbb6fd0, change_type=NM_PLATFORM_SIGNAL_REMOVED, reason=NM_PLATFORM_REASON_EXTERNAL) at platform/nm-linux-platform.c:1625
#26 0x00007f6c3e92b0f9 in event_notification (msg=0x7f6c3fa946f0, user_data=0x7f6c3fa7a870) at platform/nm-linux-platform.c:1986
#27 0x00007f6c3c35812f in nl_cb_call (msg=<optimized out>, type=<optimized out>, cb=<optimized out>) at ../include/netlink-private/netlink.h:141
#28 recvmsgs (cb=0x7f6c3fa7a620, sk=0x7f6c3fa7a710) at nl.c:952
#29 nl_recvmsgs_report (sk=0x7f6c3fa7a710, cb=0x7f6c3fa7a620) at nl.c:1003
#30 0x00007f6c3c3584f9 in nl_recvmsgs (sk=<optimized out>, cb=<optimized out>) at nl.c:1027
#31 0x00007f6c3e929dca in event_handler (channel=0x7f6c3fa78810, io_condition=G_IO_IN, user_data=0x7f6c3fa7a870) at platform/nm-linux-platform.c:4127
#32 0x00007f6c3aecc2a6 in g_main_dispatch (context=0x7f6c3fa68490) at gmain.c:3066
#33 g_main_context_dispatch (context=context@entry=0x7f6c3fa68490) at gmain.c:3642
#34 0x00007f6c3aecc628 in g_main_context_iterate (context=0x7f6c3fa68490, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#35 0x00007f6c3aecca3a in g_main_loop_run (loop=0x7f6c3fa68550) at gmain.c:3907
#36 0x00007f6c3e8e9fff in main (argc=1, argv=0x7fff0a341c88) at main.c:483
https://bugzilla.gnome.org/show_bug.cgi?id=741651
(cherry picked from commit 3ea9169c81)
If NM IPv6LL wasn't enabled then there is no need to bounce disable_ipv6
to tell the kernel to re-enable kernel IPv6LL, because kernel IPv6LL
is already enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=740702
(cherry picked from commit 27c1a73ae0)
If we have NM running, adding a route with metric 20 might conflict
and cause NM to remove the route.
Choose a different (higher) metric that is less likely to cause a
conflict.
(cherry picked from commit b169f222bf)
We want to export the IP configuration of interfaces when they have some, but
the kernel doesn't care if they are IFF_UP or not. Neither should NetworkManager,
so don't force devices IFF_UP just because we're assuming their IP config.
Externally created software devices would be managed/assumed immediately
upon creation, which includes setting them IFF_UP and possibly turning
on NM-managed IPv6LL.
With this commit, expected behavior for external software devices is:
1) created: unmanaged state, no further action
2) IP address added but !IFF_UP: connection assumed, but device is not set IFF_UP
3) slave attached but !IFF_UP: connection assumed, but master is not set IFF_UP
3) set IFF_UP: connection assumed (if any), if not -> DISCONNECTED
This branch ensures that external software devices are not set IFF_UP
by NetworkManager when they are discovered. It additionally ensures that
they are not set IFF_UP during connection assumption. They may be set
IFF_UP later through specific user action.
https://bugzilla.gnome.org/show_bug.cgi?id=725647https://bugzilla.redhat.com/show_bug.cgi?id=1030947
INTERNAL is actually a nop right now because the only thing that
sets it is suspend/resume, which is covered by the preceding
manager_sleeping() call. But we may use this more in the future,
so add it while we're here.
Devices that are unmanaged because their parent is unmanaged
probably shouldn't assume connections either, per 4e105c50.
Error: NEGATIVE_RETURNS (CWE-394): [#def8]
NetworkManager-1.1.0/src/tests/test-general-with-expect.c:139: negative_return_fn: Function "fork()" returns a negative number.
NetworkManager-1.1.0/src/tests/test-general-with-expect.c:139: var_assign: Assigning: signed variable "pgid" = "fork".
NetworkManager-1.1.0/src/tests/test-general-with-expect.c:163: negative_returns: "pgid" is passed to a parameter that cannot be negative.
Error: NEGATIVE_RETURNS (CWE-394): [#def9]
NetworkManager-1.1.0/src/tests/test-general-with-expect.c:302: negative_returns: A negative constant "-1" is passed as an argument to a parameter that cannot be negative.
NetworkManager-1.1.0/src/tests/test-general-with-expect.c:81:2: neg_sink_parm_call: Passing "sig" to "nm_utils_kill_child_async", which cannot accept a negative number.
NetworkManager-1.1.0/src/NetworkManagerUtils.c:448:2: neg_sink_parm_call: Passing "sig" to "kill", which cannot accept a negative number.
(cherry picked from commit 5252287209)
Error: INFINITE_LOOP (CWE-835): [#def17]
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:93: loop_top: Top of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:94: loop_bottom: Bottom of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:93: loop_condition: If "notified" is initially true then it will remain true.
Error: INFINITE_LOOP (CWE-835): [#def18]
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:191: loop_top: Top of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:192: loop_bottom: Bottom of the loop.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:191: loop_condition: If "result & NOTIFY_MASK" is initially true then it will remain true.
NetworkManager-0.9.11.0/libnm/tests/test-nm-client.c:191: loop_condition: If "result & SIGNAL_MASK" is initially true then it will remain true.
(cherry picked from commit ce6323d4df)
Error: CHECKED_RETURN (CWE-252): [#def21]
NetworkManager-0.9.11.0/src/settings/plugins/ifcfg-rh/plugin.c:676: check_return: Calling "stat("/etc/hostname", &file_stat)" without checking return value. This library function may fail and return an error code. [Note: The source code implementation of the function has been overridden by a builtin model.]
(cherry picked from commit 405d198e7c)
Error: CHECKED_RETURN (CWE-252): [#def20]
NetworkManager-0.9.11.0/src/devices/nm-device.c:5037: check_return: Calling "g_spawn_async" without checking return value (as is done elsewhere 12 out of 13 times).
(cherry picked from commit 4da19b8981)
Error: CHECKED_RETURN (CWE-252): [#def12]
NetworkManager-0.9.11.0/libnm-core/tests/test-general.c:348: check_return: Calling "nm_setting_verify" without checking return value (as is done elsewhere 37 out of 45 times).
...
(cherry picked from commit 6603e7ffde)
Error: RESOURCE_LEAK (CWE-772): [#def10]
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:225: alloc_fn: Storage is returned from allocation function "priority_map_new_from_str".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:154:4: alloc_fn: Storage is returned from allocation function "g_malloc0".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:154:4: var_assign: Assigning: "p" = "g_malloc0(8UL)".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:164:2: return_alloc: Returning allocated memory "p".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:225: var_assign: Assigning: "item" = storage returned from "priority_map_new_from_str(map, str)".
NetworkManager-0.9.11.0/libnm-core/nm-setting-vlan.c:226: leaked_storage: Variable "item" going out of scope leaks the storage it points to.
Error: RESOURCE_LEAK (CWE-772): [#def11]
NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2056: alloc_fn: Storage is returned from allocation function "crypto_make_des_aes_key".
NetworkManager-0.9.11.0/libnm-core/crypto.c:405:2: alloc_fn: Storage is returned from allocation function "g_malloc0".
NetworkManager-0.9.11.0/libnm-core/crypto.c:405:2: var_assign: Assigning: "key" = "g_malloc0(digest_len + 1U)".
NetworkManager-0.9.11.0/libnm-core/crypto.c:407:2: noescape: Resource "key" is not freed or pointed-to in function "crypto_md5_hash".
NetworkManager-0.9.11.0/libnm-core/crypto.c:769:24: noescape: "crypto_md5_hash(char const *, gssize, char const *, gssize, char *, gsize)" does not free or save its pointer parameter "buffer".
NetworkManager-0.9.11.0/libnm-core/crypto.c:415:2: return_alloc: Returning allocated memory "key".
NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2056: var_assign: Assigning: "key" = storage returned from "crypto_make_des_aes_key("DES-EDE3-CBC", &salt[0], salt_len, in_password, &key_len, NULL)".
NetworkManager-0.9.11.0/libnm-core/nm-utils.c:2057: leaked_storage: Variable "key" going out of scope leaks the storage it points to.
(cherry picked from commit afb0e2c53c)
Error: DEADCODE (CWE-561): [#def3]
NetworkManager-0.9.11.0/clients/cli/utils.c:488: cond_notnull: Condition "input", taking true branch. Now the value of "input" is not "NULL".
NetworkManager-0.9.11.0/clients/cli/utils.c:517: notnull: At condition "input", the value of "input" cannot be "NULL".
NetworkManager-0.9.11.0/clients/cli/utils.c:517: dead_error_condition: The condition "input" must be true.
NetworkManager-0.9.11.0/clients/cli/utils.c:517: dead_error_line: Execution cannot reach the expression """" inside this statement: "g_set_error(error, 1U, 0, d...".
(cherry picked from commit bcd5b2cdc1)
