CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48698 – drm/amd/display: fix memory leak when using debugfs_lookup()
https://notcve.org/view.php?id=CVE-2022-48698
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix memory leak when using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. Fix this up by properly calling dput(). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: soluciona la pérdida de memoria al usar debugfs_lookup() Al llamar a debugfs_lookup(), el resultado debe tener llamado dput(); de lo contrario, la memoria se perderá con el tiempo. Solucione este problema llamando correctamente a dput(). • https://git.kernel.org/stable/c/58acd2ebae034db3bacf38708f508fbd12ae2e54 https://git.kernel.org/stable/c/3a6279d243cb035eaaff1450980b40cf19748f05 https://git.kernel.org/stable/c/cbfac7fa491651c57926c99edeb7495c6c1aeac2 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48697 – nvmet: fix a use-after-free
https://notcve.org/view.php?id=CVE-2022-48697
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a use-after-free Fix the following use-after-free complaint triggered by blktests nvme/004: BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e print_report.cold+0x36/0x1e2 kasan_report+0xb9/0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet] nvmet_req_complete+0x15/0x40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [nvme_loop] process_one_work+0x56e/0xa70 worker_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet: corrige un use-after-free. Solucione la siguiente queja de use-after-free activada por blktests nvme/004: ERROR: KASAN: acceso a la memoria del usuario en blk_mq_complete_request_remote+0xac /0x350 Lectura de tamaño 4 en la dirección 0000607bd1835943 por tarea kworker/13:1/460 Cola de trabajo: nvmet-wq nvme_loop_execute_work [nvme_loop] Seguimiento de llamadas: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e /0x1e2 informe_kasan+0xb9 /0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet_req_complete+0x15/0x 40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [ nvme_loop] proceso_one_work+0x56e/0xa70 trabajador_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30 • https://git.kernel.org/stable/c/a07b4970f464f13640e28e16dad6cfa33647cc99 https://git.kernel.org/stable/c/17f121ca3ec6be0fb32d77c7f65362934a38cc8e https://git.kernel.org/stable/c/8d66989b5f7bb28bba2f8e1e2ffc8bfef4a10717 https://git.kernel.org/stable/c/be01f1c988757b95f11f090a9f491365670a522b https://git.kernel.org/stable/c/ebf46da50beb78066674354ad650606a467e33fa https://git.kernel.org/stable/c/4484ce97a78171668c402e0c45db7f760aea8060 https://git.kernel.org/stable/c/6a02a61e81c231cc5c680c5dbf8665275147ac52 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48696 – regmap: spi: Reserve space for register address/padding
https://notcve.org/view.php?id=CVE-2022-48696
In the Linux kernel, the following vulnerability has been resolved: regmap: spi: Reserve space for register address/padding Currently the max_raw_read and max_raw_write limits in regmap_spi struct do not take into account the additional size of the transmitted register address and padding. This may result in exceeding the maximum permitted SPI message size, which could cause undefined behaviour, e.g. data corruption. Fix regmap_get_spi_bus() to properly adjust the above mentioned limits by reserving space for the register address/padding as set in the regmap configuration. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regmap: spi: reserva de espacio para dirección/relleno de registro Actualmente, los límites max_raw_read y max_raw_write en la estructura regmap_spi no tienen en cuenta el tamaño adicional de la dirección de registro transmitida y el relleno. Esto puede dar como resultado que se exceda el tamaño de mensaje SPI máximo permitido, lo que podría causar un comportamiento indefinido, por ejemplo, corrupción de datos. Corrija regmap_get_spi_bus() para ajustar adecuadamente los límites mencionados anteriormente reservando espacio para la dirección/relleno del registro como se establece en la configuración de regmap. • https://git.kernel.org/stable/c/f231ff38b7b23197013b437128d196710fe282da https://git.kernel.org/stable/c/15ff1f17847c19174b260bd7dd0de33edcebd45e https://git.kernel.org/stable/c/f5723cfc01932c7a8d5c78dbf7e067e537c91439 •
CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48694 – RDMA/irdma: Fix drain SQ hang with no completion
https://notcve.org/view.php?id=CVE-2022-48694
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix drain SQ hang with no completion SW generated completions for outstanding WRs posted on SQ after QP is in error target the wrong CQ. This causes the ib_drain_sq to hang with no completion. Fix this to generate completions on the right CQ. [ 863.969340] INFO: task kworker/u52:2:671 blocked for more than 122 seconds. [ 863.979224] Not tainted 5.14.0-130.el9.x86_64 #1 [ 863.986588] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 863.996997] task:kworker/u52:2 state:D stack: 0 pid: 671 ppid: 2 flags:0x00004000 [ 864.007272] Workqueue: xprtiod xprt_autoclose [sunrpc] [ 864.014056] Call Trace: [ 864.017575] __schedule+0x206/0x580 [ 864.022296] schedule+0x43/0xa0 [ 864.026736] schedule_timeout+0x115/0x150 [ 864.032185] __wait_for_common+0x93/0x1d0 [ 864.037717] ? usleep_range_state+0x90/0x90 [ 864.043368] __ib_drain_sq+0xf6/0x170 [ib_core] [ 864.049371] ? __rdma_block_iter_next+0x80/0x80 [ib_core] [ 864.056240] ib_drain_sq+0x66/0x70 [ib_core] [ 864.062003] rpcrdma_xprt_disconnect+0x82/0x3b0 [rpcrdma] [ 864.069365] ? xprt_prepare_transmit+0x5d/0xc0 [sunrpc] [ 864.076386] xprt_rdma_close+0xe/0x30 [rpcrdma] [ 864.082593] xprt_autoclose+0x52/0x100 [sunrpc] [ 864.088718] process_one_work+0x1e8/0x3c0 [ 864.094170] worker_thread+0x50/0x3b0 [ 864.099109] ? • https://git.kernel.org/stable/c/81091d7696ae71627ff80bbf2c6b0986d2c1cce3 https://git.kernel.org/stable/c/5becc531a3fa8da75158a8993f56cc3e0717716e https://git.kernel.org/stable/c/ead54ced6321099978d30d62dc49c282a6e70574 https://git.kernel.org/stable/c/14d148401c5202fec3a071e24785481d540b22c3 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48693 – soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs
https://notcve.org/view.php?id=CVE-2022-48693
In the Linux kernel, the following vulnerability has been resolved: soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs In brcmstb_pm_probe(), there are two kinds of leak bugs: (1) we need to add of_node_put() when for_each__matching_node() breaks (2) we need to add iounmap() for each iomap in fail path En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: soc: brcmstb: pm-arm: corrige los errores de fuga de refcount y __iomem En brcmstb_pm_probe(), hay dos tipos de errores de fuga: (1) necesitamos agregar of_node_put() cuando for_each__matching_node() se rompe (2) necesitamos agregar iounmap() para cada iomap en la ruta de error • https://git.kernel.org/stable/c/0b741b8234c86065fb6954d32d427b3f7e14756f https://git.kernel.org/stable/c/0284b4e6dec6088a41607aa3f42bf51edff01883 https://git.kernel.org/stable/c/57b2897ec3ffe4cbe018446be6d04432919dca6b https://git.kernel.org/stable/c/6dc0251638a4a1a998506dbd4627f8317e907558 https://git.kernel.org/stable/c/43245c77d9efd8c9eb91bf225d07954dcf32204d https://git.kernel.org/stable/c/653500b400d5576940b7429690f7197199ddcc82 https://git.kernel.org/stable/c/1085f5080647f0c9f357c270a537869191f7f2a1 • CWE-401: Missing Release of Memory after Effective Lifetime •