Created attachment 288553 [details] Lenovo X220 undocking dmesg I'm not sure if fs/vfs is a proper component to fill the bug to, please reassign if anything. Short description: When attaching and detaching CD-Rom device to the PC, either emulated or physical, the device handling userspace software (udisks-daemon) and the kernel may stall all block device communication, making killing userspace application and proper shutdown/reboot impossible. Detailed description: I have Lenovo X220 laptop with dock. The dock includes CD-Rom drive. Quite frequently, when I dock and undock the laptop, I see the [attachment] in dmesg. Snippet: >pktcdvd: pktcdvd0: writer mapped to sr0 >ata2.00: disabled >ata2.00: detaching (SCSI 1:0:0:0) >ACPI: \_SB_.GDCK: undocking >------------[ cut here ]------------ >kernel BUG at fs/inode.c:1587! >invalid opcode: 0000 [#1] SMP NOPTI >CPU: 0 PID: 9426 Comm: udisks-daemon Tainted: G IOE >5.5.16-200.fc31.x86_64 #1 After that, 'udisks2' enters 'Ds' state and could not be killed, even with 'kill -9'. I can't properly shut down or reboot the laptop. Applications, which use udisks (dolphin file manager) would stall at communication with udisks as well. The same happens with Huawei E3372 USB LTE modem. This modem emulates CD-Rom drive upon connection and should be switched to proper network mode with usb_modeswitch. Switching the modem with usb_modeswitch also triggers this issue frequently. Since the log says: >invalid opcode: 0000 [#1] SMP NOPTI I assume that there's code corruption (maybe use-after-free or some thread race, that's only my assumption) which possibly may be exploited to get code execution with malicious CD-Rom drive. Versions: Fedora 31 Kernel 5.5.16-200.fc31.x86_64 from Fedora repository, with zswap.enabled=1, mitigations=off Lenovo ThinkPad X220 (Intel Sandy Bridge) This began to happen somewhere around 5.3+ kernels. 4.19 does not have this issue.
Created attachment 288555 [details] Full dmesg output
Another day, another kernel oops.
Created attachment 288673 [details] dmesg snippet Snippet from dmesg
Created attachment 288675 [details] Full dmesg output #2 Full dmesg output #2
See also: #202743. It's the same bug.
bug #202743