Doing multiple squashfs (and other loop?) mounts in parallel breaks
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Critical
|
Unassigned |
Bug Description
On a system running a 5.2 kernel, doing a large number of mounts of squashfs filesystems in parallel results in the mounts getting out of sync with their backing devices.
To reproduce,
https:/
this breaks people with ~40 snaps (easily achievable given snapd leaves up to 3 previous revisions of snaps mounted at any given time, so a person with ~13 snaps that get updated often will hit this number).
ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: linux-image-
ProcVersionSign
Uname: Linux 5.2.0-8-generic x86_64
ApportVersion: 2.20.11-0ubuntu5
Architecture: amd64
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CurrentDesktop: ubuntu:GNOME
Date: Wed Jul 17 15:11:15 2019
InstallationDate: Installed on 2019-07-17 (0 days ago)
InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190716)
IwConfig:
ens3 no wireless extensions.
lo no wireless extensions.
Lsusb: Error: command ['lsusb'] failed with exit code 1:
MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
ProcFB: 0 qxldrmfb
ProcKernelCmdLine: BOOT_IMAGE=
RelatedPackageV
linux-
linux-
linux-firmware 1.180
RfKill:
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/01/2014
dmi.bios.vendor: SeaBIOS
dmi.bios.version: Ubuntu-
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.
dmi.modalias: dmi:bvnSeaBIOS:
dmi.product.name: Standard PC (i440FX + PIIX, 1996)
dmi.product.
dmi.sys.vendor: QEMU
CVE References
tags: | added: rls-ee-incoming |
Changed in linux (Ubuntu): | |
importance: | Undecided → Critical |
status: | New → Confirmed |
summary: |
- Doing multiple squashfs ((and other loop?) mounts in parallel breaks + Doing multiple squashfs (and other loop?) mounts in parallel breaks |
tags: | added: cscc |
tags: | added: patch |
I haven't yet tried to reproduce this with an upstream kernel, but given that it's affecting arch users with 5.2 as well, it's fairly likely to be there.