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 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46980 – usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4
https://notcve.org/view.php?id=CVE-2021-46980
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4 commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs. If such a source is connected it's possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object's (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now(). With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one. [ 151.545106][ T70] Unexpected kernel BRK exception at EL1 [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Call trace: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0 [ 151.545550][ T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] process_one_work+0x244/0x6f0 [ 151.545564][ T70] worker_thread+0x3e0/0xa64 We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command. • https://git.kernel.org/stable/c/4dbc6a4ef06d6a79ff91be6fc2e90f8660031ce0 https://git.kernel.org/stable/c/e5366bea0277425e1868ba20eeb27c879d5a6e2d https://git.kernel.org/stable/c/a453bfd7ef15fd9d524004d3ca7b05353a302911 https://git.kernel.org/stable/c/5e9c6f58b01e6fdfbc740390c01f542a35c97e57 https://git.kernel.org/stable/c/1f4642b72be79757f050924a9b9673b6a02034bc •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46978 – KVM: nVMX: Always make an attempt to map eVMCS after migration
https://notcve.org/view.php?id=CVE-2021-46978
In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always make an attempt to map eVMCS after migration When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can't map evmcs page right away: evmcs gpa is not 'struct kvm_vmx_nested_state_hdr' and we can't read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit f2c7ef3ba955 ("KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit") added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The 'fix' is far from being ideal as we can't easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole 'KVM_REQ_GET_NESTED_STATE_PAGES' idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the 'native' path when vmptr loading happens on vmx_set_nested_state(). • https://git.kernel.org/stable/c/0faceb7d6dda6f370ff1fa0464d7180f7e5cb417 https://git.kernel.org/stable/c/f2c7ef3ba9556d62a7e2bb23b563c6510007d55c https://git.kernel.org/stable/c/c8bf64e3fb77cc19bad146fbe26651985b117194 https://git.kernel.org/stable/c/200a45649ab7361bc80c70aebf7165b64f9a6c9f https://git.kernel.org/stable/c/bd0e8455b85b651a4c77de9616e307129b15aaa7 https://git.kernel.org/stable/c/f5c7e8425f18fdb9bdb7d13340651d7876890329 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46977 – KVM: VMX: Disable preemption when probing user return MSRs
https://notcve.org/view.php?id=CVE-2021-46977
In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Disable preemption when probing user return MSRs Disable preemption when probing a user return MSR via RDSMR/WRMSR. If the MSR holds a different value per logical CPU, the WRMSR could corrupt the host's value if KVM is preempted between the RDMSR and WRMSR, and then rescheduled on a different CPU. Opportunistically land the helper in common x86, SVM will use the helper in a future commit. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: VMX: deshabilite la preferencia al sondear los MSR devueltos por el usuario. Deshabilite la preferencia al sondear el MSR devuelto por un usuario a través de RDSMR/WRMSR. Si MSR tiene un valor diferente por CPU lógica, WRMSR podría dañar el valor del host si KVM se adelanta entre RDMSR y WRMSR y luego se reprograma en una CPU diferente. • https://git.kernel.org/stable/c/4be5341026246870818e28b53202b001426a5aec https://git.kernel.org/stable/c/31f29749ee970c251b3a7e5b914108425940d089 https://git.kernel.org/stable/c/5adcdeb57007ccf8ab7ac20bf787ffb6fafb1a94 https://git.kernel.org/stable/c/e3ea1895df719c4ef87862501bb10d95f4177bed https://git.kernel.org/stable/c/5104d7ffcf24749939bea7fdb5378d186473f890 •