CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47506 – nfsd: fix use-after-free due to delegation race
https://notcve.org/view.php?id=CVE-2021-47506
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix use-after-free due to delegation race A delegation break could arrive as soon as we've called vfs_setlease. A delegation break runs a callback which immediately (in nfsd4_cb_recall_prepare) adds the delegation to del_recall_lru. If we then exit nfs4_set_delegation without hashing the delegation, it will be freed as soon as the callback is done with it, without ever being removed from del_recall_lru. Symptoms show up later as use-after-free or list corruption warnings, usually in the laundromat thread. I suspect aba2072f4523 "nfsd: grant read delegations to clients holding writes" made this bug easier to hit, but I looked as far back as v3.0 and it looks to me it already had the same problem. So I'm not sure where the bug was introduced; it may have been there from the beginning. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrige el use-after-free debido a la ejecución de delegación. • https://git.kernel.org/stable/c/04a8d07f3d58308b92630045560799a3faa3ebce https://git.kernel.org/stable/c/348714018139c39533c55661a0c7c990671396b4 https://git.kernel.org/stable/c/33645d3e22720cac1e4548f8fef57bf0649536ee https://git.kernel.org/stable/c/2becaa990b93cbd2928292c0b669d3abb6cf06d4 https://git.kernel.org/stable/c/e0759696de6851d7536efddfdd2dfed4c4df1f09 https://git.kernel.org/stable/c/eeb0711801f5e19ef654371b627682aed3b11373 https://git.kernel.org/stable/c/148c816f10fd11df27ca6a9b3238cdd42fa72cd3 https://git.kernel.org/stable/c/548ec0805c399c65ed66c6641be467f71 •
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: 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 •