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: 5.5EPSS: 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 https://access.redhat.com/security/cve/CVE-2021-47435 • CWE-476: NULL Pointer Dereference •
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: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52878 – can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
https://notcve.org/view.php?id=CVE-2023-52878
In the Linux kernel, the following vulnerability has been resolved: can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds If the "struct can_priv::echoo_skb" is accessed out of bounds, this would cause a kernel crash. Instead, issue a meaningful warning message and return with an error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: dev: can_put_echo_skb(): no bloquee el kernel si se accede a can_priv::echo_skb fuera de los límites. Si se accede a "struct can_priv::echoo_skb" fuera de los límites, esto provocaría un fallo del kernel. En su lugar, emita un mensaje de advertencia significativo y regrese con un error. • https://git.kernel.org/stable/c/a6e4bc5304033e434fabccabb230b8e9ff55d76f https://git.kernel.org/stable/c/826120c9ba68f2d0dbae58e99013929c883d1444 https://git.kernel.org/stable/c/0d30931f1fa0fb893fb7d5dc32b6b7edfb775be4 https://git.kernel.org/stable/c/53c468008a7c9ca3f5fc985951f35ec2acae85bc https://git.kernel.org/stable/c/8ab67da060157362b2e0926692c659808784708f https://git.kernel.org/stable/c/6411959c10fe917288cbb1038886999148560057 https://access.redhat.com/security/cve/CVE-2023-52878 https://bugzilla.redhat.com/show_bug.cgi?id=2282680 • CWE-125: Out-of-bounds Read •