CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47500 – iio: mma8452: Fix trigger reference couting
https://notcve.org/view.php?id=CVE-2021-47500
In the Linux kernel, the following vulnerability has been resolved: iio: mma8452: Fix trigger reference couting The mma8452 driver directly assigns a trigger to the struct iio_dev. The IIO core when done using this trigger will call `iio_trigger_put()` to drop the reference count by 1. Without the matching `iio_trigger_get()` in the driver the reference count can reach 0 too early, the trigger gets freed while still in use and a use-after-free occurs. Fix this by getting a reference to the trigger before assigning it to the IIO device. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iio: mma8452: corrección del cálculo de referencia del disparador El controlador mma8452 asigna directamente un disparador a la estructura iio_dev. El núcleo de IIO, cuando termine de usar este activador, llamará a `iio_trigger_put()` para reducir el recuento de referencias en 1. Sin el `iio_trigger_get()` coincidente en el controlador, el recuento de referencias puede llegar a 0 demasiado pronto, el activador se libera mientras aún está en se produce un uso y un use-after-free. • https://git.kernel.org/stable/c/ae6d9ce05691bf79694074db7c7da980080548af https://git.kernel.org/stable/c/094d513b78b1714113bc016684b8142382e071ba https://git.kernel.org/stable/c/fb75cc4740d81264cd5bcb0e17d961d018a8be96 https://git.kernel.org/stable/c/794c0898f6bf39a458655d5fb4af70ec43a5cfcb https://git.kernel.org/stable/c/f5deab10ced368c807866283f8b79144c4823be8 https://git.kernel.org/stable/c/acf0088ac073ca6e7f4cad6acac112177e08df5e https://git.kernel.org/stable/c/db12d95085367de8b0223929d1332731024441f1 https://git.kernel.org/stable/c/c43517071dfc9fce34f8f69dbb98a8601 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47499 – iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove
https://notcve.org/view.php?id=CVE-2021-47499
In the Linux kernel, the following vulnerability has been resolved: iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the memory allocated by iio_triggered_buffer_setup() will not be freed, and cause memory leak as follows: unreferenced object 0xffff888009551400 (size 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s) hex dump (first 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff ........ ....... backtrace: [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360 [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf] [<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer] [<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013] Fix it by remove data->dready_trig condition in probe and remove. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iio: accel: kxcjk-1013: corrija la posible pérdida de memoria en la sonda y elimínela. Cuando el tipo ACPI es ACPI_SMO8500, data->dready_trig no se configurará, la memoria asignada por iio_triggered_buffer_setup( ) no se liberará y provocará una pérdida de memoria de la siguiente manera: objeto sin referencia 0xffff888009551400 (tamaño 512): comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (edad 83,852 s) volcado hexadecimal (primeros 32 bytes): 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff .... .... ....... retroceso: [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360 [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf] [<000000004b40c1f5>] ed_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer] [ <000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013] Solucionarlo eliminando la condición data->dready_trig en la sonda y eliminándola. • https://git.kernel.org/stable/c/a25691c1f9674090fb66586cf4c5d60d3efdf339 https://git.kernel.org/stable/c/8c1d43f3a3fc7184c42d7398bdf59a2a2903e4fc https://git.kernel.org/stable/c/60a55b9d91ba99eb8cf015bc46dc2de05e168a15 https://git.kernel.org/stable/c/3899700ddacbf7aaafadf44464fff3ff0d4e3307 https://git.kernel.org/stable/c/a3730f74159ad00a28960c0efe2a931fe6fe6b45 https://git.kernel.org/stable/c/8c163a14277115ca962103910ab4cce55e862ffb https://git.kernel.org/stable/c/ee86d0bad80bdcd11a87e188a596727f41b62320 https://git.kernel.org/stable/c/14508fe13b1c578b3d2ba574f1d48b351 •
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: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36012 – Bluetooth: msft: fix slab-use-after-free in msft_do_close()
https://notcve.org/view.php?id=CVE-2024-36012
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: msft: fix slab-use-after-free in msft_do_close() Tying the msft->data lifetime to hdev by freeing it in hci_release_dev() to fix the following case: [use] msft_do_close() msft = hdev->msft_data; if (!msft) ...(1) <- passed. return; mutex_lock(&msft->filter_lock); ...(4) <- used after freed. [free] msft_unregister() msft = hdev->msft_data; hdev->msft_data = NULL; ...(2) kfree(msft); ...(3) <- msft is freed. ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30 kernel/locking/mutex.c:752 Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Bluetooth: msft: corrija slab-use-after-free en msft_do_close() Vinculando la vida útil de msft->data a hdev liberándolo en hci_release_dev() para solucionar el siguiente caso: [usar] msft_do_close() msft = hdev->msft_data; if (!msft) ...(1) <- aprobado. devolver; mutex_lock(&msft->filter_lock); ...(4) <- usado después de liberado. [gratis] msft_unregister() msft = hdev->msft_data; hdev->msft_data = NULL; ...(2) klibre(msft); ...(3) <- se libera msft. ==================================================== ================ ERROR: KASAN: slab-use-after-free en __mutex_lock_common kernel/locking/mutex.c:587 [en línea] ERROR: KASAN: slab-use-after -free en __mutex_lock+0x8f/0xc30 kernel/locking/mutex.c:752 Lectura de tamaño 8 en addr ffff888106cbbca8 por tarea kworker/u5:2/309 • https://git.kernel.org/stable/c/bf6a4e30ffbd9e9ef8934582feb937f6532f8b68 https://git.kernel.org/stable/c/e3880b531b68f98d3941d83f2f6dd11cf4fd6b76 https://git.kernel.org/stable/c/a85a60e62355e3bf4802dead7938966824b23940 https://git.kernel.org/stable/c/4f1de02de07748da80a8178879bc7a1df37fdf56 https://git.kernel.org/stable/c/10f9f426ac6e752c8d87bf4346930ba347aaabac •
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 •