fwupd crashed with SIGSEGV in fu_plugin_dell_match_dock_component()

Bug #1726367 reported by Tim Whitbeck
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
fwupd (Ubuntu)
Fix Released
Medium
Unassigned
Artful
Incomplete
Undecided
Unassigned
Bionic
Fix Released
Medium
Unassigned

Bug Description

Dell Precision 5520 using USB-C single-cable dock K17A.

ProblemType: Crash
DistroRelease: Ubuntu 17.10
Package: fwupd 0.9.7-2
ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
Uname: Linux 4.13.0-16-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.7-0ubuntu3
Architecture: amd64
CrashCounter: 1
Date: Mon Oct 23 07:55:49 2017
ExecutablePath: /usr/lib/fwupd/fwupd
InstallationDate: Installed on 2017-10-20 (2 days ago)
InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018)
ProcCmdline: /usr/lib/fwupd/fwupd
ProcEnviron:
 LANG=en_US.UTF-8
 PATH=(custom, no user)
SegvAnalysis:
 Segfault happened at: 0x7f10f3106c5a <__strcmp_sse2_unaligned+26>: movdqu (%rdi),%xmm1
 PC (0x7f10f3106c5a) ok
 source "(%rdi)" (0x00000006) not located in a known VMA region (needed readable region)!
 destination "%xmm1" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: fwupd
StacktraceTop:
 fu_plugin_dell_device_added_cb () from /usr/lib/x86_64-linux-gnu/fwupd-plugins-2/libfu_plugin_dell.so
 g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
 ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
 g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
 g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
Title: fwupd crashed with SIGSEGV in fu_plugin_dell_device_added_cb()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

Revision history for this message
Tim Whitbeck (twhitbeck) wrote :
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceTop:
 fu_plugin_dell_match_dock_component (name_out=<synthetic pointer>, guid_out=0x7ffdd4b4cee0, query_str=0x6 <error: Cannot access memory at address 0x6>) at ../plugins/dell/fu-plugin-dell.c:134
 fu_plugin_dell_device_added_cb (ctx=<optimized out>, device=0x56246b6e4fa0, plugin=0x56246b6cd500) at ../plugins/dell/fu-plugin-dell.c:337
 g_closure_invoke (closure=0x56246b6b9ea0, return_value=0x0, n_param_values=2, param_values=0x7ffdd4b4d200, invocation_hint=0x7ffdd4b4d180) at ../../../../gobject/gclosure.c:804
 signal_emit_unlocked_R (node=node@entry=0x56246b5a3cd0, detail=detail@entry=0, instance=instance@entry=0x56246b57e050, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffdd4b4d200) at ../../../../gobject/gsignal.c:3635
 g_signal_emit_valist (instance=0x56246b57e050, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffdd4b4d3d0) at ../../../../gobject/gsignal.c:3391

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceSource.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in fwupd (Ubuntu):
importance: Undecided → Medium
summary: - fwupd crashed with SIGSEGV in fu_plugin_dell_device_added_cb()
+ fwupd crashed with SIGSEGV in fu_plugin_dell_match_dock_component()
tags: removed: need-amd64-retrace
information type: Private → Public
Revision history for this message
Mario Limonciello (superm1) wrote :

Sorry, K17A dock? Do you mean TB16 dock?

Revision history for this message
Mario Limonciello (superm1) wrote :

I'm pretty sure it's a TB16 dock from looking at the traces. Can you reliably reproduce this? I have some suspicions, but would like to see verbose fwupd output to confirm it if possible.

So try to run this:

# sudo /usr/lib/fwupd/fwupd -v

And share all of the output that is found.

Changed in fwupd (Ubuntu):
status: New → Incomplete
Revision history for this message
Tim Whitbeck (twhitbeck) wrote :

It says K17A on the bottom of the dock for "Reg Model". It also reads WD15 elsewhere, which I think is the actual model. It is this unit: http://www.dell.com/en-us/shop/dell-business-dock-wd15-with-180w-adapter/apd/450-aeuo/pc-accessories

