CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47467 – kunit: fix reference count leak in kfree_at_end
https://notcve.org/view.php?id=CVE-2021-47467
In the Linux kernel, the following vulnerability has been resolved: kunit: fix reference count leak in kfree_at_end The reference counting issue happens in the normal path of kfree_at_end(). When kunit_alloc_and_get_resource() is invoked, the function forgets to handle the returned resource object, whose refcount increased inside, causing a refcount leak. Fix this issue by calling kunit_alloc_resource() instead of kunit_alloc_and_get_resource(). Fixed the following when applying: Shuah Khan <skhan@linuxfoundation.org> CHECK: Alignment should match open parenthesis + kunit_alloc_resource(test, NULL, kfree_res_free, GFP_KERNEL, (void *)to_free); En el kernel de Linux, se resolvió la siguiente vulnerabilidad: kunit: corrige la fuga del recuento de referencias en kfree_at_end El problema del recuento de referencias ocurre en la ruta normal de kfree_at_end(). Cuando se invoca kunit_alloc_and_get_resource(), la función se olvida de manejar el objeto de recurso devuelto, cuyo recuento aumentó en el interior, lo que provoca una fuga de recuento. Solucione este problema llamando a kunit_alloc_resource() en lugar de kunit_alloc_and_get_resource(). Se corrigió lo siguiente al aplicar: Shuah Khan VERIFICAR: La alineación debe coincidir con el paréntesis abierto + kunit_alloc_resource(test, NULL, kfree_res_free, GFP_KERNEL, (void *)to_free); • https://git.kernel.org/stable/c/bbdd158b40b66a9403391a517f24ef6613573446 https://git.kernel.org/stable/c/f62314b1ced25c58b86e044fc951cd6a1ea234cf •
CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47466 – mm, slub: fix potential memoryleak in kmem_cache_open()
https://notcve.org/view.php?id=CVE-2021-47466
In the Linux kernel, the following vulnerability has been resolved: mm, slub: fix potential memoryleak in kmem_cache_open() In error path, the random_seq of slub cache might be leaked. Fix this by using __kmem_cache_release() to release all the relevant resources. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm, slub: corrige una posible pérdida de memoria en kmem_cache_open() En la ruta del error, es posible que se haya filtrado el random_seq del caché slub. Solucione este problema usando __kmem_cache_release() para liberar todos los recursos relevantes. • https://git.kernel.org/stable/c/210e7a43fa905bccafa9bb5966fba1d71f33eb8b https://git.kernel.org/stable/c/4f5d1c29cfab5cb0ab885059818751bdef32e2bb https://git.kernel.org/stable/c/568f906340b43120abd6fcc67c37396482f85930 https://git.kernel.org/stable/c/42b81946e3ac9ea0372ba16e05160dc11e02694f https://git.kernel.org/stable/c/9037c57681d25e4dcc442d940d6dbe24dd31f461 https://access.redhat.com/security/cve/CVE-2021-47466 https://bugzilla.redhat.com/show_bug.cgi?id=2282890 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47465 – KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest()
https://notcve.org/view.php?id=CVE-2021-47465
In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: Fix stack handling in idle_kvm_start_guest() In commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C") kvm_start_guest() became idle_kvm_start_guest(). The old code allocated a stack frame on the emergency stack, but didn't use the frame to store anything, and also didn't store anything in its caller's frame. idle_kvm_start_guest() on the other hand is written more like a normal C function, it creates a frame on entry, and also stores CR/LR into its callers frame (per the ABI). The problem is that there is no caller frame on the emergency stack. The emergency stack for a given CPU is allocated with: paca_ptrs[i]->emergency_sp = alloc_stack(limit, i) + THREAD_SIZE; So emergency_sp actually points to the first address above the emergency stack allocation for a given CPU, we must not store above it without first decrementing it to create a frame. This is different to the regular kernel stack, paca->kstack, which is initialised to point at an initial frame that is ready to use. idle_kvm_start_guest() stores the backchain, CR and LR all of which write outside the allocation for the emergency stack. It then creates a stack frame and saves the non-volatile registers. • https://git.kernel.org/stable/c/10d91611f426d4bafd2a83d966c36da811b2f7ad https://git.kernel.org/stable/c/80bbb0bc3a0288442f7fe6fc514f4ee1cb06ccb7 https://git.kernel.org/stable/c/fbd724c49bead048ae9fc1a5b7bff2fb3e54f855 https://git.kernel.org/stable/c/6d077c37c4643394b1bae9682da48164fc147ea8 https://git.kernel.org/stable/c/9b4416c5095c20e110c82ae602c254099b83b72f •
CVSS: 7.4EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47464 – audit: fix possible null-pointer dereference in audit_filter_rules
https://notcve.org/view.php?id=CVE-2021-47464
In the Linux kernel, the following vulnerability has been resolved: audit: fix possible null-pointer dereference in audit_filter_rules Fix possible null-pointer dereference in audit_filter_rules. audit_filter_rules() error: we previously assumed 'ctx' could be null En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: auditoría: corrige una posible desreferencia de puntero nulo en audit_filter_rules. Corrige una posible desreferencia de puntero nulo en audit_filter_rules. Error audit_filter_rules(): previamente asumimos que 'ctx' podría ser nulo • https://git.kernel.org/stable/c/bf361231c295d92a28ca283ea713f56e93e55796 https://git.kernel.org/stable/c/d6f451f1f60c58d73038c7c3177066f8f084e2a2 https://git.kernel.org/stable/c/16802fa4c33eb1a8efb23f1e93365190e4047d05 https://git.kernel.org/stable/c/4e9e46a700201b4c85081fd478c99c692a9aaa0d https://git.kernel.org/stable/c/6e3ee990c90494561921c756481d0e2125d8b895 • CWE-476: NULL Pointer Dereference •
CVSS: 7.0EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47461 – userfaultfd: fix a race between writeprotect and exit_mmap()
https://notcve.org/view.php?id=CVE-2021-47461
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix a race between writeprotect and exit_mmap() A race is possible when a process exits, its VMAs are removed by exit_mmap() and at the same time userfaultfd_writeprotect() is called. The race was detected by KASAN on a development kernel, but it appears to be possible on vanilla kernels as well. Use mmget_not_zero() to prevent the race as done in other userfaultfd operations. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: userfaultfd: corrige una ejecución entre writeprotect y exit_mmap() Una ejecución es posible cuando un proceso sale, sus VMA son eliminados por exit_mmap() y al mismo tiempo se llama a userfaultfd_writeprotect() . KASAN detectó la ejecución en un núcleo de desarrollo, pero parece ser posible también en núcleos de vainilla. Utilice mmget_not_zero() para evitar la ejecución como se hace en otras operaciones de userfaultfd. • https://git.kernel.org/stable/c/63b2d4174c4ad1f40b48d7138e71bcb564c1fe03 https://git.kernel.org/stable/c/3cda4bfffd4f755645577aaa9e96a606657b4525 https://git.kernel.org/stable/c/149958ecd0627a9f1e9c678c25c665400054cd6a https://git.kernel.org/stable/c/cb185d5f1ebf900f4ae3bf84cee212e6dd035aca https://access.redhat.com/security/cve/CVE-2021-47461 https://bugzilla.redhat.com/show_bug.cgi?id=2282896 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •