CVSS: 8.4EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47456 – can: peak_pci: peak_pci_remove(): fix UAF
https://notcve.org/view.php?id=CVE-2021-47456
In the Linux kernel, the following vulnerability has been resolved: can: peak_pci: peak_pci_remove(): fix UAF When remove the module peek_pci, referencing 'chan' again after releasing 'dev' will cause UAF. Fix this by releasing 'dev' later. The following log reveals it: [ 35.961814 ] BUG: KASAN: use-after-free in peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.963414 ] Read of size 8 at addr ffff888136998ee8 by task modprobe/5537 [ 35.965513 ] Call Trace: [ 35.965718 ] dump_stack_lvl+0xa8/0xd1 [ 35.966028 ] print_address_description+0x87/0x3b0 [ 35.966420 ] kasan_report+0x172/0x1c0 [ 35.966725 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967137 ] ? trace_irq_enable_rcuidle+0x10/0x170 [ 35.967529 ] ? peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.967945 ] __asan_report_load8_noabort+0x14/0x20 [ 35.968346 ] peak_pci_remove+0x16f/0x270 [peak_pci] [ 35.968752 ] pci_device_remove+0xa9/0x250 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: pico_pci: pico_pci_remove(): arreglar UAF Cuando se elimina el módulo peek_pci, hacer referencia a 'chan' nuevamente después de liberar 'dev' causará UAF. Solucione este problema lanzando 'dev' más tarde. • https://git.kernel.org/stable/c/e6d9c80b7ca1504411ad6d7acdb8683e4ae1c9cd https://git.kernel.org/stable/c/1c616528ba4aeb1125a06b407572ab7b56acae38 https://git.kernel.org/stable/c/447d44cd2f67a20b596ede3ca3cd67086dfd9ca9 https://git.kernel.org/stable/c/34914971bb3244db4ce2be44e9438a9b30c56250 https://git.kernel.org/stable/c/adbda14730aacce41c0d3596415aa39ad63eafd9 https://git.kernel.org/stable/c/1248582e47a9f7ce0ecd156c39fc61f8b6aa3699 https://git.kernel.org/stable/c/28f28e4bc3a5e0051faa963f10b778ab38c1db69 https://git.kernel.org/stable/c/0e5afdc2315b0737edcf55bede4ee1640 • CWE-416: Use After Free CWE-467: Use of sizeof() on a Pointer Type •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47443 – NFC: digital: fix possible memory leak in digital_tg_listen_mdaa()
https://notcve.org/view.php?id=CVE-2021-47443
In the Linux kernel, the following vulnerability has been resolved: NFC: digital: fix possible memory leak in digital_tg_listen_mdaa() 'params' is allocated in digital_tg_listen_mdaa(), but not free when digital_send_cmd() failed, which will cause memory leak. Fix it by freeing 'params' if digital_send_cmd() return failed. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFC: digital: corrige una posible pérdida de memoria en digital_tg_listen_mdaa() Los 'params' se asignan en digital_tg_listen_mdaa(), pero no están libres cuando falla digital_send_cmd(), lo que provocará una pérdida de memoria. Solucionelo liberando 'params' si falla la devolución de digital_send_cmd(). • https://git.kernel.org/stable/c/1c7a4c24fbfd99442cc6e14dc80fcb00f118e8b8 https://git.kernel.org/stable/c/429054ec51e648d241a7e0b465cf44f6633334c5 https://git.kernel.org/stable/c/a67d47e32c91e2b10402cb8c081774cbf08edb2e https://git.kernel.org/stable/c/b7b023e6ff567e991c31cd425b0e1d16779c938b https://git.kernel.org/stable/c/9881b0c860649f27ef2565deef011e516390f416 https://git.kernel.org/stable/c/7ab488d7228a9dceb2456867f1f0919decf6efed https://git.kernel.org/stable/c/3f2960b39f22e26cf8addae93c3f5884d1c183c9 https://git.kernel.org/stable/c/564249219e5b5673a8416b5181875d828 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47442 – NFC: digital: fix possible memory leak in digital_in_send_sdd_req()
https://notcve.org/view.php?id=CVE-2021-47442
In the Linux kernel, the following vulnerability has been resolved: NFC: digital: fix possible memory leak in digital_in_send_sdd_req() 'skb' is allocated in digital_in_send_sdd_req(), but not free when digital_in_send_cmd() failed, which will cause memory leak. Fix it by freeing 'skb' if digital_in_send_cmd() return failed. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFC: digital: corrige una posible pérdida de memoria en digital_in_send_sdd_req() 'skb' está asignado en digital_in_send_sdd_req(), pero no está libre cuando falla digital_in_send_cmd(), lo que provocará una pérdida de memoria. Solucionarlo liberando 'skb' si falla la devolución de digital_in_send_cmd(). • https://git.kernel.org/stable/c/2c66daecc4092e6049673c281b2e6f0d5e59a94c https://git.kernel.org/stable/c/74569c78aa84f8c958f1334b465bc530906ec99a https://git.kernel.org/stable/c/88c890b0b9a1fb9fcd01c61ada515e8b636c34f9 https://git.kernel.org/stable/c/fcce6e5255474ca33c27dda0cdf9bf5087278873 https://git.kernel.org/stable/c/071bdef36391958c89af5fa2172f691b31baa212 https://git.kernel.org/stable/c/2bde4aca56db9fe25405d39ddb062531493a65db https://git.kernel.org/stable/c/50cb95487c265187289810addec5093d4fed8329 https://git.kernel.org/stable/c/6432d7f1d1c3aa74cfe8f5e3afdf81b78 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47438 – net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path
https://notcve.org/view.php?id=CVE-2021-47438
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path Prior to this patch in case mlx5_core_destroy_cq() failed it returns without completing all destroy operations and that leads to memory leak. Instead, complete the destroy flow before return error. Also move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq() to be symmetrical with mlx5_core_create_cq(). kmemleak complains on: unreferenced object 0xc000000038625100 (size 64): comm "ethtool", pid 28301, jiffies 4298062946 (age 785.380s) hex dump (first 32 bytes): 60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0 `.H.......4..... 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}..... backtrace: [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core] [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core] [<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core] [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core] [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core] [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core] [<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core] [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230 [mlx5_core] [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300 [mlx5_core] [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core] [<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core] [<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0 [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0 [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0 [<00000000646c5c2c>] genl_rcv_msg+0x78/0x120 [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net/mlx5e: corrige la pérdida de memoria en la ruta de error mlx5_core_destroy_cq(). Antes de este parche, en caso de que mlx5_core_destroy_cq() fallara, regresa sin completar todas las operaciones de destrucción y eso conduce a una pérdida de memoria. En su lugar, complete el flujo de destrucción antes de que se produzca el error de devolución. También mueva mlx5_debug_cq_remove() al principio de mlx5_core_destroy_cq() para que sea simétrico con mlx5_core_create_cq(). kmemleak se queja de: objeto sin referencia 0xc000000038625100 (tamaño 64): comm "ethtool", pid 28301, jiffies 4298062946 (edad 785.380 s) volcado hexadecimal (primeros 32 bytes): 60 01 48 94 00 00 00 c0 b8 05 34 3 00 00 00 c0 `.H.......4..... 02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0 ..........}..... rastreo hacia atrás : [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core] [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core] [<000000002a12918f>] 0x1d0/0x2d0 [mlx5_core] [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core] [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core] [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core] [<0000000081839561>] 5e_open_channels+0x9cc/0x13e0 [mlx5_core] [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4 /0x230 [mlx5_core] [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300 [mlx5_core] [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core [<00000000a] 0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core] [<00000000a8f3d84b>] etnl_set_privflags +0x234/0x2d0 [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0 [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0 [<00000000646c5c2c>] v_msg+0x78/0x120 [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0 • https://git.kernel.org/stable/c/e126ba97dba9edeb6fafa3665b5f8497fc9cdf8c https://git.kernel.org/stable/c/4f7bddf8c5c01cac74373443b13a68e1c6723a94 https://git.kernel.org/stable/c/ed8aafea4fec9c654e63445236e0b505e27ed3a7 https://git.kernel.org/stable/c/94b960b9deffc02fc0747afc01f72cc62ab099e3 •
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 •