CVSS: 6.3EPSS: 0%CPEs: 7EXPL: 0CVE-2021-47267 – usb: fix various gadget panics on 10gbps cabling
https://notcve.org/view.php?id=CVE-2021-47267
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: 6EXPL: 0CVE-2021-47266 – RDMA/ipoib: Fix warning caused by destroying non-initial netns
https://notcve.org/view.php?id=CVE-2021-47266
In the Linux kernel, the following vulnerability has been resolved: RDMA/ipoib: Fix warning caused by destroying non-initial netns After the commit 5ce2dced8e95 ("RDMA/ipoib: Set rtnl_link_ops for ipoib interfaces"), if the IPoIB device is moved to non-initial netns, destroying that netns lets the device vanish instead of moving it back to the initial netns, This is happening because default_device_exit() skips the interfaces due to having rtnl_link_ops set. Steps to reporoduce: ip netns add foo ip link set mlx5_ib0 netns foo ip netns delete foo WARNING: CPU: 1 PID: 704 at net/core/dev.c:11435 netdev_exit+0x3f/0x50 Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun d fuse CPU: 1 PID: 704 Comm: kworker/u64:3 Tainted: G S W 5.13.0-rc1+ #1 Hardware name: Dell Inc. PowerEdge R630/02C2CP, BIOS 2.1.5 04/11/2016 Workqueue: netns cleanup_net RIP: 0010:netdev_exit+0x3f/0x50 Code: 48 8b bb 30 01 00 00 e8 ef 81 b1 ff 48 81 fb c0 3a 54 a1 74 13 48 8b 83 90 00 00 00 48 81 c3 90 00 00 00 48 39 d8 75 02 5b c3 <0f> 0b 5b c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00 RSP: 0018:ffffb297079d7e08 EFLAGS: 00010206 RAX: ffff8eb542c00040 RBX: ffff8eb541333150 RCX: 000000008010000d RDX: 000000008010000e RSI: 000000008010000d RDI: ffff8eb440042c00 RBP: ffffb297079d7e48 R08: 0000000000000001 R09: ffffffff9fdeac00 R10: ffff8eb5003be000 R11: 0000000000000001 R12: ffffffffa1545620 R13: ffffffffa1545628 R14: 0000000000000000 R15: ffffffffa1543b20 FS: 0000000000000000(0000) GS:ffff8ed37fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005601b5f4c2e8 CR3: 0000001fc8c10002 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ops_exit_list.isra.9+0x36/0x70 cleanup_net+0x234/0x390 process_one_work+0x1cb/0x360 ? process_one_work+0x360/0x360 worker_thread+0x30/0x370 ? process_one_work+0x360/0x360 kthread+0x116/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 To avoid the above warning and later on the kernel panic that could happen on shutdown due to a NULL pointer dereference, make sure to set the netns_refund flag that was introduced by commit 3a5ca857079e ("can: dev: Move device back to init netns on owning netns delete") to properly restore the IPoIB interfaces to the initial netns. • https://git.kernel.org/stable/c/dc1d4c658b9c123e31054fffcbc0b23566694b1a https://git.kernel.org/stable/c/5ce2dced8e95e76ff7439863a118a053a7fc6f91 https://git.kernel.org/stable/c/938e97b946ecf5aa3ccc04ff4ad116e92d894270 https://git.kernel.org/stable/c/86e76dbea6379bb272bceb36fe4217f34ff6858d https://git.kernel.org/stable/c/64f1fb6acc2ab95982fc4334f351d7576c26f313 https://git.kernel.org/stable/c/67cf4e447b5e5e9e94996cb6812ae2828e0e0e27 https://git.kernel.org/stable/c/0a672f7d89db2da17ae02733ccc08458be72a6f8 https://git.kernel.org/stable/c/a3e74fb9247cd530dca246699d5eb5a69 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47265 – RDMA: Verify port when creating flow rule
https://notcve.org/view.php?id=CVE-2021-47265
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: 3EXPL: 0CVE-2021-47264 – ASoC: core: Fix Null-point-dereference in fmt_single_name()
https://notcve.org/view.php?id=CVE-2021-47264
In the Linux kernel, the following vulnerability has been resolved: ASoC: core: Fix Null-point-dereference in fmt_single_name() Check the return value of devm_kstrdup() in case of Null-point-dereference. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: core: corrige la desreferencia de punto nulo en fmt_single_name(). Verifique el valor de retorno de devm_kstrdup() en caso de dereferencia de punto nulo. • https://git.kernel.org/stable/c/45dd9943fce08f1b38352ff9453682253bdf19b7 https://git.kernel.org/stable/c/0e2c9aeb00289f279b8181fbd4c20765127d8943 https://git.kernel.org/stable/c/047fd16015a79180771650aa6ce71f68b2c23368 https://git.kernel.org/stable/c/41daf6ba594d55f201c50280ebcd430590441da1 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47263 – gpio: wcd934x: Fix shift-out-of-bounds error
https://notcve.org/view.php?id=CVE-2021-47263
In the Linux kernel, the following vulnerability has been resolved: gpio: wcd934x: Fix shift-out-of-bounds error bit-mask for pins 0 to 4 is BIT(0) to BIT(4) however we ended up with BIT(n - 1) which is not right, and this was caught by below usban check UBSAN: shift-out-of-bounds in drivers/gpio/gpio-wcd934x.c:34:14 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: gpio: wcd934x: corrección de error de desplazamiento fuera de los límites. La máscara de bits para los pines 0 a 4 es BIT(0) a BIT(4); sin embargo, terminamos con BIT( n - 1) lo cual no es correcto, y esto fue detectado por la siguiente verificación USB UBSAN: shift-out-of-bounds in drivers/gpio/gpio-wcd934x.c:34:14 • https://git.kernel.org/stable/c/59c324683400b41caa6d85b091e812ee3d5415c3 https://git.kernel.org/stable/c/e0b518a2eb44d8a74c19e50f79a8ed393e96d634 https://git.kernel.org/stable/c/dd55331d493b7ea75c5db1f24d6822946fde2862 https://git.kernel.org/stable/c/dbec64b11c65d74f31427e2b9d5746fbf17bf840 •