linux-kernel - regression (bisected): "modprobe parport

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]

Message-ID: <20190313064557.GA14531@unicorn.suse.cz>
Date:   Wed, 13 Mar 2019 07:45:57 +0100
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc:     linux-kernel@...r.kernel.org
Subject: regression (bisected): "modprobe parport_pc" hangs in current
 mainline

Hello,

I encountered a regression in current (post-5.0) mainline kernel which I
bisected to commit 1aec4211204d ("parport: daisy: use new parport device
model"). Running "modprobe parport_pc" hangs up:

tweed:~ # ps ax | grep modprobe
 1206 pts/0    D+     0:00 modprobe parport_pc
 1209 ?        S      0:00 /sbin/modprobe -q -- parport_lowlevel
 1211 pts/1    S+     0:00 grep modprobe
tweed:~ # cat /proc/1206/stack 
[<0>] call_usermodehelper_exec+0xc7/0x140
[<0>] __request_module+0x1a1/0x430
[<0>] __parport_register_driver+0x142/0x150 [parport]
[<0>] parport_bus_init+0x1d/0x30 [parport]
[<0>] parport_default_proc_register+0x28/0x1000 [parport]
[<0>] do_one_initcall+0x46/0x1cd
[<0>] do_init_module+0x5b/0x20d
[<0>] load_module+0x1b3d/0x20f0
[<0>] __do_sys_finit_module+0xbd/0xe0
[<0>] do_syscall_64+0x60/0x120
[<0>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[<0>] 0xffffffffffffffff
tweed:~ # cat /proc/1209/stack 
[<0>] load_module+0xe6a/0x20f0
[<0>] __do_sys_finit_module+0xbd/0xe0
[<0>] do_syscall_64+0x60/0x120
[<0>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[<0>] 0xffffffffffffffff

call_usermodehelper_exec+0xc7/0x140 is (build from commit 1aec4211204d)
line 583 in kernel/umh.c:

		retval = wait_for_completion_killable(&done);

and load_module+0xe6a/0x20f0 is in add_unformed_module(), line 3577 in
kernel/module.c:

			err = wait_event_interruptible(module_wq,
					       finished_loading(mod->name));

Unfortunately I don't have version of crash able to deal with kernels as
new as these so I wasn't able to find more for now.

I have seen this both on real hardware and in a VM.

Michal Kubecek