Page 170 of 2704 results (0.007 seconds)

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: add a proper sanity check for endpoints Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> [2] Related syzkaller crashes: En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: carl9170: agregue una verificación de integridad adecuada para los endpoints Syzkaller informa [1] que aparece una advertencia causada por la presencia de un tipo de endpoint incorrecto en la etapa de envío de URB. Si bien hubo una verificación para un cuarto endpoint específico, dado que puede cambiar de tipo entre masivo e interrupción, se confía implícitamente en otros endpoints. Se activa una advertencia similar en un par de otros problemas de syzbot [2]. Solucione el problema realizando una verificación exhaustiva de todos los endpoints teniendo en cuenta la diferencia entre la configuración de alta y máxima velocidad. [1] Informe de Syzkaller: ... • https://git.kernel.org/stable/c/a84fab3cbfdc427e7d366f1cc844f27b2084c26c https://git.kernel.org/stable/c/eb0f2fc3ff5806cc572cd9055ce7c52a01e97645 https://git.kernel.org/stable/c/ac3ed46a8741d464bc70ebdf7433c1d786cf329d https://git.kernel.org/stable/c/8650725bb0a48b206d5a8ddad3a7488f9a5985b7 https://git.kernel.org/stable/c/6a9892bf24c906b4d6b587f8759ca38bff672582 https://git.kernel.org/stable/c/265c3cda471c26e0f25d0c755da94e1eb15d7a0c https://git.kernel.org/stable/c/62eb07923f3693d55b0c2d9a5a4f1ad72cb6b8fd https://git.kernel.org/stable/c/03ddc74bdfd71b84a55c9f2185d8787f2 •

CVSS: 6.5EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: wifi: ar5523: enable proper endpoint verification Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ar5523: habilite la verificación adecuada del endpoint Syzkaller informa [1] que aparece una advertencia sobre un endpoint en uso que no tiene el tipo esperado. Solucione el problema verificando la existencia de todos los endpoints adecuados con sus tipos correspondientes intactos. Lamentablemente, este parche no se ha probado en hardware real. [1] Informe Syzkaller: ------------[ cortar aquí ]------------ usb 1-1: BOGUS urb xfer, tubería 3 != tipo 1 ADVERTENCIA : CPU: 0 PID: 3643 en drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... • https://git.kernel.org/stable/c/b7d572e1871df06a96a1c9591c71c5494ff6b624 https://git.kernel.org/stable/c/79ddf5f2020fd593d50f1363bb5131283d74f78f https://git.kernel.org/stable/c/68a5a00c5d38978a3f8460c6f182f7beec8688ff https://git.kernel.org/stable/c/ee25389df80138907bc9dcdf4a2be2067cde9a81 https://git.kernel.org/stable/c/b4c24de37a6bb383394a6fef2b85a6db41d426f5 https://git.kernel.org/stable/c/34f7ebff1b9699e0b89fa58b693bc098c2f5ec72 https://git.kernel.org/stable/c/b33a81e4ecfb022b028cae37d1c1ce28ac1b359d https://git.kernel.org/stable/c/beeed260b92af158592f5e8d2dab65dae •

CVSS: -EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Ensure the copied buf is NUL terminated Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: bfa: asegúrese de que el buf copiado tenga terminación NUL. Actualmente, asignamos un búfer del kernel de tamaño nbytes y copiamos nbytes del espacio de usuario a ese búfer. • https://git.kernel.org/stable/c/9f30b674759b9a2da25aefe25d885161d8a911cb https://git.kernel.org/stable/c/481fc0c8617304a67649027c4a44723a139a0462 https://git.kernel.org/stable/c/595a6b98deec01b6dbb20139f71edcd5fb760ec2 https://git.kernel.org/stable/c/00b425ff0891283207d7bad607a2412225274d7a https://git.kernel.org/stable/c/1708e3cf2488788cba5489e4f913d227de757baf https://git.kernel.org/stable/c/7d3e694c4fe30f3aba9cd5ae86fb947a54c3db5c https://git.kernel.org/stable/c/204714e68015d6946279719fd464ecaf57240f35 https://git.kernel.org/stable/c/7510fab46b1cbd1680e2a096e779aec33 •

