CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47435 – dm: fix mempool NULL pointer race when completing IO
https://notcve.org/view.php?id=CVE-2021-47435
In the Linux kernel, the following vulnerability has been resolved: dm: fix mempool NULL pointer race when completing IO dm_io_dec_pending() calls end_io_acct() first and will then dec md in-flight pending count. But if a task is swapping DM table at same time this can result in a crash due to mempool->elements being NULL: task1 task2 do_resume ->do_suspend ->dm_wait_for_completion bio_endio ->clone_endio ->dm_io_dec_pending ->end_io_acct ->wakeup task1 ->dm_swap_table ->__bind ->__bind_mempools ->bioset_exit ->mempool_exit ->free_io [ 67.330330] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ...... [ 67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 67.330510] pc : mempool_free+0x70/0xa0 [ 67.330515] lr : mempool_free+0x4c/0xa0 [ 67.330520] sp : ffffff8008013b20 [ 67.330524] x29: ffffff8008013b20 x28: 0000000000000004 [ 67.330530] x27: ffffffa8c2ff40a0 x26: 00000000ffff1cc8 [ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800 [ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800 [ 67.330547] x21: 00000000ffff1cc8 x20: ffffffd9a1304d80 [ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c [ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd [ 67.330563] x15: 000000000093b41e x14: 0000000000000010 [ 67.330569] x13: 0000000000007f7a x12: 0000000034155555 [ 67.330574] x11: 0000000000000001 x10: 0000000000000001 [ 67.330579] x9 : 0000000000000000 x8 : 0000000000000000 [ 67.330585] x7 : 0000000000000000 x6 : ffffff80148b5c1a [ 67.330590] x5 : ffffff8008013ae0 x4 : 0000000000000001 [ 67.330596] x3 : ffffff80080139c8 x2 : ffffff801083bab8 [ 67.330601] x1 : 0000000000000000 x0 : ffffffdada34c970 [ 67.330609] Call trace: [ 67.330616] mempool_free+0x70/0xa0 [ 67.330627] bio_put+0xf8/0x110 [ 67.330638] dec_pending+0x13c/0x230 [ 67.330644] clone_endio+0x90/0x180 [ 67.330649] bio_endio+0x198/0x1b8 [ 67.330655] dec_pending+0x190/0x230 [ 67.330660] clone_endio+0x90/0x180 [ 67.330665] bio_endio+0x198/0x1b8 [ 67.330673] blk_update_request+0x214/0x428 [ 67.330683] scsi_end_request+0x2c/0x300 [ 67.330688] scsi_io_completion+0xa0/0x710 [ 67.330695] scsi_finish_command+0xd8/0x110 [ 67.330700] scsi_softirq_done+0x114/0x148 [ 67.330708] blk_done_softirq+0x74/0xd0 [ 67.330716] __do_softirq+0x18c/0x374 [ 67.330724] irq_exit+0xb4/0xb8 [ 67.330732] __handle_domain_irq+0x84/0xc0 [ 67.330737] gic_handle_irq+0x148/0x1b0 [ 67.330744] el1_irq+0xe8/0x190 [ 67.330753] lpm_cpuidle_enter+0x4f8/0x538 [ 67.330759] cpuidle_enter_state+0x1fc/0x398 [ 67.330764] cpuidle_enter+0x18/0x20 [ 67.330772] do_idle+0x1b4/0x290 [ 67.330778] cpu_startup_entry+0x20/0x28 [ 67.330786] secondary_start_kernel+0x160/0x170 Fix this by: 1) Establishing pointers to 'struct dm_io' members in dm_io_dec_pending() so that they may be passed into end_io_acct() _after_ free_io() is called. 2) Moving end_io_acct() after free_io(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dm: corrige la ejecución del puntero NULL de mempool al completar IO dm_io_dec_pending() llama a end_io_acct() primero y luego dec md en vuelo conteo pendiente. Pero si una tarea intercambia la tabla DM al mismo tiempo, esto puede provocar un bloqueo debido a que mempool->elementos son NULL: tarea1 tarea2 do_resume ->do_suspend ->dm_wait_for_completion bio_endio ->clone_endio ->dm_io_dec_pending ->end_io_acct ->wakeup task1 - >dm_swap_table ->__bind ->__bind_mempools ->bioset_exit ->mempool_exit ->free_io [67.330330] No se puede manejar la desreferencia del puntero NULL del kernel en la dirección virtual 00000000000000000 ...... [67.330494] pstate: 80400085 (Nzcv daIf +PAN -UAO ) [67.330510] pc: mempool_free+0x70/0xa0 [67.330515] lr: mempool_free+0x4c/0xa0 [67.330520] sp: ffffff8008013b20 [67.330524] x29: ffffff8008013b20 x28: 000000000000004 [ 67.330530] x27: fffffa8c2ff40a0 x26: 00000000ffff1cc8 [ 67.330535] x25: 0000000000000000 x24: ffffffdada34c800 [ 67.330541] x23: 0000000000000000 x22: ffffffdada34c800 [ 67.330547] x21: 00000000ffff1cc8 x20: 1304d80 [ 67.330552] x19: ffffffdada34c970 x18: 000000b312625d9c [ 67.330558] x17: 00000000002dcfbf x16: 00000000000006dd [ 67.330563] 000000000093b41e x14: 0000000000000010 [ 67.330569] x13: 0000000000007f7a x12: 0000000034155555 [ 67.330574] x11: 00000000000000001 x10: 0000000000000001 [ 67.330579] x9 : 0000000000000000 x8: 0000000000000000 [67.330585] x7: 0000000000000000 x6: ffffff80148b5c1a [67.330590] x5: ffffff8008013ae0 x4: 000000001 [67.330596] x3: ffffff80080139c8 x2: ffffff801083bab8 [67.330601] x1: 0000000000000000 x0: ffffffdada34c970 [67.330609] Rastreo de llamadas: [67.330616] mempool_free+0x70/0xa0 [67.330627] 8/0x110 [67.330638] dec_pending+0x13c/0x230 [67.330644] clone_endio+0x90/0x180 [ 67.330649] bio_endio+0x198/0x1b8 [ 67.330655] dec_pending+0x190/0x230 [ 67.330660] clone_endio+0x90/0x180 [ 67.330665] bio_endio+0x198/0x1b8 [ 67.330673 ] blk_update_request+0x214/0x428 [ 67.330683] scsi_end_request+0x2c/0x300 [ 67.330688 ] scsi_io_completion+0xa0/0x710 [ 67.330695] scsi_finish_command+0xd8/0x110 [ 67.330700] scsi_softirq_done+0x114/0x148 [ 67.330708] blk_done_softirq+0x74/0xd0 [ 67.3307 16] __do_softirq+0x18c/0x374 [ 67.330724] irq_exit+0xb4/0xb8 [ 67.330732] __handle_domain_irq +0x84/0xc0 [ 67.330737] gic_handle_irq+0x148/0x1b0 [ 67.330744] el1_irq+0xe8/0x190 [ 67.330753] lpm_cpuidle_enter+0x4f8/0x538 [ 67.330759] +0x1fc/0x398 [ 67.330764] cpuidle_enter+0x18/0x20 [ 67.330772] do_idle+0x1b4 /0x290 [ 67.330778] cpu_startup_entry+0x20/0x28 [ 67.330786] second_start_kernel+0x160/0x170 Solucione este problema de la siguiente manera: 1) Estableciendo punteros a los miembros 'struct dm_io' en dm_io_dec_pending() para que puedan pasarse a end_io_acct() _después_ free_io() se llama. 2) Mover end_io_acct() después de free_io(). • https://git.kernel.org/stable/c/9fb7cd5c7fef0f1c982e3cd27745a0dec260eaed https://git.kernel.org/stable/c/d35aef9c60d310eff3eaddacce301efe877e2b7c https://git.kernel.org/stable/c/9e07272cca2ed76f7f6073f4444b1143828c8d87 https://git.kernel.org/stable/c/ad1393b92e5059218d055bfec8f4946d85ad04c4 https://git.kernel.org/stable/c/d29c78d3f9c5d2604548c1065bf1ec212728ea61 https://git.kernel.org/stable/c/6e506f07c5b561d673dd0b0d8f7f420cc48024fb https://git.kernel.org/stable/c/d208b89401e073de986dc891037c5a668f5d5d95 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47434 – xhci: Fix command ring pointer corruption while aborting a command
https://notcve.org/view.php?id=CVE-2021-47434
In the Linux kernel, the following vulnerability has been resolved: xhci: Fix command ring pointer corruption while aborting a command The command ring pointer is located at [6:63] bits of the command ring control register (CRCR). All the control bits like command stop, abort are located at [0:3] bits. While aborting a command, we read the CRCR and set the abort bit and write to the CRCR. The read will always give command ring pointer as all zeros. So we essentially write only the control bits. • https://git.kernel.org/stable/c/22bcb65ea41072ab5d03c0c6290e04e0df6d09a0 https://git.kernel.org/stable/c/62c182b5e763e5f4062e72678e72ce3e02dd4d1b https://git.kernel.org/stable/c/01c2dcb67e71c351006dd17cbba86c26b7f61eaf https://git.kernel.org/stable/c/dec944bb7079b37968cf69c8a438f91f15c4cc61 https://git.kernel.org/stable/c/e54abefe703ab7c4e5983e889babd1447738ca42 https://git.kernel.org/stable/c/ff0e50d3564f33b7f4b35cadeabd951d66cfc570 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47433 – btrfs: fix abort logic in btrfs_replace_file_extents
https://notcve.org/view.php?id=CVE-2021-47433
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix abort logic in btrfs_replace_file_extents Error injection testing uncovered a case where we'd end up with a corrupt file system with a missing extent in the middle of a file. This occurs because the if statement to decide if we should abort is wrong. The only way we would abort in this case is if we got a ret != -EOPNOTSUPP and we called from the file clone code. However the prealloc code uses this path too. Instead we need to abort if there is an error, and the only error we _don't_ abort on is -EOPNOTSUPP and only if we came from the clone file code. • https://git.kernel.org/stable/c/0e32a2b85c7d92ece86c17dfef390c5ed79c6378 https://git.kernel.org/stable/c/0e309e1152fc34ef75991d9d69b165dbf75bf26c https://git.kernel.org/stable/c/4afb912f439c4bc4e6a4f3e7547f2e69e354108f •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52836 – locking/ww_mutex/test: Fix potential workqueue corruption
https://notcve.org/view.php?id=CVE-2023-52836
In the Linux kernel, the following vulnerability has been resolved: locking/ww_mutex/test: Fix potential workqueue corruption In some cases running with the test-ww_mutex code, I was seeing odd behavior where sometimes it seemed flush_workqueue was returning before all the work threads were finished. Often this would cause strange crashes as the mutexes would be freed while they were being used. Looking at the code, there is a lifetime problem as the controlling thread that spawns the work allocates the "struct stress" structures that are passed to the workqueue threads. Then when the workqueue threads are finished, they free the stress struct that was passed to them. Unfortunately the workqueue work_struct node is in the stress struct. Which means the work_struct is freed before the work thread returns and while flush_workqueue is waiting. It seems like a better idea to have the controlling thread both allocate and free the stress structures, so that we can be sure we don't corrupt the workqueue by freeing the structure prematurely. So this patch reworks the test to do so, and with this change I no longer see the early flush_workqueue returns. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lock/ww_mutex/test: soluciona una posible corrupción de la cola de trabajo. En algunos casos, al ejecutar el código test-ww_mutex, veía un comportamiento extraño en el que a veces parecía que flush_workqueue regresaba antes que todos los subprocesos de trabajo. hemos terminado. • https://git.kernel.org/stable/c/d4d37c9e6a4dbcca958dabd99216550525c7e389 https://git.kernel.org/stable/c/d8267cabbe1bed15ccf8b0e684c528bf8eeef715 https://git.kernel.org/stable/c/dcd85e3c929368076a7592b27f541e0da8b427f5 https://git.kernel.org/stable/c/9ed2d68b3925145f5f51c46559484881d6082f75 https://git.kernel.org/stable/c/e89d0ed45a419c485bae999426ecf92697cbdda3 https://git.kernel.org/stable/c/c56df79d68677cf062da1b6e3b33e74299a92dfc https://git.kernel.org/stable/c/e36407713163363e65566e7af0abe207d5f59a0c https://git.kernel.org/stable/c/304a2c4aad0fff887ce493e4197bf9cba •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52835 – perf/core: Bail out early if the request AUX area is out of bound
https://notcve.org/view.php?id=CVE-2023-52835
In the Linux kernel, the following vulnerability has been resolved: perf/core: Bail out early if the request AUX area is out of bound When perf-record with a large AUX area, e.g 4GB, it fails with: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory) and it reveals a WARNING with __alloc_pages(): ------------[ cut here ]------------ WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Call trace: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 __arm64_sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8 'rb->aux_pages' allocated by kcalloc() is a pointer array which is used to maintains AUX trace pages. The allocated page for this array is physically contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the size of pointer array crosses the limitation set by MAX_ORDER, it reveals a WARNING. So bail out early with -ENOMEM if the request AUX area is out of bound, e.g.: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf/core: rescate anticipado si el área AUX de la solicitud está fuera de los límites. Cuando perf-record con un área AUX grande, por ejemplo, 4 GB, falla con: #perf record -C 0 -m, 4G -e arm_spe_0// -- el sueño 1 no pudo mapear con 12 (no se puede asignar memoria) y revela una ADVERTENCIA con __alloc_pages(): ------------[ cortar aquí ] ------------ ADVERTENCIA: CPU: 44 PID: 17573 en mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Rastreo de llamadas: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/ 0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8 'rb->aux_pages' asignado por kcalloc() es una matriz de punteros que se utiliza para mantener páginas de seguimiento AUX. • https://git.kernel.org/stable/c/8c504f615d7ed60ae035c51d0c789137ced6797f https://git.kernel.org/stable/c/788c0b3442ead737008934947730a6d1ff703734 https://git.kernel.org/stable/c/1a2a4202c60fcdffbf04f259002ce9bff39edece https://git.kernel.org/stable/c/fd0df3f8719201dbe61a4d39083d5aecd705399a https://git.kernel.org/stable/c/9ce4e87a8efd37c85766ec08b15e885cab08553a https://git.kernel.org/stable/c/2424410f94a94d91230ced094062d859714c984a https://git.kernel.org/stable/c/2e905e608e38cf7f8dcddcf8a6036e91a78444cb https://git.kernel.org/stable/c/54aee5f15b83437f23b2b2469bcf21bdd • CWE-125: Out-of-bounds Read •