CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46971 – perf/core: Fix unconditional security_locked_down() call
https://notcve.org/view.php?id=CVE-2021-46971
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown state is queried unconditionally, even though its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesn't matter in case of the Lockdown LSM, it causes trouble with the SELinux's lockdown hook implementation. SELinux implements the locked_down hook with a check whether the current task's type has the corresponding "lockdown" class permission ("integrity" or "confidentiality") allowed in the policy. This means that calling the hook when the access control decision would be ignored generates a bogus permission check and audit record. Fix this by checking sample_type first and only calling the hook when its result would be honored. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf/core: corrige la llamada incondicional a security_locked_down() Actualmente, el estado de bloqueo se consulta incondicionalmente, aunque su resultado se usa solo si el bit PERF_SAMPLE_REGS_INTR está establecido en attr.sample_type. Si bien eso no importa en el caso del Lockdown LSM, causa problemas con la implementación del gancho de bloqueo de SELinux. • https://git.kernel.org/stable/c/b0c8fdc7fdb77586c3d1937050925b960743306e https://git.kernel.org/stable/c/b246759284d6a2bc5b6f1009caeeb3abce2ec9ff https://git.kernel.org/stable/c/4348d3b5027bc3ff6336368b6c60605d4ef8e1ce https://git.kernel.org/stable/c/f5809ca4c311b71bfaba6d13f4e39eab0557895e https://git.kernel.org/stable/c/c7b0208ee370b89d20486fae71cd9abb759819c1 https://git.kernel.org/stable/c/08ef1af4de5fe7de9c6d69f1e22e51b66e385d9b •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2021-46966 – ACPI: custom_method: fix potential use-after-free issue
https://notcve.org/view.php?id=CVE-2021-46966
In the Linux kernel, the following vulnerability has been resolved: ACPI: custom_method: fix potential use-after-free issue In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPI: custom_method: soluciona un posible problema de use-after-free En cm_write(), buf siempre se libera al llegar al final de la función. Si el recuento solicitado es menor que table.length, el búfer asignado se liberará, pero las llamadas posteriores a cm_write() seguirán intentando acceder a él. Elimine el kfree(buf) incondicional al final de la función y establezca el buf en NULL en la ruta de error -EINVAL para que coincida con el resto de la función. • https://git.kernel.org/stable/c/4bda2b79a9d04c8ba31681c66e95877dbb433416 https://git.kernel.org/stable/c/5c12dadcbef8cd55ef1f5dac799bfcbb7ea7db1d https://git.kernel.org/stable/c/35b88a10535edcf62d3e6b7893a8cd506ff98a24 https://git.kernel.org/stable/c/e4467fb6ef547aa352dc03397f9474ec84eced5b https://git.kernel.org/stable/c/03d1571d9513369c17e6848476763ebbd10ec2cb https://git.kernel.org/stable/c/70424999fbf1f160ade111cb9baab51776e0f9c2 https://git.kernel.org/stable/c/06cd4a06eb596a888239fb8ceb6ea15677cab396 https://git.kernel.org/stable/c/1d53ca5d131074c925ce38361fb0376d3 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-46963 – scsi: qla2xxx: Fix crash in qla2xxx_mqueuecommand()
https://notcve.org/view.php?id=CVE-2021-46963
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash in qla2xxx_mqueuecommand() RIP: 0010:kmem_cache_free+0xfa/0x1b0 Call Trace: qla2xxx_mqueuecommand+0x2b5/0x2c0 [qla2xxx] scsi_queue_rq+0x5e2/0xa40 __blk_mq_try_issue_directly+0x128/0x1d0 blk_mq_request_issue_directly+0x4e/0xb0 Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb is now allocated by upper layers. This fixes smatch warning of srb unintended free. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: qla2xxx: Soluciona falla en qla2xxx_mqueuecommand() RIP: 0010:kmem_cache_free+0xfa/0x1b0 Rastreo de llamadas: qla2xxx_mqueuecommand+0x2b5/0x2c0 [qla2xxx] scsi_queue_rq+0x5e2/0xa40 __blk_mq_try_issue_ directamente+0x128 /0x1d0 blk_mq_request_issue_directly+0x4e/0xb0 Se corrigió la llamada incorrecta para liberar srb en qla2xxx_mqueuecommand(), ya que srb ahora está asignado por capas superiores. Esto corrige la advertencia de srb gratuito no deseado. • https://git.kernel.org/stable/c/64a8c5018a4b21b04a756a56c495ef47c14e92d9 https://git.kernel.org/stable/c/dea6ee7173039d489977c9ed92e3749154615db4 https://git.kernel.org/stable/c/af2a0c51b1205327f55a7e82e530403ae1d42cbb https://git.kernel.org/stable/c/4a1cc2f71bc57cf8dee6f58e7d2355a43aabb312 https://git.kernel.org/stable/c/c5ab9b67d8b061de74e2ca51bf787ee599bd7f89 https://git.kernel.org/stable/c/77509a238547863040a42d57c72403f7d4c89a8f https://git.kernel.org/stable/c/702cdaa2c6283c135ef16d52e0e4e3c1005aa538 https://git.kernel.org/stable/c/80ef24175df2cba3860d0369d1c662b49 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46962 – mmc: uniphier-sd: Fix a resource leak in the remove function
https://notcve.org/view.php?id=CVE-2021-46962
In the Linux kernel, the following vulnerability has been resolved: mmc: uniphier-sd: Fix a resource leak in the remove function A 'tmio_mmc_host_free()' call is missing in the remove function, in order to balance a 'tmio_mmc_host_alloc()' call in the probe. This is done in the error handling path of the probe, but not in the remove function. Add the missing call. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mmc: uniphier-sd: corrige una fuga de recursos en la función de eliminación Falta una llamada 'tmio_mmc_host_free()' en la función de eliminación, para equilibrar un 'tmio_mmc_host_alloc()' llamar a la sonda. Esto se hace en la ruta de manejo de errores de la sonda, pero no en la función de eliminación. Agrega la llamada faltante. • https://git.kernel.org/stable/c/3fd784f745dd1747863775a99ec749619ee6759c https://git.kernel.org/stable/c/0d8941b9b2d3e7b3481fdf43b1a6189d162175b7 https://git.kernel.org/stable/c/25ac6ce65f1ab458982d15ec1caf441acd37106a https://git.kernel.org/stable/c/ebe0f12cf4c044f812c6d17011531582f9ac8bb3 https://git.kernel.org/stable/c/d6e7fda496978f2763413b5523557b38dc2bf6c2 https://git.kernel.org/stable/c/e29c84857e2d51aa017ce04284b962742fb97d9e •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46961 – irqchip/gic-v3: Do not enable irqs when handling spurious interrups
https://notcve.org/view.php?id=CVE-2021-46961
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Do not enable irqs when handling spurious interrups We triggered the following error while running our 4.19 kernel with the pseudo-NMI patches backported to it: [ 14.816231] ------------[ cut here ]------------ [ 14.816231] kernel BUG at irq.c:99! [ 14.816232] Internal error: Oops - BUG: 0 [#1] SMP [ 14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____)) [ 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.95.aarch64 #14 [ 14.816233] Hardware name: evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter+0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0 [ 14.816238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff [ 14.816243] x17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000 [ 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 : 0000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000 [ 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0 [ 14.816251] Call trace: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [ 14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254] __handle_domain_irq+0x68/0xc0 [ 14.816254] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle+0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.816256] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000) [ 14.816258] Modules linked in: start_dp(O) smeth(O) [ 15.103092] ---[ end trace 701753956cb14aa8 ]--- [ 15.103093] Kernel panic - not syncing: Fatal exception in interrupt [ 15.103099] SMP: stopping secondary CPUs [ 15.103100] Kernel Offset: disabled [ 15.103100] CPU features: 0x36,a2400218 [ 15.103100] Memory Limit: none which is cause by a 'BUG_ON(in_nmi())' in nmi_enter(). From the call trace, we can find three interrupts (noted A, B, C above): interrupt (A) is preempted by (B), which is further interrupted by (C). Subsequent investigations show that (B) results in nmi_enter() being called, but that it actually is a spurious interrupt. Furthermore, interrupts are reenabled in the context of (B), and (C) fires with NMI priority. We end-up with a nested NMI situation, something we definitely do not want to (and cannot) handle. The bug here is that spurious interrupts should never result in any state change, and we should just return to the interrupted context. Moving the handling of spurious interrupts as early as possible in the GICv3 handler fixes this issue. [maz: rewrote commit message, corrected Fixes: tag] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: irqchip/gic-v3: no habilitar irqs cuando se manejan interrupciones espurias. Activamos el siguiente error al ejecutar nuestro kernel 4.19 con los parches pseudo-NMI respaldados: [14.816231] - -----------[ cortar aquí ]------------ ¡ERROR del kernel [14.816231] en irq.c:99! • https://git.kernel.org/stable/c/3f1f3234bc2db1c16b9818b9a15a5d58ad45251c https://git.kernel.org/stable/c/e7ea8e46e3b777be26aa855fe07778c415f24926 https://git.kernel.org/stable/c/7be4db5c2b59fa77071c93ca4329876fb9777202 https://git.kernel.org/stable/c/ea817ac1014c04f47885532b55f5d0898deadfba https://git.kernel.org/stable/c/3f72d3709f53af72835af7dc8b15ba61611a0e36 https://git.kernel.org/stable/c/a97709f563a078e259bf0861cd259aa60332890a •