CVSS: 4.7EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48650 – scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts()
https://notcve.org/view.php?id=CVE-2022-48650
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts() Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") made the __qlt_24xx_handle_abts() function return early if tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean up the allocated memory for the management command. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qla2xxx: Reparar pérdida de memoria en __qlt_24xx_handle_abts() el commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") hizo que la función __qlt_24xx_handle_abts() regresara antes si tcm_qla2xxx_find_cmd_by_tag() no lo hizo encontró un comando, pero no pudo limpiar la memoria asignada para el comando de administración. • https://git.kernel.org/stable/c/8f394da36a361cbe0e1e8b1d4213e5598c8095ac https://git.kernel.org/stable/c/89df49e561b4a8948521fc3f8a013012eaa08f82 https://git.kernel.org/stable/c/6a4236ed47f5b0a57eb6b8fb1c351b15b3d341d7 https://git.kernel.org/stable/c/601be20fc6a1b762044d2398befffd6bf236cebf •
CVSS: -EPSS: 0%CPEs: 1EXPL: 0CVE-2022-48649 – mm/slab_common: fix possible double free of kmem_cache
https://notcve.org/view.php?id=CVE-2022-48649
In the Linux kernel, the following vulnerability has been resolved: mm/slab_common: fix possible double free of kmem_cache When doing slub_debug test, kfence's 'test_memcache_typesafe_by_rcu' kunit test case cause a use-after-free error: BUG: KASAN: use-after-free in kobject_del+0x14/0x30 Read of size 8 at addr ffff888007679090 by task kunit_try_catch/261 CPU: 1 PID: 261 Comm: kunit_try_catch Tainted: G B N 6.0.0-rc5-next-20220916 #17 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x34/0x48 print_address_description.constprop.0+0x87/0x2a5 print_report+0x103/0x1ed kasan_report+0xb7/0x140 kobject_del+0x14/0x30 kmem_cache_destroy+0x130/0x170 test_exit+0x1a/0x30 kunit_try_run_case+0xad/0xc0 kunit_generic_run_threadfn_adapter+0x26/0x50 kthread+0x17b/0x1b0 </TASK> The cause is inside kmem_cache_destroy(): kmem_cache_destroy acquire lock/mutex shutdown_cache schedule_work(kmem_cache_release) (if RCU flag set) release lock/mutex kmem_cache_release (if RCU flag not set) In some certain timing, the scheduled work could be run before the next RCU flag checking, which can then get a wrong value and lead to double kmem_cache_release(). Fix it by caching the RCU flag inside protected area, just like 'refcnt' En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/slab_common: corrección posible doble liberación de kmem_cache Al realizar la prueba slub_debug, el caso de prueba kunit 'test_memcache_typesafe_by_rcu' de kfence causa un error de use-after-free: ERROR: KASAN: uso después -free en kobject_del+0x14/0x30 Lectura de tamaño 8 en addr ffff888007679090 por tarea kunit_try_catch/261 CPU: 1 PID: 261 Comm: kunit_try_catch Contaminado: GBN 6.0.0-rc5-next-20220916 #17 Nombre de hardware: PC estándar QEMU ( I440FX+PIIX, 1996), BIOS 1.15.0-1 04/01/2014 TRACE DE LLAMADA: dump_stack_lvl+0x34/0x48 print_address_description.constprop.0+0x87/0x2a5 print_rePort+0x103/0x1ed kasan_report+0xb7/0x140/0x140/0x140+0xb7/0x140/0x140/0x140/0x14/0x140/0xil 0x14/0x30 kmem_cache_destroy+0x130/0x170 test_exit+0x1a/0x30 kunit_try_run_case+0xad/0xc0 kunit_generic_run_threadfn_adapter+0x26/0x50 kthread+0x17b/0x1b0 La causa está dentro de kmem_cache_destroy (): kmem_cache_destroy adquirir bloqueo/mutex Shutdown_cache Schedule_work(kmem_cache_release) (si el indicador RCU está establecido) liberar bloqueo/mutex kmem_cache_release (si el indicador RCU no está establecido) En un momento determinado, el trabajo programado podría ejecutarse antes de la siguiente verificación del indicador RCU, lo que luego puede obtener un valor incorrecto y provocar un doble kmem_cache_release() . Solucionarlo almacenando en caché la bandera RCU dentro del área protegida, como 'refcnt' • https://git.kernel.org/stable/c/357321557920c805de2b14832002465c320eea4f https://git.kernel.org/stable/c/c673c6ceac53fb2e631c9fbbd79957099a08927f https://git.kernel.org/stable/c/d71608a877362becdc94191f190902fac1e64d35 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48648 – sfc: fix null pointer dereference in efx_hard_start_xmit
https://notcve.org/view.php?id=CVE-2022-48648
In the Linux kernel, the following vulnerability has been resolved: sfc: fix null pointer dereference in efx_hard_start_xmit Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it. I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc: corrige la desreferencia del puntero nulo en efx_hard_start_xmit Intentar obtener el canal de la variable tx_queue aquí es incorrecto porque solo podemos estar aquí si tx_queue es NULL, por lo que no debemos desreferenciarlo. Como dice el comentario anterior en el código, es muy poco probable que esto suceda, pero de todos modos está mal, así que solucionémoslo. Encontré este problema debido a un error diferente que provocó que tx_queue fuera NULL. • https://git.kernel.org/stable/c/12804793b17c0e19115a90d98f2f3df0cb79e233 https://git.kernel.org/stable/c/b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7 https://git.kernel.org/stable/c/8547c7bfc0617e7184e4da65b9b96681fcfe9998 https://git.kernel.org/stable/c/b3b952168ee1f220ba729fa100fd9d5aa752eb03 https://git.kernel.org/stable/c/0a242eb2913a4aa3d6fbdb86559f27628e9466f3 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48647 – sfc: fix TX channel offset when using legacy interrupts
https://notcve.org/view.php?id=CVE-2022-48647
In the Linux kernel, the following vulnerability has been resolved: sfc: fix TX channel offset when using legacy interrupts In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but that's not correct if efx_sepparate_tx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue. Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sfc: corrige el desplazamiento del canal TX cuando se usan interrupciones heredadas En el modo de interrupción heredado, tx_channel_offset estaba codificado en 1, pero eso no es correcto si efx_sepparate_tx_channels es falso. En ese caso, el desplazamiento es 0 porque las colas de transmisión están en el único canal existente en el índice 0, junto con la cola de recepción. Sin esta solución, tan pronto como intenta enviar tráfico, intenta obtener las colas de transmisión de un canal no inicializado y obtiene estos errores: ADVERTENCIA: CPU: 1 PID: 0 en drivers/net/ethernet/sfc/tx.c: 540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] • https://git.kernel.org/stable/c/bf2af9b24313553f3f0b30443220ab0ac8595d2d https://git.kernel.org/stable/c/06cb7e134f8f4a11b66f1dbeb5f237412a0aeedc https://git.kernel.org/stable/c/c308dfd1b43ef0d4c3e57b741bb3462eb7a7f4a2 https://git.kernel.org/stable/c/1a7c0b3ef93d1d1dae7b0a85dab3ac6e3ad0ef61 https://git.kernel.org/stable/c/b2d60329a0b88c4e35017436ee29c43be59d46a5 https://git.kernel.org/stable/c/b4afd3878f961d3517f27b3213730fceef77945c https://git.kernel.org/stable/c/360910b88d1466a90644a4e0533803b594344a2b https://git.kernel.org/stable/c/5f623a77cfc2d501d72bcb4f9ee71721e •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48646 – sfc/siena: fix null pointer dereference in efx_hard_start_xmit
https://notcve.org/view.php?id=CVE-2022-48646
In the Linux kernel, the following vulnerability has been resolved: sfc/siena: fix null pointer dereference in efx_hard_start_xmit Like in previous patch for sfc, prevent potential (but unlikely) NULL pointer dereference. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sfc/siena: corrige la desreferencia del puntero nulo en efx_hard_start_xmit Al igual que en el parche anterior para sfc, evita una posible (pero poco probable) desreferencia del puntero NULL. • https://git.kernel.org/stable/c/12804793b17c0e19115a90d98f2f3df0cb79e233 https://git.kernel.org/stable/c/a4eadca702dff0768dd01be6789bbec2a18e5b0a https://git.kernel.org/stable/c/589c6eded10c77a12b7b2cf235b6b19a2bdb91fa • CWE-476: NULL Pointer Dereference •