Page 192 of 4234 results (0.005 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: ep0: fix NULL pointer exception There is no validation of the index from dwc3_wIndex_to_dep() and we might be referring a non-existing ep and trigger a NULL pointer exception. In certain configurations we might use fewer eps and the index might wrongly indicate a larger ep index than existing. By adding this validation from the patch we can actually report a wrong index back to the caller. In our usecase we are using a composite device on an older kernel, but upstream might use this fix also. Unfortunately, I cannot describe the hardware for others to reproduce the issue as it is a proprietary implementation. [ 82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4 [ 82.966891] Mem abort info: [ 82.969663] ESR = 0x96000006 [ 82.972703] Exception class = DABT (current EL), IL = 32 bits [ 82.978603] SET = 0, FnV = 0 [ 82.981642] EA = 0, S1PTW = 0 [ 82.984765] Data abort info: [ 82.987631] ISV = 0, ISS = 0x00000006 [ 82.991449] CM = 0, WnR = 0 [ 82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc [ 83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000 [ 83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c) [ 83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1 [ 83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c [ 83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94 ... [ 83.141788] Call trace: [ 83.144227] dwc3_ep0_handle_feature+0x414/0x43c [ 83.148823] dwc3_ep0_interrupt+0x3b4/0xc94 [ 83.181546] ---[ end trace aac6b5267d84c32f ]--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: dwc3: ep0: corrige excepción de puntero NULL. No hay validación del índice desde dwc3_wIndex_to_dep() y podríamos estar haciendo referencia a un ep inexistente y desencadenar una excepción de puntero NULL. En ciertas configuraciones, podríamos usar menos eps y el índice podría indicar erróneamente un índice ep mayor que el existente. • https://git.kernel.org/stable/c/96b74a99d360235c24052f1d060e64ac53f43528 https://git.kernel.org/stable/c/60156089f07e724e4dc8483702d5e1ede4522749 https://git.kernel.org/stable/c/990dc90750772622d44ca2ea6652c521e6f67e16 https://git.kernel.org/stable/c/bd551e7c85939de2182010273450bfa78c3742fc https://git.kernel.org/stable/c/366369b89bedd59b1425386e8d4a18a466e420e4 https://git.kernel.org/stable/c/470403639114895e2697c766fbe17be8d0e9b67a https://git.kernel.org/stable/c/788755756dd4a6aba1de479fec20b0fa600e7f19 https://git.kernel.org/stable/c/d00889080ab60051627dab1d85831cd9d •

CVSS: 6.3EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: usb: fix various gadget panics on 10gbps cabling usb_assign_descriptors() is called with 5 parameters, the last 4 of which are the usb_descriptor_header for: full-speed (USB1.1 - 12Mbps [including USB1.0 low-speed @ 1.5Mbps), high-speed (USB2.0 - 480Mbps), super-speed (USB3.0 - 5Gbps), super-speed-plus (USB3.1 - 10Gbps). The differences between full/high/super-speed descriptors are usually substantial (due to changes in the maximum usb block size from 64 to 512 to 1024 bytes and other differences in the specs), while the difference between 5 and 10Gbps descriptors may be as little as nothing (in many cases the same tuning is simply good enough). However if a gadget driver calls usb_assign_descriptors() with a NULL descriptor for super-speed-plus and is then used on a max 10gbps configuration, the kernel will crash with a null pointer dereference, when a 10gbps capable device port + cable + host port combination shows up. (This wouldn't happen if the gadget max-speed was set to 5gbps, but it of course defaults to the maximum, and there's no real reason to artificially limit it) The fix is to simply use the 5gbps descriptor as the 10gbps descriptor, if a 10gbps descriptor wasn't provided. Obviously this won't fix the problem if the 5gbps descriptor is also NULL, but such cases can't be so trivially solved (and any such gadgets are unlikely to be used with USB3 ports any way). En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: corrige varios fallos de dispositivos en cableado de 10 gbps usb_assign_descriptors() se llama con 5 parámetros, los últimos 4 de los cuales son usb_descriptor_header para: velocidad completa (USB1.1 - 12Mbps [ incluyendo USB1.0 de baja velocidad a 1,5 Mbps), alta velocidad (USB2.0 - 480 Mbps), súper velocidad (USB3.0 - 5 Gbps), súper velocidad plus (USB3.1 - 10 Gbps). Las diferencias entre los descriptores de velocidad completa/alta/supervelocidad suelen ser sustanciales (debido a cambios en el tamaño máximo del bloque USB de 64 a 512 a 1024 bytes y otras diferencias en las especificaciones), mientras que la diferencia entre los descriptores de 5 y 10 Gbps puede ser tan casi nada (en muchos casos, la misma afinación es simplemente suficiente). Sin embargo, si un controlador de dispositivo llama a usb_assign_descriptors() con un descriptor NULL para super-speed-plus y luego se usa en una configuración máxima de 10 gbps, el kernel fallará con una desreferencia de puntero null, cuando un puerto de dispositivo con capacidad de 10 gbps + cable + puerto de host Aparece la combinación. (Esto no sucedería si la velocidad máxima del dispositivo estuviera configurada en 5 gbps, pero, por supuesto, está predeterminada al máximo y no hay ninguna razón real para limitarla artificialmente). • https://git.kernel.org/stable/c/fd24be23abf3e94260be0f00bb42c7e91d495f87 https://git.kernel.org/stable/c/70cd19cb5bd94bbb5bacfc9c1e4ee0071699a604 https://git.kernel.org/stable/c/45f9a2fe737dc0a5df270787f2231aee8985cd59 https://git.kernel.org/stable/c/5ef23506695b01d5d56a13a092a97f2478069d75 https://git.kernel.org/stable/c/b972eff874637402ddc4a7dd11fb22538a0b6d28 https://git.kernel.org/stable/c/ca6bc277430d90375452b60b047763a090b7673e https://git.kernel.org/stable/c/032e288097a553db5653af552dd8035cd2a0ba96 •

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

In the Linux kernel, the following vulnerability has been resolved: RDMA: Verify port when creating flow rule Validate port value provided by the user and with that remove no longer needed validation by the driver. The missing check in the mlx5_ib driver could cause to the below oops. Call trace: _create_flow_rule+0x2d4/0xf28 [mlx5_ib] mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib] ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs] ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs] ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs] do_vfs_ioctl+0xd0/0xaf0 ksys_ioctl+0x84/0xb4 __arm64_sys_ioctl+0x28/0xc4 el0_svc_common.constprop.3+0xa4/0x254 el0_svc_handler+0x84/0xa0 el0_svc+0x10/0x26c Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a) En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: RDMA: Verificar puerto al crear regla de flujo. Validar valor de puerto proporcionado por el usuario y con ello eliminar la validación que ya no necesita el controlador. La verificación que falta en el controlador mlx5_ib podría provocar los siguientes errores. Seguimiento de llamadas: _create_flow_rule+0x2d4/0xf28 [mlx5_ib] mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib] ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x1 50 [ib_uverbs] ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs] ib_uverbs_ioctl+0x158 /0x1d0 [ib_uverbs] do_vfs_ioctl+0xd0/0xaf0 ksys_ioctl+0x84/0xb4 __arm64_sys_ioctl+0x28/0xc4 el0_svc_common.constprop.3+0xa4/0x254 el0_svc_handler+0x84/0xa0 0x10/0x26c Código: b9401260 f9615681 51000400 8b001c20 (f9403c1a) • https://git.kernel.org/stable/c/436f2ad05a0b65b1467ddf51bc68171c381bf844 https://git.kernel.org/stable/c/8dc1b0e0ca204596c50bcd159ee069ae0f998176 https://git.kernel.org/stable/c/2adcb4c5a52a2623cd2b43efa7041e74d19f3a5e •

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

In the Linux kernel, the following vulnerability has been resolved: NFS: Fix a potential NULL dereference in nfs_get_client() None of the callers are expecting NULL returns from nfs_get_client() so this code will lead to an Oops. It's better to return an error pointer. I expect that this is dead code so hopefully no one is affected. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: NFS: corrija una posible desreferencia NULL en nfs_get_client() Ninguna de las personas que llaman espera retornos NULL de nfs_get_client(), por lo que este código generará un error ¡Oops! Es mejor devolver un puntero de error. • https://git.kernel.org/stable/c/31434f496abb9f3410b10f541462fe58613dd3ad https://git.kernel.org/stable/c/fab8bfdfb4aac9e4e8363666333adfdf21e89106 https://git.kernel.org/stable/c/a979e601000982a3ca693171a6d4dffc47f8ad00 https://git.kernel.org/stable/c/634f17ff1d59905eb3b4bbbc00805961d08beaee https://git.kernel.org/stable/c/4b380a7d84ef2ce3f4f5bec5d8706ed937ac6502 https://git.kernel.org/stable/c/0057ecef9f324007c0ba5fcca4ddd131178ce78b https://git.kernel.org/stable/c/279ad78a00f8b9c5ff24171a59297187a3bd44b7 https://git.kernel.org/stable/c/58ddf61f10b8f9b7b1341644bfee2f1c6 •

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

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix error handling of scsi_host_alloc() After device is initialized via device_initialize(), or its name is set via dev_set_name(), the device has to be freed via put_device(). Otherwise device name will be leaked because it is allocated dynamically in dev_set_name(). Fix the leak by replacing kfree() with put_device(). Since scsi_host_dev_release() properly handles IDA and kthread removal, remove special-casing these from the error handling as well. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: corrige el manejo de errores de scsi_host_alloc(). Después de que el dispositivo se inicializa mediante device_initialize(), o su nombre se establece mediante dev_set_name(), el dispositivo debe liberarse mediante put_device (). • https://git.kernel.org/stable/c/8958181c1663e24a13434448e7d6b96b5d04900a https://git.kernel.org/stable/c/db08ce595dd64ea9859f7d088b51cbfc8e685c66 https://git.kernel.org/stable/c/2dc85045ae65b9302a1d2e2ddd7ce4c030153a6a https://git.kernel.org/stable/c/79296e292d67fa7b5fb8d8c27343683e823872c8 https://git.kernel.org/stable/c/7a696ce1d5d16a33a6cd6400bbcc0339b2460e11 https://git.kernel.org/stable/c/45d83db4728127944b237c0c8248987df9d478e7 https://git.kernel.org/stable/c/66a834d092930cf41d809c0e989b13cd6f9ca006 •