CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47098 – hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations
https://notcve.org/view.php?id=CVE-2021-47098
In the Linux kernel, the following vulnerability has been resolved: hwmon: (lm90) Prevent integer overflow/underflow in hysteresis calculations Commit b50aa49638c7 ("hwmon: (lm90) Prevent integer underflows of temperature calculations") addressed a number of underflow situations when writing temperature limits. However, it missed one situation, seen when an attempt is made to set the hysteresis value to MAX_LONG and the critical temperature limit is negative. Use clamp_val() when setting the hysteresis temperature to ensure that the provided value can never overflow or underflow. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: hwmon: (lm90) Previene el desbordamiento/desbordamiento insuficiente de enteros en los cálculos de histéresis del commit b50aa49638c7 ("hwmon: (lm90) Evita el desbordamiento insuficiente de enteros en los cálculos de temperatura") abordó una serie de situaciones de desbordamiento insuficiente al escribir. límites de temperatura. Sin embargo, omitió una situación, vista cuando se intenta establecer el valor de histéresis en MAX_LONG y el límite de temperatura crítica es negativo. Utilice abrazadera_val() al configurar la temperatura de histéresis para garantizar que el valor proporcionado nunca pueda desbordarse o subestimarse. • https://git.kernel.org/stable/c/b50aa49638c7e12abf4ecc483f4e928c5cccc1b0 https://git.kernel.org/stable/c/d105f30bea9104c590a9e5b495cb8a49bdfe405f https://git.kernel.org/stable/c/55840b9eae5367b5d5b29619dc2fb7e4596dba46 •
CVSS: 6.0EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47097 – Input: elantech - fix stack out of bound access in elantech_change_report_id()
https://notcve.org/view.php?id=CVE-2021-47097
In the Linux kernel, the following vulnerability has been resolved: Input: elantech - fix stack out of bound access in elantech_change_report_id() The array param[] in elantech_change_report_id() must be at least 3 bytes, because elantech_read_reg_params() is calling ps2_command() with PSMOUSE_CMD_GETINFO, that is going to access 3 bytes from param[], but it's defined in the stack as an array of 2 bytes, therefore we have a potential stack out-of-bounds access here, also confirmed by KASAN: [ 6.512374] BUG: KASAN: stack-out-of-bounds in __ps2_command+0x372/0x7e0 [ 6.512397] Read of size 1 at addr ffff8881024d77c2 by task kworker/2:1/118 [ 6.512416] CPU: 2 PID: 118 Comm: kworker/2:1 Not tainted 5.13.0-22-generic #22+arighi20211110 [ 6.512428] Hardware name: LENOVO 20T8000QGE/20T8000QGE, BIOS R1AET32W (1.08 ) 08/14/2020 [ 6.512436] Workqueue: events_long serio_handle_event [ 6.512453] Call Trace: [ 6.512462] show_stack+0x52/0x58 [ 6.512474] dump_stack+0xa1/0xd3 [ 6.512487] print_address_description.constprop.0+0x1d/0x140 [ 6.512502] ? __ps2_command+0x372/0x7e0 [ 6.512516] __kasan_report.cold+0x7d/0x112 [ 6.512527] ? _raw_write_lock_irq+0x20/0xd0 [ 6.512539] ? __ps2_command+0x372/0x7e0 [ 6.512552] kasan_report+0x3c/0x50 [ 6.512564] __asan_load1+0x6a/0x70 [ 6.512575] __ps2_command+0x372/0x7e0 [ 6.512589] ? ps2_drain+0x240/0x240 [ 6.512601] ? • https://git.kernel.org/stable/c/9e4815cf178561104881e5d687ef69396aca1c8d https://git.kernel.org/stable/c/dde807b4a44273fa5f62c0cb308295e6d6642550 https://git.kernel.org/stable/c/e4c9062717feda88900b566463228d1c4910af6d https://git.kernel.org/stable/c/a7f95328c6f0afffdc4555f16e3bbab8bbf0d9be https://git.kernel.org/stable/c/676c572439e58b7ee6b7ca3f1e5595382921045c https://git.kernel.org/stable/c/dfd5b60b5342b6b505a104e48f08ad9b9bdbbd7b https://git.kernel.org/stable/c/1d72d9f960ccf1052a0630a68c3d358791dbdaaa https://access.redhat.com/security/cve/CVE-2021-47097 • CWE-125: Out-of-bounds Read •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47096 – ALSA: rawmidi - fix the uninitalized user_pversion
https://notcve.org/view.php?id=CVE-2021-47096
In the Linux kernel, the following vulnerability has been resolved: ALSA: rawmidi - fix the uninitalized user_pversion The user_pversion was uninitialized for the user space file structure in the open function, because the file private structure use kmalloc for the allocation. The kernel ALSA sequencer code clears the file structure, so no additional fixes are required. BugLink: https://github.com/alsa-project/alsa-lib/issues/178 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ALSA: rawmidi: corrige la user_pversion no inicializada. La user_pversion no se inicializó para la estructura de archivos del espacio de usuario en la función abierta, porque la estructura privada del archivo usa kmalloc para la asignación. El código del secuenciador ALSA del kernel borra la estructura del archivo, por lo que no se requieren correcciones adicionales. Enlace de error: https://github.com/alsa-project/alsa-lib/issues/178 • https://git.kernel.org/stable/c/09d23174402da0f10e98da2c61bb5ac8e7d79fdd https://git.kernel.org/stable/c/12d50801497235956fb3760be8530f4e44e4ce67 https://git.kernel.org/stable/c/b398fcbe4de1e1100867fdb6f447c6fbc8fe7085 https://git.kernel.org/stable/c/39a8fc4971a00d22536aeb7d446ee4a97810611b •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47095 – ipmi: ssif: initialize ssif_info->client early
https://notcve.org/view.php?id=CVE-2021-47095
In the Linux kernel, the following vulnerability has been resolved: ipmi: ssif: initialize ssif_info->client early During probe ssif_info->client is dereferenced in error path. However, it is set when some of the error checking has already been done. This causes following kernel crash if an error path is taken: [ 30.645593][ T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present [ 30.657616][ T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088 ... [ 30.657723][ T674] pc : __dev_printk+0x28/0xa0 [ 30.657732][ T674] lr : _dev_err+0x7c/0xa0 ... [ 30.657772][ T674] Call trace: [ 30.657775][ T674] __dev_printk+0x28/0xa0 [ 30.657778][ T674] _dev_err+0x7c/0xa0 [ 30.657781][ T674] ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e] [ 30.657791][ T674] i2c_device_probe+0x37c/0x3c0 ... Initialize ssif_info->client before any error path can be taken. Clear i2c_client data in the error path to prevent the dangling pointer from leaking. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipmi: ssif: inicializa ssif_info->client temprano Durante la sonda, ssif_info->client se desreferencia en la ruta de error. • https://git.kernel.org/stable/c/c4436c9149c5d2bc0c49ab57ec85c75ea1c4d61c https://git.kernel.org/stable/c/8efd6a3391f7b0b19fb0c38e50add06ca30c94af https://git.kernel.org/stable/c/1f6ab847461ce7dd89ae9db2dd4658c993355d7c https://git.kernel.org/stable/c/77a7311ca167aa5b7055c549a940a56e73ee5f29 https://git.kernel.org/stable/c/34f35f8f14bc406efc06ee4ff73202c6fd245d15 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47094 – KVM: x86/mmu: Don't advance iterator after restart due to yielding
https://notcve.org/view.php?id=CVE-2021-47094
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Don't advance iterator after restart due to yielding After dropping mmu_lock in the TDP MMU, restart the iterator during tdp_iter_next() and do not advance the iterator. Advancing the iterator results in skipping the top-level SPTE and all its children, which is fatal if any of the skipped SPTEs were not visited before yielding. When zapping all SPTEs, i.e. when min_level == root_level, restarting the iter and then invoking tdp_iter_next() is always fatal if the current gfn has as a valid SPTE, as advancing the iterator results in try_step_side() skipping the current gfn, which wasn't visited before yielding. Sprinkle WARNs on iter->yielded being true in various helpers that are often used in conjunction with yielding, and tag the helper with __must_check to reduce the probabily of improper usage. Failing to zap a top-level SPTE manifests in one of two ways. If a valid SPTE is skipped by both kvm_tdp_mmu_zap_all() and kvm_tdp_mmu_put_root(), the shadow page will be leaked and KVM will WARN accordingly. WARNING: CPU: 1 PID: 3509 at arch/x86/kvm/mmu/tdp_mmu.c:46 [kvm] RIP: 0010:kvm_mmu_uninit_tdp_mmu+0x3e/0x50 [kvm] Call Trace: <TASK> kvm_arch_destroy_vm+0x130/0x1b0 [kvm] kvm_destroy_vm+0x162/0x2a0 [kvm] kvm_vcpu_release+0x34/0x60 [kvm] __fput+0x82/0x240 task_work_run+0x5c/0x90 do_exit+0x364/0xa10 ? futex_unqueue+0x38/0x60 do_group_exit+0x33/0xa0 get_signal+0x155/0x850 arch_do_signal_or_restart+0xed/0x750 exit_to_user_mode_prepare+0xc5/0x120 syscall_exit_to_user_mode+0x1d/0x40 do_syscall_64+0x48/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae If kvm_tdp_mmu_zap_all() skips a gfn/SPTE but that SPTE is then zapped by kvm_tdp_mmu_put_root(), KVM triggers a use-after-free in the form of marking a struct page as dirty/accessed after it has been put back on the free list. This directly triggers a WARN due to encountering a page with page_count() == 0, but it can also lead to data corruption and additional errors in the kernel. WARNING: CPU: 7 PID: 1995658 at arch/x86/kvm/../../.. • https://git.kernel.org/stable/c/faaf05b00aecdb347ffd1d763d024394ec0329f8 https://git.kernel.org/stable/c/3c7a18440638b1c5a4645e2de1670cee32df7307 https://git.kernel.org/stable/c/d884eefd75cc54887bc2e9e724207443525dfb2c https://git.kernel.org/stable/c/3a0f64de479cae75effb630a2e0a237ca0d0623c •