Page 67 of 2608 results (0.007 seconds)

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

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-&gt;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 &lt;48&gt; 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: 0

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-&gt;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-&gt;driver) add_uevent_var(env, "DRIVER=%s", dev-&gt;driver-&gt;name); y entre la prueba y la desreferencia de dev-&gt;driver, el núcleo del gadget establece dev-&gt;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: 0

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: -EPSS: 0%CPEs: 10EXPL: 0

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 •

CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Fix bug in pipe direction for control transfers The syzbot fuzzer reported a minor bug in the usbtmc driver: usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0 WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Modules linked in: CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [inline] The problem is that usbtmc_ioctl_request() uses usb_rcvctrlpipe() for all of its transfers, whether they are in or out. It's easy to fix. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: usbtmc: corrige un error en la dirección de la tubería para las transferencias de control. El syzbot fuzzer informó un error menor en el controlador usbtmc: usb 5-1: directorio de control BOGUS, la tubería 80001e80 no coincide con bRequestType 0 ADVERTENCIA: CPU: 0 PID: 3813 en drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Módulos vinculados en: CPU: 0 PID: 3813 Comm : syz-executor122 No contaminado 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Seguimiento de llamadas: usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core /message.c:102 [en línea] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [en línea] El problema es que usbtmc_ioctl_request() usa usb_rcvctrlpipe( ) para todas sus transferencias, ya sean de entrada o de salida. • https://git.kernel.org/stable/c/700a0715854c1e79a73341724ce4f5bb01abc016 https://git.kernel.org/stable/c/10a805334a11acd547602d6c4cf540a0f6ab5c6e https://git.kernel.org/stable/c/c69aef9db878ab277068a8cc1b4bf0cf309dc2b7 https://git.kernel.org/stable/c/5f6a2d63c68c12cf61259df7c3527a0e05dce952 https://git.kernel.org/stable/c/e9b667a82cdcfe21d590344447d65daed52b353b •