CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52739 – Fix page corruption caused by racy check in __free_pages
https://notcve.org/view.php?id=CVE-2023-52739
Después de dividir el problema en dos, encontramos que el problema comenzó desde la confirmación e320d3012d25 ("mm/page_alloc.c: corrige la liberación de páginas no compuestas"): if (put_page_testzero(page)) free_the_page(page, order); else if (! • https://git.kernel.org/stable/c/e320d3012d25b1fb5f3df4edb7bd44a1c362ec10 https://git.kernel.org/stable/c/830b103831a924a23af48562c4d274696e75ab4f https://git.kernel.org/stable/c/0a626e27f984dfbe96bd8e4fd08f20a2ede3ea23 https://git.kernel.org/stable/c/3af734f3eac6f70ef8e272a80da40544b9d0f2b5 https://git.kernel.org/stable/c/3b4c045a98f53a8890a94bb5846a390c8e39e673 https://git.kernel.org/stable/c/462a8e08e0e6287e5ce13187257edbf24213ed03 •
CVSS: 4.4EPSS: 0%CPEs: 7EXPL: 0CVE-2023-52730 – mmc: sdio: fix possible resource leaks in some error paths
https://notcve.org/view.php?id=CVE-2023-52730
Si sdio_add_func() o sdio_init_func() falla, sdio_remove_func() no puede liberar los recursos, porque no se presenta la función sdio en estos dos casos, no llamará a of_node_put() o put_device(). • https://git.kernel.org/stable/c/3d10a1ba0d37c8f5fd5afcdda00613fbb8a90bf5 https://git.kernel.org/stable/c/92ff03c2563c9b57a027c744750f3b7d2f261c58 https://git.kernel.org/stable/c/5c7858adada31dbed042448cff6997dd6efc472a https://git.kernel.org/stable/c/761db46b29b496946046d8cb33c7ea6de6bef36e https://git.kernel.org/stable/c/30716d9f0fa1766e522cf24c8a456244e4fc9931 https://git.kernel.org/stable/c/1e06cf04239e202248c8fa356bf11449dc73cfbd https://git.kernel.org/stable/c/f855d31bb38d663c3ba672345d7cce9324ba3b72 https://git.kernel.org/stable/c/605d9fb9556f8f5fb4566f4df1480f280 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: 4.7EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47412 – block: don't call rq_qos_ops->done_bio if the bio isn't tracked
https://notcve.org/view.php?id=CVE-2021-47412
Especialmente en bio_endio(): 1) la cola de solicitudes se remite a través de bio->bi_bdev->bd_disk->queue, que puede desaparecer ya que el recuento de la cola de solicitudes no se puede mantener en los dos casos anteriores 2) q->rq_qos se puede liberar en blk_cleanup_queue() al llamar a __rq_qos_done_bio() Solucione el posible pánico del kernel al no llamar a rq_qos_ops->done_bio si no se realiza un seguimiento de la biografía. • https://git.kernel.org/stable/c/004b8f8a691205a93d9e80d98b786b2b97424d6e https://git.kernel.org/stable/c/a647a524a46736786c95cdb553a070322ca096e3 https://access.redhat.com/security/cve/CVE-2021-47412 https://bugzilla.redhat.com/show_bug.cgi?id=2282324 • CWE-388: 7PK - Errors •
CVSS: 4.1EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47400 – net: hns3: do not allow call hns3_nic_net_open repeatedly
https://notcve.org/view.php?id=CVE-2021-47400
Al restablecer y configurar tc el dispositivo simultáneamente, existe una pequeña oportunidad de llamar a hns3_nic_net_open repetidamente y causar un error en el kernel al llamar a napi_enable dos veces. La información del seguimiento de llamadas es la siguiente: [3078.222780] ------------[ cortar aquí ]------------ [ 3078.230255] BUG del kernel en net/core/dev. c:6991! • https://git.kernel.org/stable/c/e888402789b9db5de4fcda361331d66dbf0cd9fd https://git.kernel.org/stable/c/5a31d4e73ada8022427b69b10fd1f01a6a8d4b3d https://git.kernel.org/stable/c/f8ba689cb69523144d10606096ef686002dd7285 https://git.kernel.org/stable/c/3dac38bdce7932901b9f0b71c62331852c809e61 https://git.kernel.org/stable/c/5b09e88e1bf7fe86540fab4b5f3eece8abead39e https://access.redhat.com/security/cve/CVE-2021-47400 https://bugzilla.redhat.com/show_bug.cgi?id=2282336 • CWE-664: Improper Control of a Resource Through its Lifetime •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47391 – RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests
https://notcve.org/view.php?id=CVE-2021-47391
El FSM puede ejecutarse en un círculo permitiendo llamar a rdma_resolve_ip() dos veces en el mismo id_priv. Si bien esto no puede suceder sin realizar el trabajo, viola la invariante de que la misma solicitud en segundo plano de resolución de dirección no puede estar activa dos veces. CPU 1 CPU 2 rdma_resolve_addr(): RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler) #1 process_one_req(): para #1 addr_handler(): RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND mutex_unlock(&id_priv->handler_mutex); [.. el controlador sigue ejecutándose...] rdma_resolve_addr(): RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY rdma_resolve_ip(addr_handler)!! ahora hay dos solicitudes en la lista de solicitudes rdma_destroy_id(): destroy_id_handler_unlock(): _destroy_id(): cma_cancel_operation(): rdma_addr_cancel() // Process_one_req() lo elimina automáticamente spin_lock_bh(&lock); cancel_delayed_work(&req->trabajo); if (!... Esto genera situaciones en las que req_list puede tener dos solicitudes para el mismo "identificador" pero rdma_addr_cancel() solo cancela la primera. • https://git.kernel.org/stable/c/e51060f08a61965c4dd91516d82fe90617152590 https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589 https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808 •