Hi Jonathan,

Since this patch has been applied to the tree with a link to a different
bug, this bug report won't get any notification about when the fix is
published to -updates. Please follow the updates on bug 1815234.

Thank you.

** Changed in: linux (Ubuntu Bionic)
       Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1817060

Title:
  EXT4: Mainstream fix for regression caused by fix CVE-2018-10876 is
  missing from Ubuntu Bionic Kernel

Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Bionic:
  Fix Committed

Bug description:
  Bionic kernels including the current 4.15.0-45 (and 4.15.0-46 from the
  latest in git) contain the following commit  https://git.launchpad.net
  /~ubuntu-
  
kernel/ubuntu/+source/linux/+git/bionic/commit/?id=70b9ab218a71b56b6a8c1f4c0daf0219a5238597
  from June 2018 which was an (incorrect) attempt to fix CVE-2018-10876.

  Given that this problem involves changes to code relating to a CVE I
  have marked this bug as being security related

  Unfortunately this fix introduces a new bug whereby the kernel will
  detect corruption and take evasive action if a filesystem is remounted
  before the lazy background initialisation has zeroed block group
  zero's inode table.

  There was an upstream commit made in July 2018, which claims to fix the above 
regression but this one has not been adopted into Ubuntu's kernel:
  
(https://github.com/torvalds/linux/commit/5012284700775a4e6e3fbe7eac4c543c4874b559)

  Contrary to the example in the upstream fix, it doesn't really matter
  whether the first mount is ro or rw although if the initial mount is
  read-only then the kernel will not initialise in the background and a
  subsequent remount as rw is guaranteed to hit this problem, whereas
  after an initial rw mount there is a small window of time where a
  remount will encounter this problem.

  We are hitting this issue during automated builds because Puppet is
  likely to issue one or more remounts against a filesystem it has only
  just created and mounted. This seems like inefficient behaviour by
  Puppet, however remounting should be a safe operation and it currently
  is not.

  SUGGESTED FIX:
  --------------
  Please could the above upstream commit (874b559) to be patched into Ubuntu's 
kernel to alleviate this?

  STEPS TO REPRODUCE:
  -------------------
  You either need a spare disk/volume to reformat, or a 'loop' device backed to 
a large file - e.g.:
  # fallocate -l 25G /bigfile && losetup --find --show /bigfile

  Format the device, mount and remount e.g.:
  # mkfs.ext4 /dev/loop2
  # mount /dev/loop7 /mnt && mount -o remount /mnt
  NOTE: Contrary to the similar example in the upstream fix I am mounting rw 
not ro see my earlier comments on this.

  The filesystem will immediately be remounted read-only with the following in 
/var/log/syslog:
  ---
  Feb 21 12:25:04 host kernel: [1299993.278265] EXT4-fs (loop2): mounted 
filesystem with ordered data mode. Opts: errors=remount-ro
  Feb 21 12:25:04 host kernel: [1299993.284921] EXT4-fs error (device loop2): 
ext4_has_uninit_itable:3135: comm mount: Inode table for bg 0 marked as needing 
zeroing
  Feb 21 12:25:04 host kernel: [1299993.341356] Aborting journal on device 
loop2-8.
  Feb 21 12:25:05 host kernel: [1299993.634358] EXT4-fs (loop2): Remounting 
filesystem read-only
  ----

  By running dump2efs in a loop after first mount I was able to observe
  that the output for Group 0 shows in my case that it takes about 4-5
  seconds after the first mount before the kernel's ext4lazyinit process
  zeroes Group 0's inode table.

  WORKAROUND:
  -----------
  For the benefit of anyone else hitting this issue prior to a kernel fix, it 
is possible to avoid this problem by forcing mkfs to zero the inode tables 
immediately - e.g.
  # mkfs.ext4 -E lazy_itable_init=0
  This will cause mkfs to take a little longer creating the filesystem.

  With the workaround all block groups on the new filesystem (as shown by 
dumpe2fs) will look like this until some time after the filesystem was first 
mounted:
  Group 0: (Blocks 0-32767) csum 0x7b1a

  Once initialised (either by the ext4lazyinit or by using lazy_itable_init=0 ) 
they acquire the ITABLE_ZEROED flag and can then be safely remounted without 
hitting this bug:
  Group 0: (Blocks 0-32767) csum 0x7b1a [ITABLE_ZEROED]

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: linux-signed-image-generic 4.15.0.45.47
  ProcVersionSignature: Ubuntu 4.15.0-45.48-generic 4.15.18
  Uname: Linux 4.15.0-45-generic x86_64
  NonfreeKernelModules: wl
  ApportVersion: 2.20.9-0ubuntu7.5
  Architecture: amd64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', 
'/dev/snd/hwC0D3', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D8p', '/dev/snd/pcmC0D7p', 
'/dev/snd/pcmC0D3p', '/dev/snd/pcmC0D1c', '/dev/snd/pcmC0D1p', 
'/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/controlC0', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CurrentDesktop: MATE
  Date: Thu Feb 21 10:13:27 2019
  EcryptfsInUse: Yes
  HibernationDevice: RESUME=UUID=b48635fa-6372-48f1-98fd-91631831a174
  InstallationDate: Installed on 2017-10-04 (504 days ago)
  InstallationMedia: Ubuntu-MATE 17.04 "Zesty Zapus" - Release amd64 (20170412)
  MachineType: Apple Inc. Macmini6,2
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic 
root=UUID=a84d64f4-c466-422f-8a7e-d586bfa4a7ed ro
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-45-generic N/A
   linux-backports-modules-4.15.0-45-generic  N/A
   linux-firmware                             1.173.3
  SourcePackage: linux
  UpgradeStatus: Upgraded to bionic on 2018-10-09 (134 days ago)
  dmi.bios.date: 10/20/2016
  dmi.bios.vendor: Apple Inc.
  dmi.bios.version: MM61.88Z.0106.B0B.1610201654
  dmi.board.asset.tag: Base Board Asset Tag#
  dmi.board.name: Mac-F65AE981FFA204ED
  dmi.board.vendor: Apple Inc.
  dmi.board.version: Macmini6,2
  dmi.chassis.type: 16
  dmi.chassis.vendor: Apple Inc.
  dmi.chassis.version: Mac-F65AE981FFA204ED
  dmi.modalias: 
dmi:bvnAppleInc.:bvrMM61.88Z.0106.B0B.1610201654:bd10/20/2016:svnAppleInc.:pnMacmini6,2:pvr1.0:rvnAppleInc.:rnMac-F65AE981FFA204ED:rvrMacmini6,2:cvnAppleInc.:ct16:cvrMac-F65AE981FFA204ED:
  dmi.product.family: Macmini
  dmi.product.name: Macmini6,2
  dmi.product.version: 1.0
  dmi.sys.vendor: Apple Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1817060/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to