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-47497 – nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells
https://notcve.org/view.php?id=CVE-2021-47497
In the Linux kernel, the following vulnerability has been resolved: nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0); will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we subtract one from that making a large number that is then shifted more than the number of bits that fit into an unsigned long. UBSAN reports this problem: UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9 Hardware name: Google Lazor (rev3+) with KB Backlight (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack+0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 nvmem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 component_bind_all+0xf0/0x264 msm_drm_bind+0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c component_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 really_probe+0x110/0x304 __driver_probe_device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv+0x90/0xdc __device_attach+0xc8/0x174 device_initial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 deferred_probe_work_func+0x7c/0xb8 process_one_work+0x128/0x21c process_scheduled_works+0x40/0x54 worker_thread+0x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Fix it by making sure there are any bits to mask out. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nvmem: corrige el desplazamiento fuera de los límites (UBSAN) con celdas de tamaño de bytes. Si una celda tiene 'nbits' iguales a un múltiplo de BITS_PER_BYTE, la lógica *p &= GENMASK( (celda->nbits%BITS_PER_BYTE) - 1, 0); se convertirá en un comportamiento indefinido porque el módulo de nbits BITS_PER_BYTE es 0, y restamos uno de eso, lo que genera un número grande que luego se desplaza más que el número de bits que caben en un largo sin signo. UBSAN informa este problema: UBSAN: desplazamiento fuera de los límites en drivers/nvmem/core.c:1386:8 el exponente de desplazamiento 64 es demasiado grande para el tipo de 64 bits 'largo sin firmar' CPU: 6 PID: 7 Comm: kworker /u16:0 Not tainted 5.15.0-rc3+ #9 Nombre del hardware: Google Lazor (rev3+) con KB Backlight (DT) Cola de trabajo: events_unbound deferred_probe_work_func Rastreo de llamadas: dump_backtrace+0x0/0x170 show_stack+0x24/0x30 dump_stack_lvl+0x64/0x7c dump_stack +0x18/0x38 ubsan_epilogue+0x10/0x54 __ubsan_handle_shift_out_of_bounds+0x180/0x194 __nvmem_cell_read+0x1ec/0x21c nvmem_cell_read+0x58/0x94 nvmem_cell_read_variable_common+0x4c/0xb0 mem_cell_read_variable_le_u32+0x40/0x100 a6xx_gpu_init+0x170/0x2f4 adreno_bind+0x174/0x284 componente_bind_all+0xf0/0x264 msm_drm_bind +0x1d8/0x7a0 try_to_bring_up_master+0x164/0x1ac __component_add+0xbc/0x13c componente_add+0x20/0x2c dp_display_probe+0x340/0x384 platform_probe+0xc0/0x100 very_probe+0x110/0x304 _device+0xb8/0x120 driver_probe_device+0x4c/0xfc __device_attach_driver+0xb0/0x128 bus_for_each_drv +0x90/0xdc __device_attach+0xc8/0x174 dispositivo_inicial_probe+0x20/0x2c bus_probe_device+0x40/0xa4 diferido_probe_work_func+0x7c/0xb8 proceso_one_work+0x128/0x21c proceso_scheduled_works+0x40/0x54 trabajador_hilo+0 x1ec/0x2a8 kthread+0x138/0x158 ret_from_fork+0x10/0x20 Arreglar asegurándose de que haya partes que enmascarar. • https://git.kernel.org/stable/c/69aba7948cbe53f2f1827e84e9dd0ae470a5072e https://git.kernel.org/stable/c/abcb8d33e4d2215ccde5ab5ccf9f730a59d79d97 https://git.kernel.org/stable/c/60df06bbdf497e37ed25ad40572c362e5b0998df https://git.kernel.org/stable/c/2df6c023050205c4d04ffc121bc549f65cb8d1df https://git.kernel.org/stable/c/eb0fc8e7170e61eaf65d28dee4a8baf4e86b19ca https://git.kernel.org/stable/c/0594f1d048d8dc338eb9a240021b1d00ae1eb082 https://git.kernel.org/stable/c/57e48886401b14cd351423fabfec2cfd18df4f66 https://git.kernel.org/stable/c/0e822e5413da1af28cca350cb1cb42b61 • CWE-125: Out-of-bounds Read •
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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47493 – ocfs2: fix race between searching chunks and release journal_head from buffer_head
https://notcve.org/view.php?id=CVE-2021-47493
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix race between searching chunks and release journal_head from buffer_head Encountered a race between ocfs2_test_bg_bit_allocatable() and jbd2_journal_put_journal_head() resulting in the below vmcore. PID: 106879 TASK: ffff880244ba9c00 CPU: 2 COMMAND: "loop3" Call trace: panic oops_end no_context __bad_area_nosemaphore bad_area_nosemaphore __do_page_fault do_page_fault page_fault [exception RIP: ocfs2_block_group_find_clear_bits+316] ocfs2_block_group_find_clear_bits [ocfs2] ocfs2_cluster_group_search [ocfs2] ocfs2_search_chain [ocfs2] ocfs2_claim_suballoc_bits [ocfs2] __ocfs2_claim_clusters [ocfs2] ocfs2_claim_clusters [ocfs2] ocfs2_local_alloc_slide_window [ocfs2] ocfs2_reserve_local_alloc_bits [ocfs2] ocfs2_reserve_clusters_with_limit [ocfs2] ocfs2_reserve_clusters [ocfs2] ocfs2_lock_refcount_allocators [ocfs2] ocfs2_make_clusters_writable [ocfs2] ocfs2_replace_cow [ocfs2] ocfs2_refcount_cow [ocfs2] ocfs2_file_write_iter [ocfs2] lo_rw_aio loop_queue_work kthread_worker_fn kthread ret_from_fork When ocfs2_test_bg_bit_allocatable() called bh2jh(bg_bh), the bg_bh->b_private NULL as jbd2_journal_put_journal_head() raced and released the jounal head from the buffer head. Needed to take bit lock for the bit 'BH_JournalHead' to fix this race. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige la ejecución entre fragmentos de búsqueda y libera journal_head de buffer_head Se encontró una ejecución entre ocfs2_test_bg_bit_allocatable() y jbd2_journal_put_journal_head() que resultó en el siguiente vmcore. PID: 106879 TAREA: ffff880244ba9c00 CPU: 2 COMANDO: "loop3" Rastreo de llamadas: pánico oops_end no_context __bad_area_nosemaphore bad_area_nosemaphore __do_page_fault do_page_fault page_fault [excepción RIP: ocfs2_block_group_find_clear_bits+316] 2_block_group_find_clear_bits [ocfs2] ocfs2_cluster_group_search [ocfs2] ocfs2_search_chain [ocfs2] ocfs2_claim_suballoc_bits [ocfs2] __ocfs2_claim_clusters [ocfs2] ocfs2_claim_clusters [ocfs2] ocfs2_local_alloc_slide_window [ocfs2] ocfs2_reserve_local_alloc_bits [ocfs2] ocfs2_reserve_clusters_with_limit [ocfs2] ocfs2_reserve_clusters [ocfs2] ocfs2_lock_refcount_allocators [ocfs2] 2_make_clusters_writable [ocfs2] ocfs2_replace_cow [ocfs2] ocfs2_refcount_cow [ocfs2] ocfs2_file_write_iter [ocfs2] lo_rw_aio loop_queue_work kthread_worker_fn kthread ret_from_fork Cuando ocfs2_test_bg_bit_allocatable () llamado bh2jh(bg_bh), el bg_bh->b_private NULL como jbd2_journal_put_journal_head() corrió y liberó el encabezado del diario del encabezado del búfer. Era necesario bloquear el bit 'BH_JournalHead' para solucionar esta ejecución. • https://git.kernel.org/stable/c/5043fbd294f5909a080ade0f04b70a4da9e122b7 https://git.kernel.org/stable/c/2e382600e8856ea654677b5134ee66e03ea72bc2 https://git.kernel.org/stable/c/6f1b228529ae49b0f85ab89bcdb6c365df401558 •