CVSS: 4.4EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Ensure the copied buf is NUL terminated Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: scsi: qedf: asegúrese de que el buf copiado tenga terminación NUL. Actualmente, asignamos un búfer del kernel del tamaño de un conteo y copiamos el conteo desde el espacio de usuario a ese búfer. • https://git.kernel.org/stable/c/61d8658b4a435eac729966cc94cdda077a8df5cd https://git.kernel.org/stable/c/1f84a2744ad813be23fc4be99fb74bfb24aadb95 https://git.kernel.org/stable/c/a75001678e1d38aa607d5b898ec7ff8ed0700d59 https://git.kernel.org/stable/c/769b9fd2af02c069451fe9108dba73355d9a021c https://git.kernel.org/stable/c/dccd97b39ab2f2b1b9a47a1394647a4d65815255 https://git.kernel.org/stable/c/d93318f19d1e1a6d5f04f5d965eaa9055bb7c613 https://git.kernel.org/stable/c/563e609275927c0b75fbfd0d90441543aa7b5e0d https://git.kernel.org/stable/c/4907f5ad246fa9b51093ed7dfc7da9ebb • CWE-125: Out-of-bounds Read CWE-476: NULL Pointer Dereference •

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

In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix overwriting ct original tuple for ICMPv6 OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet. OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure with the metadata like conntrack state, input port, recirculation id, etc. Then the packet itself gets parsed to populate the rest of the keys from the packet headers. Whenever the packet parsing code starts parsing the ICMPv6 header, it first zeroes out fields in the key corresponding to Neighbor Discovery information even if it is not an ND packet. It is an 'ipv6.nd' field. However, the 'ipv6' is a union that shares the space between 'nd' and 'ct_orig' that holds the original tuple conntrack metadata parsed from the OVS_PACKET_ATTR_KEY. ND packets should not normally have conntrack state, so it's fine to share the space, but normal ICMPv6 Echo packets or maybe other types of ICMPv6 can have the state attached and it should not be overwritten. The issue results in all but the last 4 bytes of the destination address being wiped from the original conntrack tuple leading to incorrect packet matching and potentially executing wrong actions in case this packet recirculates within the datapath or goes back to userspace. ND fields should not be accessed in non-ND packets, so not clearing them should be fine. Executing memset() only for actual ND packets to avoid the issue. Initializing the whole thing before parsing is needed because ND packet may not contain all the options. The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't affect packets entering OVS datapath from network interfaces, because in this case CT metadata is populated from skb after the packet is already parsed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: openvswitch: corrige la sobrescritura de la tupla original de ct para ICMPv6 OVS_PACKET_CMD_EXECUTE tiene 3 atributos principales: - OVS_PACKET_ATTR_KEY - Metadatos de paquetes en formato netlink. - OVS_PACKET_ATTR_PACKET: contenido del paquete binario. - OVS_PACKET_ATTR_ACTIONS: acciones a ejecutar en el paquete. • https://git.kernel.org/stable/c/9dd7f8907c3705dc7a7a375d1c6e30b06e6daffc https://git.kernel.org/stable/c/6a51ac92bf35d34b4996d6eb67e2fe469f573b11 https://git.kernel.org/stable/c/0b532f59437f688563e9c58bdc1436fefa46e3b5 https://git.kernel.org/stable/c/5ab6aecbede080b44b8e34720ab72050bf1e6982 https://git.kernel.org/stable/c/483eb70f441e2df66ade78aa7217e6e4caadfef3 https://git.kernel.org/stable/c/9ec8b0ccadb908d92f7ee211a4eff05fd932f3f6 https://git.kernel.org/stable/c/78741b4caae1e880368cb2f5110635f3ce45ecfd https://git.kernel.org/stable/c/431e9215576d7b728f3f53a704d237a52 • CWE-665: Improper Initialization •