Hi Greg,
On Wed, Mar 17, 2021 at 11:11:04AM +0100, Greg KH wrote:
> On Wed, Mar 17, 2021 at 11:21:23AM +0530, Rohit Keshri wrote:
> > Hello Team,
> >
> > A flaw was found in the Linux kernel. A denial of service problem is
> > identified if an extent tree is corrupted in a crafted ext4 filesystem in
> > fs/ext4/extents.c in ext4_es_cache_extent. Fabricating an integer overflow,
> > A local attacker with a special user privilege may cause a system crash
> > problem which can lead to an availability threat.
>
> Please include what kernel version things like this were "found in" and
> when it was fixed, otherwise you force everyone to go scramble just to
> find that this was reported in July of 2020 and fixed then in the 5.9
> kernel release and has already been backported to all relevant stable
> kernel releases in August of last year.
>
> In other words, no one running an updated kernel version from kernel.org
> is vulnerable today, right? Are you saying that specific distro kernels
> are vulnerable to this? If so, which ones?
It might be missing in some stable trees from a quick check. I just
checked the SUSE bug and it lists the following three relevant
commits, whilst the last one seems the relevant one:
d176b1f62f24 "ext4: handle error of ext4_setup_system_zone() on remount"
bf9a379d0980 "ext4: don't allow overlapping system zones"
ce9f24cccdc0 "ext4: check journal inode extents more carefully"
ce9f24cccdc0 was indeed included in 5.9-rc2, and backported to
v5.7.18: 3b654d118548ef2bb212dca361a5d1d19707822d ext4: check journal inode extents more carefully
v5.8.4: cfa678021a1bb6b5ce4aa45c865f2d3167646f89 ext4: check journal inode extents more carefully
v5.9-rc2: ce9f24cccdc019229b70a5c15e2b09ad9c0ab5d1 ext4: check journal inode extents more carefully
Then though it has
Fixes: 0a944e8a6c66 ("ext4: don't perform block validity checks on the journal inode")
and 0a944e8a6c66 itself was backported to some of the stable series as
well, I found:
v3.16.85: 71bfaf9e30125ec5b408fd328e412abf3b23214d ext4: don't perform block validity checks on the journal inode
v4.14.178: fc3293a80acc469fbabc91bfbf2e65dc84377dc7 ext4: don't perform block validity checks on the journal inode
v4.19.73: 97fbf573460e56ddf172614f70cdfa2af03b20ea ext4: don't perform block validity checks on the journal inode
v4.4.221: 571fa68cacdf5fa70a6fdb71bda051f822d3cfb6 ext4: don't perform block validity checks on the journal inode
v4.9.221: 2130aae807893cff163404bf6f6f6a4906dd14a1 ext4: don't perform block validity checks on the journal inode
v5.2-rc2: 0a944e8a6c66ca04c7afbaa17e22bf208a8b37f0 ext4: don't perform block validity checks on the journal inode
So in the current still supported stable series, in 4.9.221, 4.14.178 and
4.19.73.
I just tried the reproducer from
https://bugzilla.suse.com/show_bug.cgi?id=1173485 on a system with 4.19.177
which so has not yet the 0a944e8a6c66 ("ext4: don't perform block validity
checks on the journal inode") fix backported and it indeed causes:
[ 224.003978] ------------[ cut here ]------------
[ 224.005052] kernel BUG at fs/ext4/extents_status.c:762!
[ 224.006659] invalid opcode: 0000 [#1] SMP PTI
[ 224.008378] CPU: 0 PID: 594 Comm: mount Not tainted 4.19.0-15-amd64 #1 Debian 4.19.177-1
[ 224.011292] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
[ 224.014043] RIP: 0010:ext4_es_cache_extent+0xfe/0x100 [ext4]
[ 224.015770] Code: 48 8b 45 00 48 8b 7d 08 48 83 c5 18 48 89 e2 4c 89 e6 e8 a5 15 d8 d2 48 8b 45 00 48 85 c0 75 e4 e9 54 ff ff ff e8 a2 65 3f d2 <0f> 0b 0f 1f 44 00 00 41 55 49 89 fd 41 54 55 48 89 d5 53 89 f3 0f
[ 224.019834] RSP: 0018:ffffa7a840b8f958 EFLAGS: 00010213
[ 224.021034] RAX: 07ffffffffffffff RBX: 0000000000007ffd RCX: 0000ffffffffffff
[ 224.022658] RDX: 0000000000007fff RSI: 00000000ffffffff RDI: ffff940d78a78968
[ 224.024283] RBP: 0000000000007fff R08: 1000ffffffffffff R09: 00000000000002c9
[ 224.025913] R10: 00000000000002c9 R11: 0000000000000041 R12: ffff940d78a78968
[ 224.027549] R13: 00000000ffffffff R14: ffffffffffffffff R15: 00000000ffffffff
[ 224.029179] FS: 00007fe8d33fb100(0000) GS:ffff940d7ba00000(0000) knlGS:0000000000000000
[ 224.031011] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 224.032354] CR2: 000056074c755878 CR3: 0000000135184001 CR4: 00000000001606f0
[ 224.033990] Call Trace:
[ 224.034634] ext4_cache_extents+0x63/0xd0 [ext4]
[ 224.035712] __read_extent_tree_block+0x111/0x160 [ext4]
[ 224.036665] ? __kmalloc+0x180/0x220
[ 224.037343] ? ext4_find_extent+0x144/0x320 [ext4]
[ 224.038247] ext4_find_extent+0x144/0x320 [ext4]
[ 224.039144] ext4_ext_map_blocks+0x6a/0xda0 [ext4]
[ 224.040063] ? schedule+0x28/0x80
[ 224.040747] ? __wait_on_bit+0x58/0x90
[ 224.041476] ext4_map_blocks+0x2e4/0x5f0 [ext4]
[ 224.042350] ? ext4_data_block_valid+0x1d/0x20 [ext4]
[ 224.043313] ? __ext4_ext_check+0x238/0x3a0 [ext4]
[ 224.044261] _ext4_get_block+0x8e/0x110 [ext4]
[ 224.045158] ? unlock_new_inode+0x4e/0x60
[ 224.045960] generic_block_bmap+0x4b/0x70
[ 224.046765] jbd2_journal_init_inode+0x11/0xb0 [jbd2]
[ 224.047794] ext4_fill_super+0x3052/0x3c70 [ext4]
[ 224.048730] ? bdev_name.isra.6+0x2a/0xa0
[ 224.049530] ? ext4_calculate_overhead+0x490/0x490 [ext4]
[ 224.050555] ? snprintf+0x49/0x60
[ 224.051234] ? ext4_calculate_overhead+0x490/0x490 [ext4]
[ 224.052309] ? mount_bdev+0x177/0x1b0
[ 224.053074] ? ext4_calculate_overhead+0x490/0x490 [ext4]
[ 224.054146] mount_bdev+0x177/0x1b0
[ 224.054858] mount_fs+0x3e/0x150
[ 224.055533] vfs_kern_mount.part.36+0x54/0x120
[ 224.056394] do_mount+0x20e/0xcc0
[ 224.057022] ? _copy_from_user+0x37/0x60
[ 224.057781] ? memdup_user+0x4b/0x70
[ 224.058530] ksys_mount+0xb6/0xd0
[ 224.059231] __x64_sys_mount+0x21/0x30
[ 224.059949] do_syscall_64+0x53/0x110
[ 224.060631] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 224.061531] RIP: 0033:0x7fe8d35f9fea
[ 224.062255] Code: 48 8b 0d a9 0e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 76 0e 0c 00 f7 d8 64 89 01 48
[ 224.065741] RSP: 002b:00007ffcd2022e38 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
[ 224.067223] RAX: ffffffffffffffda RBX: 000056074c748fb0 RCX: 00007fe8d35f9fea
[ 224.068620] RDX: 000056074c751050 RSI: 000056074c7491e0 RDI: 000056074c7491c0
[ 224.069987] RBP: 00007fe8d39471c4 R08: 0000000000000000 R09: 0000000000000000
[ 224.071399] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 224.072764] R13: 0000000000000000 R14: 000056074c7491c0 R15: 000056074c751050
[ 224.074101] Modules linked in: loop sctp binfmt_misc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel button virtio_console virtio_balloon evdev qemu_fw_cfg joydev pcspkr serio_raw nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 fscrypto ecb hid_generic usbhid hid btrfs xor zstd_decompress zstd_compress xxhash raid6_pq libcrc32c crc32c_generic dm_mod ata_generic virtio_net net_failover failover virtio_blk crc32c_intel ata_piix libata uhci_hcd ehci_pci ehci_hcd scsi_mod floppy aesni_intel usbcore psmouse aes_x86_64 crypto_simd cryptd glue_helper i2c_piix4 virtio_pci virtio_ring virtio usb_common
[ 224.084374] ---[ end trace a93d957244af62ea ]---
[ 224.085298] RIP: 0010:ext4_es_cache_extent+0xfe/0x100 [ext4]
[ 224.086402] Code: 48 8b 45 00 48 8b 7d 08 48 83 c5 18 48 89 e2 4c 89 e6 e8 a5 15 d8 d2 48 8b 45 00 48 85 c0 75 e4 e9 54 ff ff ff e8 a2 65 3f d2 <0f> 0b 0f 1f 44 00 00 41 55 49 89 fd 41 54 55 48 89 d5 53 89 f3 0f
[ 224.089834] RSP: 0018:ffffa7a840b8f958 EFLAGS: 00010213
[ 224.090832] RAX: 07ffffffffffffff RBX: 0000000000007ffd RCX: 0000ffffffffffff
[ 224.092181] RDX: 0000000000007fff RSI: 00000000ffffffff RDI: ffff940d78a78968
[ 224.093539] RBP: 0000000000007fff R08: 1000ffffffffffff R09: 00000000000002c9
[ 224.094899] R10: 00000000000002c9 R11: 0000000000000041 R12: ffff940d78a78968
[ 224.096264] R13: 00000000ffffffff R14: ffffffffffffffff R15: 00000000ffffffff
[ 224.097586] FS: 00007fe8d33fb100(0000) GS:ffff940d7ba00000(0000) knlGS:0000000000000000
[ 224.099144] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 224.100284] CR2: 000056074c755878 CR3: 0000000135184001 CR4: 00000000001606f0
So likely the 4.9.y, 4.14.y and 4.19.y still have the bug? Is this correct? I
only quickly skimmed over the report, but this seems to be the case.
Regards,
Salvatore
