CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47172 – iio: adc: ad7124: Fix potential overflow due to non sequential channel numbers
https://notcve.org/view.php?id=CVE-2021-47172
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: Fix potential overflow due to non sequential channel numbers Channel numbering must start at 0 and then not have any holes, or it is possible to overflow the available storage. Note this bug was introduced as part of a fix to ensure we didn't rely on the ordering of child nodes. So we need to support arbitrary ordering but they all need to be there somewhere. Note I hit this when using qemu to test the rest of this series. Arguably this isn't the best fix, but it is probably the most minimal option for backporting etc. Alexandru's sign-off is here because he carried this patch in a larger set that Jonathan then applied. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: iio: adc: ad7124: Se corrige posible desbordamiento por números de canales no secuenciales. La numeración de canales debe comenzar en 0 y luego no tener huecos, o es posible que se desborde el almacenamiento disponible. • https://git.kernel.org/stable/c/5408cbc6337300d6f1a87c797273c535ed96305a https://git.kernel.org/stable/c/d7857e4ee1ba69732b16c73b2f2dde83ecd78ee4 https://git.kernel.org/stable/c/f49149964d2423fb618fb6b755bb1eaa431cca2c https://git.kernel.org/stable/c/f70122825076117787b91e7f219e21c09f11a5b9 https://git.kernel.org/stable/c/26da8040eccc6c6b0e415e9a3baf72fd39eb2fdc https://git.kernel.org/stable/c/f2a772c51206b0c3f262e4f6a3812c89a650191b • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47171 – net: usb: fix memory leak in smsc75xx_bind
https://notcve.org/view.php?id=CVE-2021-47171
In the Linux kernel, the following vulnerability has been resolved: net: usb: fix memory leak in smsc75xx_bind Syzbot reported memory leak in smsc75xx_bind(). The problem was is non-freed memory in case of errors after memory allocation. backtrace: [<ffffffff84245b62>] kmalloc include/linux/slab.h:556 [inline] [<ffffffff84245b62>] kzalloc include/linux/slab.h:686 [inline] [<ffffffff84245b62>] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460 [<ffffffff82b5b2e6>] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: usb: corrige la pérdida de memoria en smsc75xx_bind Syzbot informó una pérdida de memoria en smsc75xx_bind(). El problema era que la memoria no se liberaba en caso de errores después de la asignación de memoria. backtrace: [] kmalloc include/linux/slab.h:556 [en línea] [] kzalloc include/linux/slab.h:686 [en línea] [] smsc75xx_bind+0x7a/0x334 controladores/ net/usb/smsc75xx.c:1460 [] usbnet_probe+0x3b6/0xc30 controladores/net/usb/usbnet.c:1728 • https://git.kernel.org/stable/c/d0cad871703b898a442e4049c532ec39168e5b57 https://git.kernel.org/stable/c/200dbfcad8011e50c3cec269ed7b980836eeb1fa https://git.kernel.org/stable/c/22c840596af0c09068b6cf948616e6496e59e07f https://git.kernel.org/stable/c/9e6b8c1ff9d997e1fa16cbd2d60739adf6dc1bbc https://git.kernel.org/stable/c/9e6a3eccb28779710cbbafc4f4258d92509c6d07 https://git.kernel.org/stable/c/b95fb96e6339e34694dd578fb6bde3575b01af17 https://git.kernel.org/stable/c/635ac38b36255d3cfb8312cf7c471334f4d537e0 https://git.kernel.org/stable/c/70c886ac93f87ae7214a0c69151a28a80 • CWE-401: Missing Release of Memory after Effective Lifetime CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-47170 – USB: usbfs: Don't WARN about excessively large memory allocations
https://notcve.org/view.php?id=CVE-2021-47170
In the Linux kernel, the following vulnerability has been resolved: USB: usbfs: Don't WARN about excessively large memory allocations Syzbot found that the kernel generates a WARNing if the user tries to submit a bulk transfer through usbfs with a buffer that is way too large. This isn't a bug in the kernel; it's merely an invalid request from the user and the usbfs code does handle it correctly. In theory the same thing can happen with async transfers, or with the packet descriptor table for isochronous transfers. To prevent the MM subsystem from complaining about these bad allocation requests, add the __GFP_NOWARN flag to the kmalloc calls for these buffers. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: USB: usbfs: No ADVERTIR sobre asignaciones de memoria excesivamente grandes. Syzbot descubrió que el kernel genera una ADVERTENCIA si el usuario intenta enviar una transferencia masiva a través de usbfs con un búfer demasiado grande. Esto no es un error en el kernel; es simplemente una solicitud no válida del usuario y el código usbfs la maneja correctamente. • https://git.kernel.org/stable/c/2ab21d6e1411999b5fb43434f421f00bf50002eb https://git.kernel.org/stable/c/2c835fede13e03f2743a333e4370b5ed2db91e83 https://git.kernel.org/stable/c/8d83f109e920d2776991fa142bb904d985dca2ed https://git.kernel.org/stable/c/9f7cb3f01a10d9064cf13b3d26fb7e7a5827d098 https://git.kernel.org/stable/c/4f2629ea67e7225c3fd292c7fe4f5b3c9d6392de •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47169 – serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait'
https://notcve.org/view.php?id=CVE-2021-47169
In the Linux kernel, the following vulnerability has been resolved: serial: rp2: use 'request_firmware' instead of 'request_firmware_nowait' In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls 'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the firmware don't exists, function just return without initializing ports of 'rp2_card'. But now the interrupt handler function has been registered, and when an interrupt comes, 'rp2_uart_interrupt' may access those ports then causing NULL pointer dereference or other bugs. Because the driver does some initialization work in 'rp2_fw_cb', in order to make the driver ready to handle interrupts, 'request_firmware' should be used instead of asynchronous 'request_firmware_nowait'. This report reveals it: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 assign_lock_key kernel/locking/lockdep.c:727 [inline] register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753 __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303 lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline] _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144 spin_lock include/linux/spinlock.h:329 [inline] rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline] rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493 rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504 __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670 </IRQ> RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200 RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840 R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002 R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360 arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548 default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline] do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369 start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline] RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline] RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c: 493 Co ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: rp2: use 'request_firmware' en lugar de 'request_firmware_nowait' En 'rp2_probe', el controlador registra 'rp2_uart_interrupt' y luego llama a 'rp2_fw_cb' a través de 'request_firmware_nowait'. En 'rp2_fw_cb', si el firmware no existe, la función simplemente regresa sin inicializar los puertos de 'rp2_card'. Pero ahora la función de manejo de interrupciones ha sido registrada, y cuando llega una interrupción, 'rp2_uart_interrupt' puede acceder a esos puertos y causar desreferencia al puntero NULL u otros errores. • https://git.kernel.org/stable/c/1e04d5d5fe5e76af68f834e1941fcbfa439653be https://git.kernel.org/stable/c/c697244ce940ec07e2d745ccb63ca97fc0266fbc https://git.kernel.org/stable/c/1cc57cb32c84e059bd158494f746b665fc14d1b1 https://git.kernel.org/stable/c/35265552c7fe9553c75e324c80f45e28ff14eb6e https://git.kernel.org/stable/c/915452f40e2f495e187276c4407a4f567ec2307e https://git.kernel.org/stable/c/6a931ceb0b9401fe18d0c500e08164bf9cc7be4b https://git.kernel.org/stable/c/9b07b6973f7359e2dd6a9fe6db0c142634c823b7 https://git.kernel.org/stable/c/016002848c82eeb5d460489ce392d91fe •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47168 – NFS: fix an incorrect limit in filelayout_decode_layout()
https://notcve.org/view.php?id=CVE-2021-47168
In the Linux kernel, the following vulnerability has been resolved: NFS: fix an incorrect limit in filelayout_decode_layout() The "sizeof(struct nfs_fh)" is two bytes too large and could lead to memory corruption. It should be NFS_MAXFHSIZE because that's the size of the ->data[] buffer. I reversed the size of the arguments to put the variable on the left. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFS: corrige un límite incorrecto en filelayout_decode_layout() El "sizeof(struct nfs_fh)" es dos bytes demasiado grande y podría provocar daños en la memoria. Debería ser NFS_MAXFHSIZE porque ese es el tamaño del búfer ->datos[]. Invertí el tamaño de los argumentos para poner la variable a la izquierda. • https://git.kernel.org/stable/c/16b374ca439fb406e46e071f75428f5b033056f8 https://git.kernel.org/stable/c/9d280ab53df1d4a1043bd7a9e7c6a2f9cfbfe040 https://git.kernel.org/stable/c/b287521e9e94bb342ebe5fd8c3fd7db9aef4e6f1 https://git.kernel.org/stable/c/f299522eda1566cbfbae4b15c82970fc41b03714 https://git.kernel.org/stable/c/945ebef997227ca8c20bad7f8a8358c8ee57a84a https://git.kernel.org/stable/c/e411df81cd862ef3d5b878120b2a2fef0ca9cdb1 https://git.kernel.org/stable/c/9b367fe770b1b80d7bf64ed0d177544a44405f6e https://git.kernel.org/stable/c/d34fb628f6ef522f996205a9e578216bb •