CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48652 – ice: Fix crash by keep old cfg when update TCs more than queues
https://notcve.org/view.php?id=CVE-2022-48652
In the Linux kernel, the following vulnerability has been resolved: ice: Fix crash by keep old cfg when update TCs more than queues There are problems if allocated queues less than Traffic Classes. Commit a632b2a4c920 ("ice: ethtool: Prohibit improper channel config for DCB") already disallow setting less queues than TCs. Another case is if we first set less queues, and later update more TCs config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access. [ 95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated. [ 95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)! [ 95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0 [ 95.969621] general protection fault: 0000 [#1] SMP NOPTI [ 95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G U W O --------- -t - 4.18.0 #1 [ 95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021 [ 95.969992] RIP: 0010:devm_kmalloc+0xa/0x60 [ 95.970052] Code: 5c ff ff ff 31 c0 5b 5d 41 5c c3 b8 f4 ff ff ff eb f4 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 89 d1 <8b> 97 60 02 00 00 48 8d 7e 18 48 39 f7 72 3f 55 89 ce 53 48 8b 4c [ 95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206 [ 95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0 [ 95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200 [ 95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000 [ 95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100 [ 95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460 [ 95.970981] FS: 00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000 [ 95.971108] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0 [ 95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 95.971530] PKRU: 55555554 [ 95.971573] Call Trace: [ 95.971622] ice_setup_rx_ring+0x39/0x110 [ice] [ 95.971695] ice_vsi_setup_rx_rings+0x54/0x90 [ice] [ 95.971774] ice_vsi_open+0x25/0x120 [ice] [ 95.971843] ice_open_internal+0xb8/0x1f0 [ice] [ 95.971919] ice_ena_vsi+0x4f/0xd0 [ice] [ 95.971987] ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice] [ 95.972082] ice_pf_dcb_cfg+0x29a/0x380 [ice] [ 95.972154] ice_dcbnl_setets+0x174/0x1b0 [ice] [ 95.972220] dcbnl_ieee_set+0x89/0x230 [ 95.972279] ? dcbnl_ieee_del+0x150/0x150 [ 95.972341] dcb_doit+0x124/0x1b0 [ 95.972392] rtnetlink_rcv_msg+0x243/0x2f0 [ 95.972457] ? dcb_doit+0x14d/0x1b0 [ 95.972510] ? __kmalloc_node_track_caller+0x1d3/0x280 [ 95.972591] ? • https://git.kernel.org/stable/c/a632b2a4c920ce5af29410fb091f7ee6d2e77dc6 https://git.kernel.org/stable/c/4520c4bf4dca7aa285f30cb1ca8c08c531bbf0e9 https://git.kernel.org/stable/c/7c945e5b4787db47d728120b56c934ba05f99864 https://git.kernel.org/stable/c/a509702cac95a8b450228a037c8542f57e538e5b •
CVSS: 7.7EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48651 – ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header
https://notcve.org/view.php?id=CVE-2022-48651
In the Linux kernel, the following vulnerability has been resolved: ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header If an AF_PACKET socket is used to send packets through ipvlan and the default xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following: ================================================================= UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6 ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 all Trace: print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380 packet_direct_xmit+0x22/0x60 packet_snd+0x7c9/0xc40 sock_sendmsg+0x9a/0xa0 __sys_sendto+0x18a/0x230 __x64_sys_sendto+0x74/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is: 1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit() In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which use "skb->head + skb->mac_header", out-of-bound access occurs. This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2() and reset mac header in multicast to solve this out-of-bound bug. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipvlan: corrige errores fuera de los límites causados por skb->mac_header no configurado si se usa un socket AF_PACKET para enviar paquetes a través de ipvlan y se cambia la función xmit predeterminada del socket AF_PACKET desde dev_queue_xmit() a paquete_direct_xmit() a través de setsockopt() con el nombre de opción PACKET_QDISC_BYPASS, es posible que skb->mac_header no se restablezca y permanezca en el valor inicial de 65535, esto puede desencadenar errores de losa fuera de los límites como se muestra a continuación : =================================================== ================ UG: KASAN: losa fuera de los límites en ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: cargado No contaminado 6.0.0-rc4+ #6 nombre de hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 todo Seguimiento: print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+ 0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380 paquete_direct_xmit+0x22/0x60 paquete_snd+0x7c9/0xc40 0x9a/0xa0 __sys_sendto+0x18a/0x230 __x64_sys_sendto+0x74/0x90 do_syscall_64 +0x3b/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd La causa principal es: 1. paquete_snd() solo restablece skb->mac_header cuando sock->tipo es SOCK_RAW y skb->protocolo no se especifica como en paquete_parse_headers() 2. paquete_direct_xmit() no restablece skb->mac_header como dev_queue_xmit() En este caso, skb->mac_header es 65535 cuando se llama a ipvlan_xmit_mode_l2(). Entonces, cuando ipvlan_xmit_mode_l2() obtiene el encabezado mac con eth_hdr() que usa "skb->head + skb->mac_header", se produce un acceso fuera de los límites. Este parche reemplaza eth_hdr() con skb_eth_hdr() en ipvlan_xmit_mode_l2() y restablece el encabezado de mac en multidifusión para resolver este error fuera de los límites. • https://git.kernel.org/stable/c/2ad7bf3638411cb547f2823df08166c13ab04269 https://git.kernel.org/stable/c/e2b46cd5796f083e452fbc624f65b80328b0c1a4 https://git.kernel.org/stable/c/25efdbe5fe542c3063d1948cc4e98abcb57621ca https://git.kernel.org/stable/c/bffcdade259c05ab3436b5fab711612093c275ef https://git.kernel.org/stable/c/346e94aa4a99378592c46d6a34c72703a32bd5be https://git.kernel.org/stable/c/ab4a733874ead120691e8038272d22f8444d3638 https://git.kernel.org/stable/c/8d06006c7eb75587d986da46c48ba9274f94e8e7 https://git.kernel.org/stable/c/b583e6b25bf9321c91154f6c78d2173ef • CWE-125: Out-of-bounds Read •
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 •