attached is the output of `sudo /usr/lib/fwupd/fwupd -v` (before I got a segmentation fault)

Revision history for this message
Mario Limonciello (superm1) wrote :

Yep that's the WD15 dock, thank you very much for confirming.
1. You've never performed a FW update on it in the past right?
2. How technically savvy are you with debian packaging? If I gave you a patch to try could you apt source the package apply it and try it?

Revision history for this message
Mario Limonciello (superm1) wrote :

The stack trace shows that it's a NULL pointer comparison of a substring, but it's not clear why that is happening. I can feed your exact data from your dock into the test suite but no segfault.

Revision history for this message
Mario Limonciello (superm1) wrote :

OK so I've got another theory.
By chance do you have UEFI capsule updates turned off in BIOS setup?

I think that this is a race condition in two BIOS requests happening at inconvenient times and the buffer getting overwritten as a result. In between parsing devices the check for whether capsule updates are turned on may cause that buffer to no longer be valid.
I can't reproduce it on the test suite because the test suite doesn't actually communicate to the BIOS so the buffer wouldn't be overwritten no matter what I did.

I'll share a patch that I believe should fix this.

Revision history for this message
Mario Limonciello (superm1) wrote :

OK, assuming my theory is right proposed fixes available here:
https://github.com/hughsie/fwupd/pull/306

(Those are probably useful either way upstream though)

Revision history for this message
Tim Whitbeck (twhitbeck) wrote :

Cool, thanks for looking into it. Yes, I could not install Ubuntu 17.10 without disabling UEFI in the BIOS.

How do I go about testing the changes?

Revision history for this message
Mario Limonciello (superm1) wrote :

@Tim,
Well that's unfortunate you had troubles with UEFI. After we can confirm this issue is fixed for you with the proposed fix, I think you should try to re-install with in UEFI mode again. UEFI mode is preferable as BIOS updates will only be distributed and installed when in UEFI mode.
What problem did you run into?

My fix is merged into both master and 0_9_X branches.

As for testing the fix, easiest way is with docker.
1. Set up a docker environment.
2. Clone upstream tree
# git clone https://github.com/hughsie/fwupd
3) Swap to 0_9_X branch.
# git checkout 0_9_X
4) Follow directions here for deb to compile into debs:
https://github.com/hughsie/fwupd/tree/master/contrib
5) Install all but the fwupd-tests deb package.
6) Try to start fwupd process.

Alternatively if you want to install all the build depends for fwupd you can do that too rather than docker to build.
# apt build-dep fwupd
# ./contrib/ci/build_and_install_debs.sh

Changed in fwupd (Ubuntu Artful):
status: New → Incomplete
Changed in fwupd (Ubuntu Bionic):
status: Incomplete → Fix Committed
Revision history for this message
Kevin Farley (kfarley) wrote :

I encountered this same error and was automagically pointed here by the bug reporting software.

Configuration: Dell Precision 7720, K17A (TB16) dock, Ubuntu 17.10 - live version, not installed. I had disabled USB security in BIOS prior to boot. Still running UEFI.

Booted a live 17.10 load from USB on the 7720 laptop. Everything was working when booting with dock plugged and all devices attached: ethernet, 2 displays, keyboard, and mouse.

When I tested hotplug, I encountered this same error.

Note that after the hotplug, both external displays and the laptop display worked correctly with extended display. Furthermore, the keyboard, mouse, and ethernet worked as well. It took a few seconds for everything to get recognized and restarted, but they did work.

Revision history for this message
Mario Limonciello (superm1) wrote :

Kevin,

You were running UEFI, but possibly have UEFI capsule updates disabled right?

The 1.0.2-1 upload was just accepted into bionic today. Would you mind testing with a live daily image that contains 1.0.2-1? It should probably be in tomorrow's daily image.

I expect that this should not reproduce in 1.0.2-1, but a confirmation would be good.

Changed in fwupd (Ubuntu Bionic):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.