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 •
CVSS: 7.8EPSS: 0%CPEs: 7EXPL: 0CVE-2022-48837 – usb: gadget: rndis: prevent integer overflow in rndis_set_response()
https://notcve.org/view.php?id=CVE-2022-48837
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: rndis: prevent integer overflow in rndis_set_response() If "BufOffset" is very large the "BufOffset + 8" operation can have an integer overflow. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: usb: gadget:rndis: previene el desbordamiento de enteros en rndis_set_response() Si "BufOffset" es muy grande la operación "BufOffset + 8" puede tener un desbordamiento de enteros. • https://git.kernel.org/stable/c/ff0a90739925734c91c7e39befe3f4378e0c1369 https://git.kernel.org/stable/c/4c22fbcef778badb00fb8bb9f409daa29811c175 https://git.kernel.org/stable/c/db9aaa3026298d652e98f777bc0f5756e2455dda https://git.kernel.org/stable/c/c9e952871ae47af784b4aef0a77db02e557074d6 https://git.kernel.org/stable/c/fb4ff0f96de37c44236598e8b53fe43b1df36bf3 https://git.kernel.org/stable/c/2da3b0ab54fb7f4d7c5a82757246d0ee33a47197 https://git.kernel.org/stable/c/2724ebafda0a8df08a9cb91557d33226bee80f7b https://git.kernel.org/stable/c/8b3e4d26bc9cd0f6373d0095b9ffd99e7 • CWE-190: Integer Overflow or Wraparound •
CVSS: 5.5EPSS: 0%CPEs: 10EXPL: 0CVE-2022-48836 – Input: aiptek - properly check endpoint type
https://notcve.org/view.php?id=CVE-2022-48836
In the Linux kernel, the following vulnerability has been resolved: Input: aiptek - properly check endpoint type Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint. Fix it by replacing old desc.bNumEndpoints check with usb_find_common_endpoints() helper for finding endpoints Fail log: usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usb_hub_wq hub_event ... Call Trace: <TASK> aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830 input_open_device+0x1bb/0x320 drivers/input/input.c:629 kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593 • https://git.kernel.org/stable/c/8e20cf2bce122ce9262d6034ee5d5b76fbb92f96 https://git.kernel.org/stable/c/90eb3c037fe3f0f25f01713a92725a8daa2b41f3 https://git.kernel.org/stable/c/a7c0ba06670f99c252d5bb74258dddbf50fef837 https://git.kernel.org/stable/c/57277a8b5d881e02051ba9d7f6cb3f915c229821 https://git.kernel.org/stable/c/fc8033a55e2796d21e370260a784ac9fbb8305a6 https://git.kernel.org/stable/c/6de20111cd0bb7da9b2294073ba00c7d2a6c1c4f https://git.kernel.org/stable/c/e732b0412f8c603d1e998f3bff41b5e7d5c3914c https://git.kernel.org/stable/c/f0d43d22d24182b94d7eb78a2bf6ae7e2 •