CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46987 – btrfs: fix deadlock when cloning inline extents and using qgroups
https://notcve.org/view.php?id=CVE-2021-46987
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock when cloning inline extents and using qgroups There are a few exceptional cases where cloning an inline extent needs to copy the inline extent data into a page of the destination inode. When this happens, we end up starting a transaction while having a dirty page for the destination inode and while having the range locked in the destination's inode iotree too. Because when reserving metadata space for a transaction we may need to flush existing delalloc in case there is not enough free space, we have a mechanism in place to prevent a deadlock, which was introduced in commit 3d45f221ce627d ("btrfs: fix deadlock when cloning inline extent and low on free metadata space"). However when using qgroups, a transaction also reserves metadata qgroup space, which can also result in flushing delalloc in case there is not enough available space at the moment. When this happens we deadlock, since flushing delalloc requires locking the file range in the inode's iotree and the range was already locked at the very beginning of the clone operation, before attempting to start the transaction. When this issue happens, stack traces like the following are reported: [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142) [72747.556271] Call Trace: [72747.556273] __schedule+0x296/0x760 [72747.556277] schedule+0x3c/0xa0 [72747.556279] io_schedule+0x12/0x40 [72747.556284] __lock_page+0x13c/0x280 [72747.556287] ? generic_file_readonly_mmap+0x70/0x70 [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs] [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160 [72747.556358] ? • https://git.kernel.org/stable/c/c53e9653605dbf708f5be02902de51831be4b009 https://git.kernel.org/stable/c/36af2de520cca7c37974cc4944b47850f6c460ee https://git.kernel.org/stable/c/d5347827d0b4b2250cbce6eccaa1c81dc78d8651 https://git.kernel.org/stable/c/96157707c0420e3d3edfe046f1cc797fee117ade https://git.kernel.org/stable/c/f9baa501b4fd6962257853d46ddffbc21f27e344 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-46985 – ACPI: scan: Fix a memory leak in an error handling path
https://notcve.org/view.php?id=CVE-2021-46985
In the Linux kernel, the following vulnerability has been resolved: ACPI: scan: Fix a memory leak in an error handling path If 'acpi_device_set_name()' fails, we must free 'acpi_device_bus_id->bus_id' or there is a (potential) memory leak. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ACPI: scan: Corregir pérdida de memoria en una ruta de manejo de errores Si falla 'acpi_device_set_name()' debemos liberar 'acpi_device_bus_id->bus_id' o hay una (potencial) memoria filtración. • https://git.kernel.org/stable/c/e5cdbe419004e172f642e876a671a9ff1c52f8bb https://git.kernel.org/stable/c/717d9d88fbd956ab03fad97266f6ce63a036e7f8 https://git.kernel.org/stable/c/7385e438e1f31af5b86f72fd19b0dcd2738502c9 https://git.kernel.org/stable/c/bc0b1a2036dd8072106ec81a8685ecb901f72ed6 https://git.kernel.org/stable/c/4a5891992c680d69d7e490e4d0428d17779d8e85 https://git.kernel.org/stable/c/321dbe6c0b551f9f8030becc6900f77cf9bbb9ad https://git.kernel.org/stable/c/eb50aaf960e3bedfef79063411ffd670da94b84b https://git.kernel.org/stable/c/6901a4f795e0e8d65ae779cb37fc22e0b •
CVSS: 6.0EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46984 – kyber: fix out of bounds access when preempted
https://notcve.org/view.php?id=CVE-2021-46984
In the Linux kernel, the following vulnerability has been resolved: kyber: fix out of bounds access when preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This "works" accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx's than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type 'long unsigned int [128]' Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0 extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch. • https://git.kernel.org/stable/c/a6088845c2bf754d6cb2572b484180680b037804 https://git.kernel.org/stable/c/0b6b4b90b74c27bea968c214d820ba4254b903a5 https://git.kernel.org/stable/c/54dbe2d2c1fcabf650c7a8b747601da355cd7f9f https://git.kernel.org/stable/c/a287cd84e047045f5a4d4da793414e848de627c6 https://git.kernel.org/stable/c/2ef3c76540c49167a0bc3d5f80d00fd1fc4586df https://git.kernel.org/stable/c/efed9a3337e341bd0989161b97453b52567bc59d https://access.redhat.com/security/cve/CVE-2021-46984 https://bugzilla.redhat.com/show_bug.cgi?id=2266750 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46982 – f2fs: compress: fix race condition of overwrite vs truncate
https://notcve.org/view.php?id=CVE-2021-46982
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix race condition of overwrite vs truncate pos_fsstress testcase complains a panic as belew: ------------[ cut here ]------------ kernel BUG at fs/f2fs/compress.c:1082! invalid opcode: 0000 [#1] SMP PTI CPU: 4 PID: 2753477 Comm: kworker/u16:2 Tainted: G OE 5.12.0-rc1-custom #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Workqueue: writeback wb_workfn (flush-252:16) RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs] Call Trace: f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs] f2fs_write_cache_pages+0x468/0x8a0 [f2fs] f2fs_write_data_pages+0x2a4/0x2f0 [f2fs] do_writepages+0x38/0xc0 __writeback_single_inode+0x44/0x2a0 writeback_sb_inodes+0x223/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x290 wb_workfn+0x309/0x500 process_one_work+0x220/0x3c0 worker_thread+0x53/0x420 kthread+0x12f/0x150 ret_from_fork+0x22/0x30 The root cause is truncate() may race with overwrite as below, so that one reference count left in page can not guarantee the page attaching in mapping tree all the time, after truncation, later find_lock_page() may return NULL pointer. - prepare_compress_overwrite - f2fs_pagecache_get_page - unlock_page - f2fs_setattr - truncate_setsize - truncate_inode_page - delete_from_page_cache - find_lock_page Fix this by avoiding referencing updated page. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: comprimir: corregir la condición de ejecución de sobrescritura frente a truncar pos_fsstress testcase presenta un pánico como se muestra a continuación: ------------[ cortar aquí ]--- --------- ¡ERROR del kernel en fs/f2fs/compress.c:1082! código de operación no válido: 0000 [#1] SMP PTI CPU: 4 PID: 2753477 Comm: kworker/u16:2 Contaminado: G OE 5.12.0-rc1-custom #1 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-2 01/04/2014 Cola de trabajo: reescritura wb_workfn (flush-252:16) RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs] Seguimiento de llamadas: f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs] f2fs_write_cache_pages+ 0x468/0x8a0 [f2fs] f2fs_write_data_pages+0x2a4/0x2f0 [f2fs] do_writepages+0x38/0xc0 __writeback_single_inode+0x44/0x2a0 writeback_sb_inodes+0x223/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0 x290 wb_workfn+0x309/0x500 proceso_one_work+0x220/0x3c0 trabajador_thread+0x53/ 0x420 kthread+0x12f/0x150 ret_from_fork+0x22/0x30 La causa principal es que truncate() puede correr con sobrescritura como se muestra a continuación, por lo que un recuento de referencias restante en la página no puede garantizar que la página se adjunte en el árbol de mapeo todo el tiempo, después del truncamiento, más adelante find_lock_page() puede devolver un puntero NULL. - prepare_compress_overwrite - f2fs_pagecache_get_page - unlock_page - f2fs_setattr - truncate_setsize - truncate_inode_page - delete_from_page_cache - find_lock_page Solucione este problema evitando hacer referencia a la página actualizada. • https://git.kernel.org/stable/c/4c8ff7095bef64fc47e996a938f7d57f9e077da3 https://git.kernel.org/stable/c/5639b73fd3bc6fc8ca72e3a9ac15aacaabd7ebff https://git.kernel.org/stable/c/64acb100fe3beb5d20184d0ae3307235bd3555c4 https://git.kernel.org/stable/c/936158b15e2648253afb824d252c910c496d34b5 https://git.kernel.org/stable/c/a949dc5f2c5cfe0c910b664650f45371254c0744 •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2021-46981 – nbd: Fix NULL pointer in flush_workqueue
https://notcve.org/view.php?id=CVE-2021-46981
In the Linux kernel, the following vulnerability has been resolved: nbd: Fix NULL pointer in flush_workqueue Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: error_code(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 <f0> 48 0f b1 55 d [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ? nbd_ioctl+0x490/0x490 [ 656.386954] ? • https://git.kernel.org/stable/c/e9e006f5fcf2bab59149cb38a48a4817c1b538b4 https://git.kernel.org/stable/c/0b584bf573ae59021069c056c22d65d5721910cb https://git.kernel.org/stable/c/d1db913b044f0a0693d8ee283d26b81d536efcd5 https://git.kernel.org/stable/c/9f0f39c92e4f50189155dfb13bb5524372e40eba https://git.kernel.org/stable/c/e83a26a49356a3dbd4f54102abe17fc594643698 https://git.kernel.org/stable/c/92ec11cccb7fc14331e000ab2337f60aa433433e https://git.kernel.org/stable/c/b3ead320dce6c7d7206103deca766b317591c286 https://git.kernel.org/stable/c/1c4962df938891af9ab4775f5224ef860 •