failure to set dtr/rts on USB VCP causes kernel page fault

Bug #1905994 reported by Corvus Corax
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

attempting to reproduce bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1905782 on ubuntu
20.04.1 LTS yields a kernel OOOPS / page fault in the USB cdc_acm driver.

will upload OOOPs shortly.

steps to reproduce:

1. boot ubuntu 20.04.1 LTS (In this case from live CD)
2. plug in a USB device with a virtual com port
3. configure the TTY assigned (/dev/ttyACM0) setting dtr/rts (for example with minicom)
4. device does not support setting dtr/rts

expected result:
error message
actual result:
error message plus page fault in kernel space plus system becoming unstable

will upload and attach dmesg log as soon as I managed to log the oops

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: linux-image-5.4.0-42-generic 5.4.0-42.46
ProcVersionSignature: Ubuntu 5.4.0-42.46-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27.4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ubuntu 4492 F.... pulseaudio
CasperMD5CheckMismatches: ./casper/filesystem.squashfs
CasperMD5CheckResult: skip
CasperVersion: 1.445.1
CurrentDesktop: ubuntu:GNOME
Date: Fri Nov 27 17:37:22 2020
LiveMediaBuild: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
MachineType: FUJITSU LIFEBOOK E736
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/username.seed maybe-ubiquity quiet splash ---
RelatedPackageVersions:
 linux-restricted-modules-5.4.0-42-generic N/A
 linux-backports-modules-5.4.0-42-generic N/A
 linux-firmware 1.187.2
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/20/2016
dmi.bios.vendor: FUJITSU // Insyde Software Corp.
dmi.bios.version: Version 1.22
dmi.board.name: FJNB293
dmi.board.vendor: FUJITSU
dmi.board.version: M4
dmi.chassis.type: 10
dmi.chassis.vendor: FUJITSU
dmi.chassis.version: LIFEBOOK E736
dmi.modalias: dmi:bvnFUJITSU//InsydeSoftwareCorp.:bvrVersion1.22:bd12/20/2016:svnFUJITSU:pnLIFEBOOKE736:pvr10601115935:rvnFUJITSU:rnFJNB293:rvrM4:cvnFUJITSU:ct10:cvrLIFEBOOKE736:
dmi.product.family: LIFEBOOK-FTS
dmi.product.name: LIFEBOOK E736
dmi.product.version: 10601115935
dmi.sys.vendor: FUJITSU

Revision history for this message
Corvus Corax (corvuscorax) wrote :
Revision history for this message
Corvus Corax (corvuscorax) wrote :

adding dmesg log of the OOOPS

note that the behavior differs from bug #1905782 on Ubuntu 18.

On Ubuntu 18 no OOPS is triggered, instead the driver enters an endless loop when the USB device gets disconnected later

On Ubuntu 20 a kernel OOPS is generated and takes the whole USB stack with it. past that point no more USB events are generated and the system doesn't even notice USB devices getting plugged in or plugged out.

note that to trigger the OOOPS I had to repeat the procedure to reproduce twice - connect, try to set dtr/rts, disconnect, connect again, once more try to set dtr/rts --> OOOPS

on Ubuntu18 the modemmanager service automatically tried to set dtr/rts on the device. On Ubuntu 20 I had to do this by hand by opening the tty device with:

minicom -o -D /dev/ttyACM0

Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Corvus Corax (corvuscorax) wrote :

note, as visible in the dmesg log, IO attempts with another unrelated USB device (the USB stick ubuntu had previously booted from) failed, causing IO errors, as the entire USB subsystem was down.

this is also why I had to submit this bug with "ubuntu-bug" prior to actually causing the bug and upload the dmesg.log later, since ubuntu-bug would no longer be able to work after the OOPS happened.

like with Ubuntu 18 this bug has the potential to cause data loss, make the system unstable, and a hard reboot is required to recover

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.