CVSS: 4.7EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48842 – ice: Fix race condition during interface enslave
https://notcve.org/view.php?id=CVE-2022-48842
In the Linux kernel, the following vulnerability has been resolved: ice: Fix race condition during interface enslave Commit 5dbbbd01cbba83 ("ice: Avoid RTNL lock when re-creating auxiliary device") changes a process of re-creation of aux device so ice_plug_aux_dev() is called from ice_service_task() context. This unfortunately opens a race window that can result in dead-lock when interface has left LAG and immediately enters LAG again. Reproducer: ``` #!/bin/sh ip link add lag0 type bond mode 1 miimon 100 ip link set lag0 for n in {1..10}; do echo Cycle: $n ip link set ens7f0 master lag0 sleep 1 ip link set ens7f0 nomaster done ``` This results in: [20976.208697] Workqueue: ice ice_service_task [ice] [20976.213422] Call Trace: [20976.215871] __schedule+0x2d1/0x830 [20976.219364] schedule+0x35/0xa0 [20976.222510] schedule_preempt_disabled+0xa/0x10 [20976.227043] __mutex_lock.isra.7+0x310/0x420 [20976.235071] enum_all_gids_of_dev_cb+0x1c/0x100 [ib_core] [20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core] [20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core] [20976.261079] ib_register_device+0x40d/0x580 [ib_core] [20976.266139] irdma_ib_register_device+0x129/0x250 [irdma] [20976.281409] irdma_probe+0x2c1/0x360 [irdma] [20976.285691] auxiliary_bus_probe+0x45/0x70 [20976.289790] really_probe+0x1f2/0x480 [20976.298509] driver_probe_device+0x49/0xc0 [20976.302609] bus_for_each_drv+0x79/0xc0 [20976.306448] __device_attach+0xdc/0x160 [20976.310286] bus_probe_device+0x9d/0xb0 [20976.314128] device_add+0x43c/0x890 [20976.321287] __auxiliary_device_add+0x43/0x60 [20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice] [20976.330109] ice_service_task+0xd0c/0xed0 [ice] [20976.342591] process_one_work+0x1a7/0x360 [20976.350536] worker_thread+0x30/0x390 [20976.358128] kthread+0x10a/0x120 [20976.365547] ret_from_fork+0x1f/0x40 ... [20976.438030] task:ip state:D stack: 0 pid:213658 ppid:213627 flags:0x00004084 [20976.446469] Call Trace: [20976.448921] __schedule+0x2d1/0x830 [20976.452414] schedule+0x35/0xa0 [20976.455559] schedule_preempt_disabled+0xa/0x10 [20976.460090] __mutex_lock.isra.7+0x310/0x420 [20976.464364] device_del+0x36/0x3c0 [20976.467772] ice_unplug_aux_dev+0x1a/0x40 [ice] [20976.472313] ice_lag_event_handler+0x2a2/0x520 [ice] [20976.477288] notifier_call_chain+0x47/0x70 [20976.481386] __netdev_upper_dev_link+0x18b/0x280 [20976.489845] bond_enslave+0xe05/0x1790 [bonding] [20976.494475] do_setlink+0x336/0xf50 [20976.502517] __rtnl_newlink+0x529/0x8b0 [20976.543441] rtnl_newlink+0x43/0x60 [20976.546934] rtnetlink_rcv_msg+0x2b1/0x360 [20976.559238] netlink_rcv_skb+0x4c/0x120 [20976.563079] netlink_unicast+0x196/0x230 [20976.567005] netlink_sendmsg+0x204/0x3d0 [20976.570930] sock_sendmsg+0x4c/0x50 [20976.574423] ____sys_sendmsg+0x1eb/0x250 [20976.586807] ___sys_sendmsg+0x7c/0xc0 [20976.606353] __sys_sendmsg+0x57/0xa0 [20976.609930] do_syscall_64+0x5b/0x1a0 [20976.613598] entry_SYSCALL_64_after_hwframe+0x65/0xca 1. Command 'ip link ... set nomaster' causes that ice_plug_aux_dev() is called from ice_service_task() context, aux device is created and associated device->lock is taken. 2. Command 'ip link ... set master...' calls ice's notifier under RTNL lock and that notifier calls ice_unplug_aux_dev(). That function tries to take aux device->lock but this is already taken by ice_plug_aux_dev() in step 1 3. • https://git.kernel.org/stable/c/a9bbacc53d1f5ed8febbfdf31401d20e005f49ef https://git.kernel.org/stable/c/e1014fc5572375658fa421531cedb6e084f477dc https://git.kernel.org/stable/c/5cb1ebdbc4342b1c2ce89516e19808d64417bdbc • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') CWE-667: Improper Locking •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48841 – ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats()
https://notcve.org/view.php?id=CVE-2022-48841
In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats() It is possible to do NULL pointer dereference in routine that updates Tx ring stats. Currently only stats and bytes are updated when ring pointer is valid, but later on ring is accessed to propagate gathered Tx stats onto VSI stats. Change the existing logic to move to next ring when ring is NULL. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrige la desreferencia del puntero NULL en ice_update_vsi_tx_ring_stats() Es posible realizar la desreferencia del puntero NULL en la rutina que actualiza las estadísticas del anillo Tx. Actualmente, solo se actualizan las estadísticas y los bytes cuando el puntero del anillo es válido, pero más adelante se accede al anillo para propagar las estadísticas de Tx recopiladas en las estadísticas de VSI. Cambie la lógica existente para pasar al siguiente anillo cuando el anillo sea NULL. • https://git.kernel.org/stable/c/e72bba21355dbb67512a0d666fec9f4b56dbfc2f https://git.kernel.org/stable/c/2397270ec97c5e3009a58ac110a25e1869e9d6ff https://git.kernel.org/stable/c/f153546913bada41a811722f2c6d17c3243a0333 • CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48840 – iavf: Fix hang during reboot/shutdown
https://notcve.org/view.php?id=CVE-2022-48840
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix hang during reboot/shutdown Recent commit 974578017fc1 ("iavf: Add waiting so the port is initialized in remove") adds a wait-loop at the beginning of iavf_remove() to ensure that port initialization is finished prior unregistering net device. This causes a regression in reboot/shutdown scenario because in this case callback iavf_shutdown() is called and this callback detaches the device, makes it down if it is running and sets its state to __IAVF_REMOVE. Later shutdown callback of associated PF driver (e.g. ice_shutdown) is called. That callback calls among other things sriov_disable() that calls indirectly iavf_remove() (see stack trace below). As the adapter state is already __IAVF_REMOVE then the mentioned loop is end-less and shutdown process hangs. The patch fixes this by checking adapter's state at the beginning of iavf_remove() and skips the rest of the function if the adapter is already in remove state (shutdown is in progress). Reproducer: 1. Create VF on PF driven by ice or i40e driver 2. Ensure that the VF is bound to iavf driver 3. • https://git.kernel.org/stable/c/85aa76066fef64de8a48d0da6b4071ceac455a94 https://git.kernel.org/stable/c/7b9515172ab4d4c6ac0eae4b71013ee6ce932205 https://git.kernel.org/stable/c/80974bb730270199c6fcb189af04d5945b87e813 https://git.kernel.org/stable/c/4477b9a4193b35eb3a8afd2adf2d42add2f88d57 https://git.kernel.org/stable/c/b04683ff8f0823b869c219c78ba0d974bddea0b5 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48839 – net/packet: fix slab-out-of-bounds access in packet_recvmsg()
https://notcve.org/view.php?id=CVE-2022-48839
In the Linux kernel, the following vulnerability has been resolved: net/packet: fix slab-out-of-bounds access in packet_recvmsg() syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH and mmap operations, tpacket_rcv() is queueing skbs with garbage in skb->cb[], triggering a too big copy [1] Presumably, users of af_packet using mmap() already gets correct metadata from the mapped buffer, we can simply make sure to clear 12 bytes that might be copied to user space later. BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline] BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489 Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631 CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 memcpy+0x39/0x60 mm/kasan/shadow.c:66 memcpy include/linux/fortify-string.h:225 [inline] packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fdfd5954c29 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005 RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60 R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54 </TASK> addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame: ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246 this frame has 1 object: [32, 160) 'addr' Memory state around the buggy address: ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 >ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 ^ ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00 ================================================================== En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/packet: corrige el acceso slab-out-of-bounds en paquete_recvmsg() syzbot descubrió que cuando un socket AF_PACKET utiliza operaciones PACKET_COPY_THRESH y mmap, tpacket_rcv() está poniendo en cola skbs con basura en skb->cb[], lo que desencadena una copia demasiado grande [1] Presumiblemente, los usuarios de af_packet que usan mmap() ya obtienen los metadatos correctos del búfer asignado, simplemente podemos asegurarnos de borrar 12 bytes que podrían copiarse al usuario espacio más tarde. ERROR: KASAN: pila fuera de los límites en memcpy include/linux/fortify-string.h:225 [en línea] ERROR: KASAN: pila fuera de los límites en paquete_recvmsg+0x56c/0x1150 net/packet/af_packet. c:3489 Escritura de tamaño 165 en la dirección ffffc9000385fb78 por tarea syz-executor233/3631 CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0 Nombre de hardware: Google Google Compute Engine /Google Compute Engine, BIOS Google 01/01/2011 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf /0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [en línea] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [en línea] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 memcpy+0x39/0x60 mm/kasan/shadow.c:66 memcpy include/linux/fortify-string.h:225 [en línea] paquete_recvmsg+0x56c/ 0x1150 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:948 [en línea] sock_recvmsg net/socket.c:966 [en línea] sock_recvmsg net/socket.c:962 [en línea] ____sys_recvmsg+0x2c4/0x600 net/ socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [en línea] arco xb0 /x86/entry/common.c:80 Entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fdfd5954c29 Código: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcf8e71e48 EFLAGS: 0000246 ORIG_RAX: 000000000000002f RAX : ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 000000000000005 RBP: 0000000 000000000 R08: 000000000000000d R09: 000000000000000d R10: 0000000000000000 R11: 00000000000000246 R12: 00007ffcf8e71e60 R13: 0000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54 dirección ffffc9000385fb78 está ubicado en la pila de la tarea syz-executor233/3631 en el desplazamiento 32 en el marco: ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246 este marco tiene 1 objeto: [32, 160) 'addr' Estado de memoria alrededor del buggy dirección: ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 c9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 ^ ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 0 0 00 00 00 00 ====== ==================================================== ========== • https://git.kernel.org/stable/c/0fb375fb9b93b7d822debc6a734052337ccfdb1f https://git.kernel.org/stable/c/b9d5772d60f8e7ef34e290f72fc20e3a4883e7d0 https://git.kernel.org/stable/c/b1e27cda1e3c12b705875bb7e247a97168580e33 https://git.kernel.org/stable/c/a33dd1e6693f80d805155b3f69c18c2f642915da https://git.kernel.org/stable/c/268dcf1f7b3193bc446ec3d14e08a240e9561e4d https://git.kernel.org/stable/c/70b7b3c055fd4a464da8da55ff4c1f84269f9b02 https://git.kernel.org/stable/c/a055f5f2841f7522b44a2b1eccb1951b4b03d51a https://git.kernel.org/stable/c/ef591b35176029fdefea38e8388ffa371 • CWE-125: Out-of-bounds Read •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48838 – usb: gadget: Fix use-after-free bug by not setting udc->dev.driver
https://notcve.org/view.php?id=CVE-2022-48838
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: Fix use-after-free bug by not setting udc->dev.driver The syzbot fuzzer found a use-after-free bug: BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320 Read of size 8 at addr ffff88802b934098 by task udevd/3689 CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 dev_uevent+0x712/0x780 drivers/base/core.c:2320 uevent_show+0x1b8/0x380 drivers/base/core.c:2391 dev_attr_show+0x4b/0x90 drivers/base/core.c:2094 Although the bug manifested in the driver core, the real cause was a race with the gadget core. dev_uevent() does: if (dev->driver) add_uevent_var(env, "DRIVER=%s", dev->driver->name); and between the test and the dereference of dev->driver, the gadget core sets dev->driver to NULL. The race wouldn't occur if the gadget core registered its devices on a real bus, using the standard synchronization techniques of the driver core. However, it's not necessary to make such a large change in order to fix this bug; all we need to do is make sure that udc->dev.driver is always NULL. In fact, there is no reason for udc->dev.driver ever to be set to anything, let alone to the value it currently gets: the address of the gadget's driver. After all, a gadget driver only knows how to manage a gadget, not how to manage a UDC. This patch simply removes the statements in the gadget core that touch udc->dev.driver. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: corrige el error de use-after-free al no configurar udc->dev.driver El syzbot fuzzer encontró un error de use-after-free: ERROR: KASAN: uso- after-free en dev_uevent+0x712/0x780 drivers/base/core.c:2320 Lectura de tamaño 8 en addr ffff88802b934098 por tarea udevd/3689 CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229 -g4f12b742eb2b #0 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.14.0-2 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xcd/ 0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [en línea] kasan_report.cold+0x83/0xdf mm/ kasan/report.c:459 dev_uevent+0x712/0x780 drivers/base/core.c:2320 uevent_show+0x1b8/0x380 drivers/base/core.c:2391 dev_attr_show+0x4b/0x90 drivers/base/core.c:2094 Aunque El error se manifestó en el núcleo del controlador, la verdadera causa fue una ejecución con el núcleo del dispositivo. dev_uevent() hace: if (dev->driver) add_uevent_var(env, "DRIVER=%s", dev->driver->name); y entre la prueba y la desreferencia de dev->driver, el núcleo del gadget establece dev->driver en NULL. • https://git.kernel.org/stable/c/2ccea03a8f7ec93641791f2760d7cdc6cab6205f https://git.kernel.org/stable/c/4325124dde6726267813c736fee61226f1d38f0b https://git.kernel.org/stable/c/e2d3a7009e505e120805f449c832942660f3f7f3 https://git.kernel.org/stable/c/609a7119bffe3ddd7c93f2fa65be8917e02a0b7e https://git.kernel.org/stable/c/2282a6eb6d4e118e294e43dcc421e0e0fe4040b5 https://git.kernel.org/stable/c/00bdd9bf1ac6d401ad926d3d8df41b9f1399f646 https://git.kernel.org/stable/c/2015c23610cd0efadaeca4d3a8d1dae9a45aa35a https://git.kernel.org/stable/c/27d64436984fb8835a8b7e95993193cc4 • CWE-416: Use After Free •