linux-kernel - hid-related 5.2-rc1 boot hang

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 May 2019 09:43:59 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Jiri Kosina <jkosina@...e.cz>, Hans de Goede <hdegoede@...hat.com>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: hid-related 5.2-rc1 boot hang

I have a system that works fine on 5.1.  When updating to 5.2-rc1, it
hangs at boot waiting on an instance of systemd-udevd.  The kernel
backtrace (https://photos.app.goo.gl/EV8rf7FofWouvdeE8) looks like it's
doing an finit_module() that dives into the hid code and is waiting on a
request_module().

This hang only occurs if I have a particular USB device inserted:

> Bus 001 Device 007: ID 046d:c52b Logitech, Inc. Unifying Receiver

Bisecting the issue points at this (unlikely to be the culprit) commit:

> [161f62cd07fde123fd52bf6d5b6fd6513cca968e] HID: macally: Add support for Macally ikey keyboard

This bisect result is probably just a bisect artifact.  The first real,
bad commit is a merge commit: 63b6f0b827d.  This commit merges a bunch
of stuff, but includes changes to the hid request_module() code and to
the logitech-hidpp which is the driver for the above device.

I also have a picture of the hang which includes __request_module()
dumping out the string it is passed:

	https://photos.app.goo.gl/tUETiCBZHJfKqWPu8

This is easy enough to work around, and the system works fine if I just
unplug the Logitech device and plug it in after boot.  But, it would be
nice to figure out what's going wrong.  I guess it could easily be some
interaction between systemd, the driver and the request_module() ordering.