This bug was fixed in the package linux - 4.15.0-154.161
---------------
linux (4.15.0-154.161) bionic; urgency=medium
* bionic/linux: 4.15.0-154.161 -proposed tracker (LP: #1938411)
* Potential reverts of 4.19.y stable changes in 18.04 (LP: #1938537)
- SAUCE: Revert "locking/mutex: clear MUTEX_FLAGS if wait_list is empty due
to
signal"
- SAUCE: Revert "drm/amd/amdgpu: fix refcount leak"
* Packaging resync (LP: #1786013)
- [Packaging] resync getabis
- [Packaging] update helper scripts
- update dkms package versions
* btrfs: Automatic balance returns -EUCLEAN and leads to forced readonly
filesystem (LP: #1934709) // CVE-2019-19036
- btrfs: Validate child tree block's level and first key
- btrfs: Detect unbalanced tree with empty leaf before crashing btree
operations
* btrfs: Automatic balance returns -EUCLEAN and leads to forced readonly
filesystem (LP: #1934709)
- Revert "btrfs: Detect unbalanced tree with empty leaf before crashing
btree
operations"
- Revert "btrfs: Validate child tree block's level and first key"
- btrfs: Only check first key for committed tree blocks
- btrfs: Fix wrong first_key parameter in replace_path
* Enable fib-onlink-tests.sh and msg_zerocopy.sh in kselftests/net on Bionic
(LP: #1934759)
- selftests: Add fib-onlink-tests.sh to TEST_PROGS
- selftests: net: use TEST_PROGS_EXTENDED
- selftests/net: enable msg_zerocopy test
- SAUCE: selftests: Make fib-onlink-tests.sh executable
* Kernel oops due to uninitialized list on kernfs (kernfs_kill_sb)
(LP: #1934175)
- kernfs: deal with kernfs_fill_super() failures
- unfuck sysfs_mount()
* large_dir in ext4 broken (LP: #1933074)
- SAUCE: ext4: fix directory index node split corruption
* btrfs: Attempting to balance a nearly full filesystem with relocated root
nodes fails (LP: #1933172) // CVE-2019-19036
- btrfs: reloc: fix reloc root leak and NULL pointer dereference
* btrfs: Attempting to balance a nearly full filesystem with relocated root
nodes fails (LP: #1933172)
- Revert "btrfs: reloc: fix reloc root leak and NULL pointer dereference"
* Pixel format change broken for Elgato Cam Link 4K (LP: #1932367)
- (upstream) media: uvcvideo: Fix pixel format change for Elgato Cam Link 4K
* Bionic update: upstream stable patchset 2021-06-23 (LP: #1933375)
- net: usb: cdc_ncm: don't spew notifications
- efi: Allow EFI_MEMORY_XP and EFI_MEMORY_RO both to be cleared
- efi: cper: fix snprintf() use in cper_dimm_err_location()
- vfio/pci: Fix error return code in vfio_ecap_init()
- vfio/pci: zap_vma_ptes() needs MMU
- vfio/platform: fix module_put call in error flow
- ipvs: ignore IP_VS_SVC_F_HASHED flag when adding service
- HID: pidff: fix error return code in hid_pidff_init()
- HID: i2c-hid: fix format string mismatch
- netfilter: nfnetlink_cthelper: hit EBUSY on updates if size mismatches
- ieee802154: fix error return code in ieee802154_add_iface()
- ieee802154: fix error return code in ieee802154_llsec_getparams()
- Bluetooth: fix the erroneous flush_work() order
- Bluetooth: use correct lock to prevent UAF of hdev object
- net: caif: added cfserl_release function
- net: caif: add proper error handling
- net: caif: fix memory leak in caif_device_notify
- net: caif: fix memory leak in cfusbl_device_notify
- ALSA: timer: Fix master timer notification
- ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed
- pid: take a reference when initializing `cad_pid`
- ocfs2: fix data corruption by fallocate
- nfc: fix NULL ptr dereference in llcp_sock_getname() after failed connect
- btrfs: fix error handling in btrfs_del_csums
- btrfs: fixup error handling in fixup_inode_link_counts
- mm, hugetlb: fix simple resv_huge_pages underflow on UFFDIO_COPY
- selftests/bpf: make 'dubious pointer arithmetic' test useful
- bnxt_en: Remove the setting of dev_port.
- KVM: SVM: Truncate GPR value for DR and CR accesses in !64-bit mode
- sched/fair: Optimize select_idle_cpu
- xen-pciback: redo VF placement in the virtual topology
- ALSA: usb: update old-style static const declaration
- nl80211: validate key indexes for cfg80211_registered_device
- x86/apic: Mark _all_ legacy interrupts when IO/APIC is missing
- btrfs: return errors from btrfs_del_csums in cleanup_ref_head
- KVM: arm64: Fix debug register indexing
-- Kleber Sacilotto de Souza <kleber.so...@canonical.com> Fri, 30 Jul
2021 14:39:24 +0200
** Changed in: linux (Ubuntu Bionic)
Status: Fix Committed => Fix Released
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-19036
--
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/1933074
Title:
large_dir in ext4 broken
Status in linux package in Ubuntu:
Triaged
Status in linux source package in Bionic:
Fix Released
Status in linux source package in Focal:
Fix Released
Status in linux source package in Groovy:
Won't Fix
Status in linux source package in Hirsute:
Fix Released
Status in linux source package in Impish:
Triaged
Bug description:
== SRU, Bionic, Focal, Groovy, Hirsute, Impish ==
[Impact]
Creating millions of files on ext4 partition with large_dir support by
touching them will eventually trip an ext4 leaf node issue in the
index hash. This occurs more frequently when also using smaller block
sizes and ends up either with a EXIST or EUCLEAN failure.
This occurs on the restart condition when performing do_split.
[ Fix ]
The fix protects do_split() from the restart condition, making it safe
from both current and future ordering of goto statements in earlier
sections of the code.
The fix is from a patch sent upstream and cc'd to Ted Tso but didn't
appear on the ext4 mailing list presumably because it got marked as
SPAM.
[ Test Case ]
Without the fix touching tens of thousands of empty files will trip
the issue. It seems to occur more frequently with memory pressure and
smaller block sizes, e.g.:
sudo mkdir -p /mnt/tmpfs /mnt/storage
sudo mount -t tmpfs -o size=9000M tmpfs /mnt/tmpfs
sudo dd if=/dev/urandom of=/mnt/tmpfs/ext4.img bs=1M
sudo mkfs.ext4 -O large_dir -N 21000000 -O dir_index /mnt/tmpfs/ext4.img -b
1024 -F
sudo mount /mnt/tmpfs/ext4.img /mnt/storage
and compile and run the attached C program (see
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1933074/+attachment/5509402/+files/touch.c)
that quickly populates /mnt/storage with empty files. Without the fix
this will terminate with an -EEXIST or -EUCLEAN error on the file
creation after several tens of thousands of files.
[Where problems could occur]
This changes the behaviour of the directory indexing hashing so there
is a regression potential that this may introduce subsequent index
hashing issues when needed (or not) to do a split. This patch seems
to cover all the necessary cases, so I believe this risk is relatively
low. I have also tested this on all the kernel series in the SRU with
21,000,000 files so I am confident we have enough test coverage to
show the fix is OK.
----------------------------------------------------------
I believe, I found a bug in ext4 in recent kernel versions.
I stumbled across this while I was trying to restore a backup to a new VM.
How to reproduce this bug:
1. Use a virtual/physical machine with "Ubuntu 18.04.5 LTS" and kernel
version 4.15.0-144-generic.
2. add a secondary disk to hold the test files.
3. prepare and mount the filesystem with enabled 'large_dir' flag:
mkfs.ext4 -m0 /dev/sdb1;
tune2fs -O large_dir /dev/sdb1;
mkdir /mnt/storage;
mount /dev/sdb1 /mnt/storage;
4. change to directory and create approx. 16 mio files
cd /mnt/storage;
i=0;
while (( $i < 20000000 )); do
i=$(( $i + 1 ));
(( $i % 1000 == 0 )) && echo $i;
touch file_$i.dat || break;
done
Expected behaviour:
- 20 mio files shoud be created without error
What happened instead:
- The loop aborts with an error message:
# 16263100
# touch: cannot touch 'file_16263173.dat': Structure needs cleaning
- dmesg gives a little more details:
# [Mon Jun 21 03:15:18 2021] EXT4-fs error (device sdb): dx_probe:855: inode
#2: block 146221: comm touch: directory leaf block found instead of index block
Additional notes:
- This occurs on kernel version 4.15.0-144-generic
- Not sure, but I believe one test was run on 4.15.0-143-generic and failed
too.
- Did not check against 4.15.0-142-generic
- On 4.15.0-141-generic, the problem does not exist. Behaviour is as expected.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1933074/+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
