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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47149 – net: fujitsu: fix potential null-ptr-deref
https://notcve.org/view.php?id=CVE-2021-47149
In the Linux kernel, the following vulnerability has been resolved: net: fujitsu: fix potential null-ptr-deref In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer deref. To fix this, check the return value of ioremap and return -1 to the caller in case of failure. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fujitsu: corrige el potencial null-ptr-deref En fmvj18x_get_hwinfo(), si ioremap falla, habrá un puntero NULL deref. Para solucionar este problema, verifique el valor de retorno de ioremap y devuelva -1 a la persona que llama en caso de falla. • https://git.kernel.org/stable/c/b92170e209f7746ed72eaac98f2c2f4b9af734e6 https://git.kernel.org/stable/c/6dbf1101594f7c76990b63c35b5a40205a914b6b https://git.kernel.org/stable/c/c4f1c23edbe921ab2ecd6140d700e756cd44c5f7 https://git.kernel.org/stable/c/7883d3895d0fbb0ba9bff0f8665f99974b45210f https://git.kernel.org/stable/c/22049c3d40f08facd1867548716a484dad6b3251 https://git.kernel.org/stable/c/71723a796ab7881f491d663c6cd94b29be5fba50 https://git.kernel.org/stable/c/f14bf57a08779a5dee9936f63ada0149ea89c5e6 https://git.kernel.org/stable/c/52202be1cd996cde6e8969a128dc27ee4 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47146 – mld: fix panic in mld_newpack()
https://notcve.org/view.php?id=CVE-2021-47146
In the Linux kernel, the following vulnerability has been resolved: mld: fix panic in mld_newpack() mld_newpack() doesn't allow to allocate high order page, only order-0 allocation is allowed. If headroom size is too large, a kernel panic could occur in skb_put(). Test commands: ip netns del A ip netns del B ip netns add A ip netns add B ip link add veth0 type veth peer name veth1 ip link set veth0 netns A ip link set veth1 netns B ip netns exec A ip link set lo up ip netns exec A ip link set veth0 up ip netns exec A ip -6 a a 2001:db8:0::1/64 dev veth0 ip netns exec B ip link set lo up ip netns exec B ip link set veth1 up ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1 for i in {1..99} do let A=$i-1 ip netns exec A ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100 ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i ip netns exec A ip link set ip6gre$i up ip netns exec B ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100 ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i ip netns exec B ip link set ip6gre$i up done Splat looks like: kernel BUG at net/core/skbuff.c:110! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.12.0+ #891 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:skb_panic+0x15d/0x15f Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83 41 57 41 56 41 55 48 8b 54 24 a6 26 f9 ff <0f> 0b 48 8b 6c 24 20 89 34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20 RSP: 0018:ffff88810091f820 EFLAGS: 00010282 RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000 RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb RBP: ffff888005f6eac0 R08: ffffed1022fc0031 R09: ffffed1022fc0031 R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028 R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0 FS: 0000000000000000(0000) GS:ffff888117c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 skb_put.cold.104+0x22/0x22 ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? rcu_read_lock_sched_held+0x91/0xc0 mld_newpack+0x398/0x8f0 ? • https://git.kernel.org/stable/c/72e09ad107e78d69ff4d3b97a69f0aad2b77280f https://git.kernel.org/stable/c/0e35b7457b7b6e73ffeaaca1a577fdf1af0feca1 https://git.kernel.org/stable/c/17728616a4c85baf0edc975c60ba4e4157684d9a https://git.kernel.org/stable/c/221142038f36d9f28b64e83e954774da4d4ccd17 https://git.kernel.org/stable/c/4b77ad9097067b31237eeeee0bf70f80849680a0 https://git.kernel.org/stable/c/37d697759958d111439080bab7e14d2b0e7b39f5 https://git.kernel.org/stable/c/beb39adb150f8f3b516ddf7c39835a9788704d23 https://git.kernel.org/stable/c/a76fb9ba545289379acf409653ad5f744 •