CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46952 – NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds
https://notcve.org/view.php?id=CVE-2021-46952
In the Linux kernel, the following vulnerability has been resolved: NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused by a garbage timeout (retrans) mount option being passed to nfs mount, in this case from syzkaller. If the protocol is XPRT_TRANSPORT_UDP, then 'retrans' is a shift value for a 64-bit long integer, so 'retrans' cannot be >= 64. If it is >= 64, fail the mount and return an error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: fs_context: valida las retransmisiones UDP para evitar cambios fuera de los límites. Corrige cambios fuera de los límites en xprt_calc_majortimeo(). Esto se debe a que se pasa una opción de montaje de tiempo de espera de basura (retransmisión) al montaje nfs, en este caso desde syzkaller. • https://git.kernel.org/stable/c/9954bf92c0cddd50a2a470be302e1c1ffdf21d42 https://git.kernel.org/stable/c/96fa26b74cdcf9f5c98996bf36bec9fb5b19ffe2 https://git.kernel.org/stable/c/2f3380121d49e829fb73ba86240c181bc32ad897 https://git.kernel.org/stable/c/3d0163821c035040a46d816a42c0780f0f0a30a8 https://git.kernel.org/stable/c/c09f11ef35955785f92369e25819bf0629df2e59 • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46951 – tpm: efi: Use local variable for calculating final log size
https://notcve.org/view.php?id=CVE-2021-46951
In the Linux kernel, the following vulnerability has been resolved: tpm: efi: Use local variable for calculating final log size When tpm_read_log_efi is called multiple times, which happens when one loads and unloads a TPM2 driver multiple times, then the global variable efi_tpm_final_log_size will at some point become a negative number due to the subtraction of final_events_preboot_size occurring each time. Use a local variable to avoid this integer underflow. The following issue is now resolved: Mar 8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Mar 8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20 Mar 8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 Mar 8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 Mar 8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f Mar 8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d Mar 8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073 Mar 8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 Mar 8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 Mar 8 15:35:12 hibinst kernel: FS: 0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000 Mar 8 15:35:12 hibinst kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 Mar 8 15:35:12 hibinst kernel: Call Trace: Mar 8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7 Mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 Mar 8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260 Mar 8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370 Mar 8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0 Mar 8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tpm: efi: use la variable local para calcular el tamaño del registro final Cuando se llama a tpm_read_log_efi varias veces, lo que sucede cuando uno carga y descarga un controlador TPM2 varias veces, entonces la variable global efi_tpm_final_log_size en algún momento se convierte en un número negativo debido a la resta de final_events_preboot_size que ocurre cada vez. Utilice una variable local para evitar este desbordamiento de enteros. El siguiente problema ahora está resuelto: 8 de marzo 15:35:12 kernel hibinst: Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 0.0.0 06/02/2015 8 de marzo 15:35:12 kernel hibinst: Cola de trabajo: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] 8 de marzo 15:35:12 kernel de hibinst: RIP: 0010:__memcpy+0x12/0x20 8 de marzo 15:35:12 kernel de hibinst: Código: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 8 de marzo 15:35:12 kernel de hibinst: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 8 de marzo 15:35:12 kernel de hibinst: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ff ffffffffffe0f 8 de marzo 15:35:12 kernel de hibinst: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d 8 de marzo 15:35:12 kernel de hibinst: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000 000007e9d6073 8 de marzo 15:35:12 kernel hibinst: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 8 de marzo 15:35:12 kernel de hibinst: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 8 de marzo 15:35:12 kernel de hibinst: FS: 0000000000000000(0000) GS:ffff8 8f87bd00000(0000) knlGS:0000000000000000 8 de marzo a las 15:35: 12 kernel de hibinst: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 8 de marzo 15:35:12 kernel de hibinst: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 8 de marzo 15:35:12 kernel de hibinst: Seguimiento de llamadas: 8 de marzo 15:35:12 Hibinst Kernel: tpm_read_log_efi+0x152/0x1a7 mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 mar 8 15:35:12 hibinst kernel: tpm_chip_register kernel de hibinst: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] 8 de marzo 15:35:12 kernel de hibinst: Process_one_work+0x1b4/0x370 8 de marzo 15:35:12 kernel de hibinst: work_thread+0x53/0x3e0 8 de marzo 15:35:12 kernel de hibinst : ? • https://git.kernel.org/stable/c/166a2809d65b282272c474835ec22c882a39ca1b https://git.kernel.org/stable/c/2f12258b5224cfaa808c54fd29345f3c1cbfca76 https://git.kernel.org/stable/c/60a01ecc9f68067e4314a0b55148e39e5d58a51b https://git.kernel.org/stable/c/3818b753277f5ca0c170bf5b98e0a5a225542fcb https://git.kernel.org/stable/c/ac07c557ca12ec9276c0375517bac7ae5be4e50c https://git.kernel.org/stable/c/48cff270b037022e37835d93361646205ca25101 • CWE-191: Integer Underflow (Wrap or Wraparound) •
CVSS: 7.8EPSS: 0%CPEs: 9EXPL: 0CVE-2021-46950 – md/raid1: properly indicate failure when ending a failed write request
https://notcve.org/view.php?id=CVE-2021-46950
In the Linux kernel, the following vulnerability has been resolved: md/raid1: properly indicate failure when ending a failed write request This patch addresses a data corruption bug in raid1 arrays using bitmaps. Without this fix, the bitmap bits for the failed I/O end up being cleared. Since we are in the failure leg of raid1_end_write_request, the request either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid1: indica correctamente el error al finalizar una solicitud de escritura fallida. Este parche soluciona un error de corrupción de datos en matrices raid1 que utilizan mapas de bits. Sin esta solución, los bits del mapa de bits de la E/S fallida terminan borrándose. Dado que estamos en el tramo fallido de raid1_end_write_request, es necesario volver a intentar la solicitud (R1BIO_WriteError) o fallar (R1BIO_Degraded). • https://git.kernel.org/stable/c/900c531899f5ee2321bef79e20055787bc73251d https://git.kernel.org/stable/c/1cd972e0a10760a1fa27d9830d78446c891c23b6 https://git.kernel.org/stable/c/eeba6809d8d58908b5ed1b5ceb5fcb09a98a7cad https://git.kernel.org/stable/c/a1f4fcb880988a96c0b2d5c3305ffc4e49eca0ed https://git.kernel.org/stable/c/344242d50f468a250bf4b6136934392758412ed8 https://git.kernel.org/stable/c/12216d0919b64ee2ea5dc7a50e455670f44383d5 https://git.kernel.org/stable/c/a6e17cab00fc5bf85472434c52ac751426257c6f https://git.kernel.org/stable/c/6920cef604fa57f9409e3960413e9cc11 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46949 – sfc: farch: fix TX queue lookup in TX flush done handling
https://notcve.org/view.php?id=CVE-2021-46949
In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX flush done handling We're starting from a TXQ instance number ('qid'), not a TXQ type, so efx_get_tx_queue() is inappropriate (and could return NULL, leading to panics). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: farch: corrige la búsqueda de la cola TX en el manejo finalizado del vaciado TX. Estamos comenzando desde un número de instancia TXQ ('qid'), no un tipo TXQ, por lo que efx_get_tx_queue() es inapropiado (y podría devolver NULL, lo que provocaría pánico). • https://git.kernel.org/stable/c/12804793b17c0e19115a90d98f2f3df0cb79e233 https://git.kernel.org/stable/c/fb791572d6747ef385f628450f8d57cd132e6e5a https://git.kernel.org/stable/c/a1570985ec04116cc665b760faf666a104154170 https://git.kernel.org/stable/c/98d91180748986bfb6dfb3e72765f3225719a647 https://git.kernel.org/stable/c/5b1faa92289b53cad654123ed2bc8e10f6ddd4ac • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46948 – sfc: farch: fix TX queue lookup in TX event handling
https://notcve.org/view.php?id=CVE-2021-46948
In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX event handling We're starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate (and could return NULL, leading to panics). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: farch: corrige la búsqueda de cola TX en el manejo de eventos TX Estamos comenzando desde una etiqueta TXQ, no un tipo TXQ, por lo que efx_channel_get_tx_queue() es inapropiado (y podría devolver NULL, provocando pánico). • https://git.kernel.org/stable/c/12804793b17c0e19115a90d98f2f3df0cb79e233 https://git.kernel.org/stable/c/bf2b941d0a6f2d3b9f5fa3c4c21bdd54f71ce253 https://git.kernel.org/stable/c/35c7a83ad1bb1d48ae249346e61b1132bcbf9052 https://git.kernel.org/stable/c/e531db1ea6f98c9612cb2de093a107c7eadfb96c https://git.kernel.org/stable/c/83b09a1807415608b387c7bc748d329fefc5617e • CWE-476: NULL Pointer Dereference •