CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47504 – io_uring: ensure task_work gets run as part of cancelations
https://notcve.org/view.php?id=CVE-2021-47504
In the Linux kernel, the following vulnerability has been resolved: io_uring: ensure task_work gets run as part of cancelations If we successfully cancel a work item but that work item needs to be processed through task_work, then we can be sleeping uninterruptibly in io_uring_cancel_generic() and never process it. Hence we don't make forward progress and we end up with an uninterruptible sleep warning. While in there, correct a comment that should be IFF, not IIF. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: garantiza que task_work se ejecute como parte de las cancelaciones. Si cancelamos con éxito un elemento de trabajo pero ese elemento de trabajo debe procesarse a través de task_work, entonces podemos estar durmiendo ininterrumpidamente en io_uring_cancel_generic() y nunca procesarlo. Por lo tanto, no avanzamos y terminamos con un aviso de sueño ininterrumpido. • https://git.kernel.org/stable/c/8e12976c0c19ebc14b60046b1348c516a74c25a2 https://git.kernel.org/stable/c/78a780602075d8b00c98070fa26e389b3b3efa72 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47501 – i40e: Fix NULL pointer dereference in i40e_dbg_dump_desc
https://notcve.org/view.php?id=CVE-2021-47501
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix NULL pointer dereference in i40e_dbg_dump_desc When trying to dump VFs VSI RX/TX descriptors using debugfs there was a crash due to NULL pointer dereference in i40e_dbg_dump_desc. Added a check to i40e_dbg_dump_desc that checks if VSI type is correct for dumping RX/TX descriptors. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: i40e: Se corrigió la desreferencia del puntero NULL en i40e_dbg_dump_desc Al intentar volcar los descriptores VF VSI RX/TX usando debugfs, se produjo un bloqueo debido a la desreferencia del puntero NULL en i40e_dbg_dump_desc. Se agregó una verificación a i40e_dbg_dump_desc que verifica si el tipo de VSI es correcto para volcar descriptores RX/TX. • https://git.kernel.org/stable/c/02e9c290814cc143ceccecb14eac3e7a05da745e https://git.kernel.org/stable/c/e5b7fb2198abc50058f1a29c395b004f76ab1c83 https://git.kernel.org/stable/c/16431e442db248ecd8aa9457cf0a656f1885f56e https://git.kernel.org/stable/c/23ec111bf3549aae37140330c31a16abfc172421 https://access.redhat.com/security/cve/CVE-2021-47501 https://bugzilla.redhat.com/show_bug.cgi?id=2283453 • CWE-476: NULL Pointer Dereference •
CVSS: 6.8EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36013 – Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()
https://notcve.org/view.php?id=CVE-2024-36013
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect() Extend a critical section to prevent chan from early freeing. Also make the l2cap_connect() return type void. Nothing is using the returned value but it is ugly to return a potentially freed pointer. Making it void will help with backports because earlier kernels did use the return value. Now the compile will break for kernels where this patch is not a complete fix. Call stack summary: [use] l2cap_bredr_sig_cmd l2cap_connect ┌ mutex_lock(&conn->chan_lock); │ chan = pchan->ops->new_connection(pchan); <- alloc chan │ __l2cap_chan_add(conn, chan); │ l2cap_chan_hold(chan); │ list_add(&chan->list, &conn->chan_l); ... (1) └ mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free [free] l2cap_conn_del ┌ mutex_lock(&conn->chan_lock); │ foreach chan in conn->chan_l: ... (2) │ l2cap_chan_put(chan); │ l2cap_chan_destroy │ kfree(chan) ... (3) <- chan freed └ mutex_unlock(&conn->chan_lock); ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: slab-use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0 net/bluetooth/l2cap_core.c:4260 Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: corrige slab-use-after-free en l2cap_connect() Amplia una sección crítica para evitar que chan se libere anticipadamente. También anule el tipo de retorno l2cap_connect(). Nada utiliza el valor devuelto, pero es feo devolver un puntero potencialmente liberado. • https://git.kernel.org/stable/c/73ffa904b78287f6acf8797e040150aa26a4af4a https://git.kernel.org/stable/c/cfe560c7050bfb37b0d2491bbe7cd8b59e77fdc5 https://git.kernel.org/stable/c/826af9d2f69567c646ff46d10393d47e30ad23c6 https://git.kernel.org/stable/c/4d7b41c0e43995b0e992b9f8903109275744b658 http://www.openwall.com/lists/oss-security/2024/05/30/1 http://www.openwall.com/lists/oss-security/2024/05/30/2 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47498 – dm rq: don't queue request to blk-mq during DM suspend
https://notcve.org/view.php?id=CVE-2021-47498
In the Linux kernel, the following vulnerability has been resolved: dm rq: don't queue request to blk-mq during DM suspend DM uses blk-mq's quiesce/unquiesce to stop/start device mapper queue. But blk-mq's unquiesce may come from outside events, such as elevator switch, updating nr_requests or others, and request may come during suspend, so simply ask for blk-mq to requeue it. Fixes one kernel panic issue when running updating nr_requests and dm-mpath suspend/resume stress test. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dm rq: no poner en cola la solicitud a blk-mq durante la suspensión de DM. DM utiliza la función de reposo/inquiesce de blk-mq para detener/iniciar la cola del asignador de dispositivos. Pero la inquietud de blk-mq puede provenir de eventos externos, como el cambio de ascensor, la actualización de nr_requests u otros, y la solicitud puede ocurrir durante la suspensión, así que simplemente solicite que blk-mq la vuelva a poner en cola. Soluciona un problema de pánico del kernel al ejecutar la actualización de nr_requests y la prueba de esfuerzo de suspensión/reanudación de dm-mpath. • https://git.kernel.org/stable/c/8ca9745efe3528feb06ca4e117188038eea2d351 https://git.kernel.org/stable/c/b4459b11e84092658fa195a2587aff3b9637f0e7 •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47495 – usbnet: sanity check for maxpacket
https://notcve.org/view.php?id=CVE-2021-47495
In the Linux kernel, the following vulnerability has been resolved: usbnet: sanity check for maxpacket maxpacket of 0 makes no sense and oopses as we need to divide by it. Give up. V2: fixed typo in log and stylistic issues En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usbnet: verificación de cordura para maxpacket maxpacket de 0 no tiene sentido y falla ya que necesitamos dividirlo por él. Abandonar. V2: error tipográfico corregido en el registro y problemas de estilo • https://git.kernel.org/stable/c/b9eba0a4a527e04d712f0e0401e5391ef124b33e https://git.kernel.org/stable/c/524f333e98138d909a0a0c574a9ff6737dce2767 https://git.kernel.org/stable/c/74b3b27cf9fecce00cd8918b7882fd81191d0aa4 https://git.kernel.org/stable/c/002d82227c0abe29118cf80f7e2f396b22d448ed https://git.kernel.org/stable/c/492140e45d2bf27c1014243f8616a9b612144e20 https://git.kernel.org/stable/c/693ecbe8f799405f8775719deedb1f76265d375a https://git.kernel.org/stable/c/7e8b6a4f18edee070213cb6a77118e8a412253c5 https://git.kernel.org/stable/c/397430b50a363d8b7bdda00522123f82d • CWE-369: Divide By Zero •