CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46944 – media: staging/intel-ipu3: Fix memory leak in imu_fmt
https://notcve.org/view.php?id=CVE-2021-46944
In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix memory leak in imu_fmt We are losing the reference to an allocated memory if try. Change the order of the check to avoid that. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: staging/intel-ipu3: Reparar pérdida de memoria en imu_fmt Estamos perdiendo la referencia a una memoria asignada si lo intentamos. Cambie el orden del cheque para evitarlo. • https://git.kernel.org/stable/c/6d5f26f2e045f2377b524516194657c00efbbce8 https://git.kernel.org/stable/c/ff792ae52005c85a2d829c153e08d99a356e007d https://git.kernel.org/stable/c/517f6f570566a863c2422b843c8b7d099474f6a9 https://git.kernel.org/stable/c/14d0e99c3ef6b0648535a31bf2eaabb4eff97b9e https://git.kernel.org/stable/c/74ba0adb5e983503b18a96121d965cad34ac7ce3 https://git.kernel.org/stable/c/3630901933afba1d16c462b04d569b7576339223 • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46943 – media: staging/intel-ipu3: Fix set_fmt error handling
https://notcve.org/view.php?id=CVE-2021-46943
In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix set_fmt error handling If there in an error during a set_fmt, do not overwrite the previous sizes with the invalid config. Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and causing the following OOPs [ 38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes) [ 38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0 [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: staging/intel-ipu3: Corrija el manejo de errores set_fmt Si ocurre un error durante un set_fmt, no sobrescriba los tamaños anteriores con la configuración no válida. Sin este parche, el cumplimiento de v4l2 termina asignando 4 GiB de RAM y provocando los siguientes OOP [38.662975] ipu3-imgu 0000:00:05.0: el búfer swiotlb está lleno (sz: 4096 bytes) [38.662980] DMA: Fuera de SW-IOMMU espacio para 4096 bytes en el dispositivo 0000:00:05.0 [38.663010] falla de protección general: 0000 [#1] PREEMPT SMP • https://git.kernel.org/stable/c/6d5f26f2e045f2377b524516194657c00efbbce8 https://git.kernel.org/stable/c/a03fb1e8a110658215a4cefc3e2ad53279e496a6 https://git.kernel.org/stable/c/c6b81b897f6f9445d57f8d47c4e060ec21556137 https://git.kernel.org/stable/c/34892ea938387d83ffcfb7775ec55f0f80767916 https://git.kernel.org/stable/c/6fb617e37a39db0a3eca4489431359d0bdf3b9bc https://git.kernel.org/stable/c/ad91849996f9dd79741a961fd03585a683b08356 • CWE-131: Incorrect Calculation of Buffer Size •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46941 – usb: dwc3: core: Do core softreset when switch mode
https://notcve.org/view.php?id=CVE-2021-46941
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Do core softreset when switch mode According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. • https://git.kernel.org/stable/c/41ce1456e1dbbc7355d0fcc10cf7c337c13def24 https://git.kernel.org/stable/c/fce7bbcd07d59ac30dba8ce225316b3b4c1c7b50 https://git.kernel.org/stable/c/800f58217626c8b147aa40660e572ed8a0d56e3b https://git.kernel.org/stable/c/1c10fd60c8595ea7ff7e29d3cf1fa88069941da3 https://git.kernel.org/stable/c/f88359e1588b85cf0e8209ab7d6620085f3441d9 •
CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0CVE-2021-46939 – tracing: Restructure trace_clock_global() to never block
https://notcve.org/view.php?id=CVE-2021-46939
In the Linux kernel, the following vulnerability has been resolved: tracing: Restructure trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? • https://git.kernel.org/stable/c/14131f2f98ac350ee9e73faed916d2238a8b6a0d https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4 https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545 https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44 https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534 https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f95006 • CWE-662: Improper Synchronization CWE-833: Deadlock •
CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0CVE-2021-46938 – dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails
https://notcve.org/view.php?id=CVE-2021-46938
In the Linux kernel, the following vulnerability has been resolved: dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails When loading a device-mapper table for a request-based mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following device remove will cause a double free. E.g. (dmesg): device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table. Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0305e098835de000 TEID: 0305e098835de803 Fault in home space mode while using kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: ... lots of modules ... Supported: Yes, External CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3 Hardware name: IBM 8561 T01 7I2 (LPAR) Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Call Trace: [<000000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8c15ac>] system_call+0xd8/0x2c8 Last Breaking-Event-Address: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Kernel panic - not syncing: Fatal exception: panic_on_oops When allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again. Fix this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm rq: corrige la liberación doble de blk_mq_tag_set en dev y se elimina después de que falla la carga de la tabla Al cargar una tabla de mapeador de dispositivos para un dispositivo mapeado basado en solicitudes y la asignación/inicialización de blk_mq_tag_set Si el dispositivo falla, la siguiente eliminación del dispositivo provocará una doble liberación. Por ejemplo, (dmesg): mapeador de dispositivos: núcleo: no se puede inicializar la cola para el dispositivo asignado dm-mq basado en solicitudes mapeador de dispositivos: ioctl: no se puede configurar la cola de dispositivos para una nueva tabla. • https://git.kernel.org/stable/c/1c357a1e86a4227a6b6059f2de118ae47659cebc https://git.kernel.org/stable/c/8ae0185255eaf05bd66f4215c81e99bf01140fd9 https://git.kernel.org/stable/c/b42c0a33dfdd451d9be62dd5de58c39f2750b6e3 https://git.kernel.org/stable/c/772b9f59657665af3b68d24d12b9d172d31f0dfb https://git.kernel.org/stable/c/a992a283c0b77d0a7c2c348add0e6a21fb1dab67 https://git.kernel.org/stable/c/1cb02dc76f4c0a2749a02b26469512d6984252e9 https://git.kernel.org/stable/c/6086f957416a6e87236c06079fcaba7a3998aeca https://git.kernel.org/stable/c/d757bf4c69cda3c3ab7f775dfabbf5a80 • CWE-415: Double Free •