Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: fix a crash if -&gt;get_sset_count() fails<br /> <br /> If ds-&gt;ops-&gt;get_sset_count() fails then it "count" is a negative error<br /> code such as -EOPNOTSUPP. Because "i" is an unsigned int, the negative<br /> error code is type promoted to a very high value and the loop will<br /> corrupt memory until the system crashes.<br /> <br /> Fix this by checking for error codes and changing the type of "i" to<br /> just int.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: usbfs: Don&amp;#39;t WARN about excessively large memory allocations<br /> <br /> Syzbot found that the kernel generates a WARNing if the user tries to<br /> submit a bulk transfer through usbfs with a buffer that is way too<br /> large. This isn&amp;#39;t a bug in the kernel; it&amp;#39;s merely an invalid request<br /> from the user and the usbfs code does handle it correctly.<br /> <br /> In theory the same thing can happen with async transfers, or with the<br /> packet descriptor table for isochronous transfers.<br /> <br /> To prevent the MM subsystem from complaining about these bad<br /> allocation requests, add the __GFP_NOWARN flag to the kmalloc calls<br /> for these buffers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: fix an incorrect limit in filelayout_decode_layout()<br /> <br /> The "sizeof(struct nfs_fh)" is two bytes too large and could lead to<br /> memory corruption. It should be NFS_MAXFHSIZE because that&amp;#39;s the size<br /> of the -&gt;data[] buffer.<br /> <br /> I reversed the size of the arguments to put the variable on the left.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix an Oopsable condition in __nfs_pageio_add_request()<br /> <br /> Ensure that nfs_pageio_error_cleanup() resets the mirror array contents,<br /> so that the structure reflects the fact that it is now empty.<br /> Also change the test in nfs_pageio_do_add_request() to be more robust by<br /> checking whether or not the list is empty rather than relying on the<br /> value of pg_count.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Don&amp;#39;t corrupt the value of pg_bytes_written in nfs_do_recoalesce()<br /> <br /> The value of mirror-&gt;pg_bytes_written should only be updated after a<br /> successful attempt to flush out the requests on the list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-fsl-dspi: Fix a resource leak in an error handling path<br /> <br /> &amp;#39;dspi_request_dma()&amp;#39; should be undone by a &amp;#39;dspi_release_dma()&amp;#39; call in the<br /> error handling path of the probe function, as already done in the remove<br /> function

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/meson: fix shutdown crash when component not probed<br /> <br /> When main component is not probed, by example when the dw-hdmi module is<br /> not loaded yet or in probe defer, the following crash appears on shutdown:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038<br /> ...<br /> pc : meson_drv_shutdown+0x24/0x50<br /> lr : platform_drv_shutdown+0x20/0x30<br /> ...<br /> Call trace:<br /> meson_drv_shutdown+0x24/0x50<br /> platform_drv_shutdown+0x20/0x30<br /> device_shutdown+0x158/0x360<br /> kernel_restart_prepare+0x38/0x48<br /> kernel_restart+0x18/0x68<br /> __do_sys_reboot+0x224/0x250<br /> __arm64_sys_reboot+0x24/0x30<br /> ...<br /> <br /> Simply check if the priv struct has been allocated before using it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: rp2: use &amp;#39;request_firmware&amp;#39; instead of &amp;#39;request_firmware_nowait&amp;#39;<br /> <br /> In &amp;#39;rp2_probe&amp;#39;, the driver registers &amp;#39;rp2_uart_interrupt&amp;#39; then calls<br /> &amp;#39;rp2_fw_cb&amp;#39; through &amp;#39;request_firmware_nowait&amp;#39;. In &amp;#39;rp2_fw_cb&amp;#39;, if the<br /> firmware don&amp;#39;t exists, function just return without initializing ports<br /> of &amp;#39;rp2_card&amp;#39;. But now the interrupt handler function has been<br /> registered, and when an interrupt comes, &amp;#39;rp2_uart_interrupt&amp;#39; may access<br /> those ports then causing NULL pointer dereference or other bugs.<br /> <br /> Because the driver does some initialization work in &amp;#39;rp2_fw_cb&amp;#39;, in<br /> order to make the driver ready to handle interrupts, &amp;#39;request_firmware&amp;#39;<br /> should be used instead of asynchronous &amp;#39;request_firmware_nowait&amp;#39;.<br /> <br /> This report reveals it:<br /> <br /> INFO: trying to register non-static key.<br /> the code is fine but needs lockdep annotation.<br /> turning off the locking correctness validator.<br /> CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-<br /> gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0xec/0x156 lib/dump_stack.c:118<br /> assign_lock_key kernel/locking/lockdep.c:727 [inline]<br /> register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753<br /> __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303<br /> lock_acquire+0x124/0x340 kernel/locking/lockdep.c:3907<br /> __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]<br /> _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144<br /> spin_lock include/linux/spinlock.h:329 [inline]<br /> rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline]<br /> rp2_asic_interrupt.isra.9+0x15d/0x990 drivers/tty/serial/rp2.c:493<br /> rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504<br /> __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149<br /> handle_irq_event_percpu+0x79/0x150 kernel/irq/handle.c:189<br /> handle_irq_event+0xac/0x140 kernel/irq/handle.c:206<br /> handle_fasteoi_irq+0x232/0x5c0 kernel/irq/chip.c:725<br /> generic_handle_irq_desc include/linux/irqdesc.h:155 [inline]<br /> handle_irq+0x230/0x3a0 arch/x86/kernel/irq_64.c:87<br /> do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247<br /> common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:670<br /> <br /> RIP: 0010:native_safe_halt+0x28/0x30 arch/x86/include/asm/irqflags.h:61<br /> Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7 f8<br /> 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 c3 90 90 90<br /> 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41<br /> RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde<br /> RAX: 0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285<br /> RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff8c2fc200<br /> RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840<br /> R10: 0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002<br /> R13: ffffffff8bea18a0 R14: 0000000000000000 R15: 0000000000000000<br /> arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]<br /> default_idle+0x6f/0x360 arch/x86/kernel/process.c:557<br /> arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548<br /> default_idle_call+0x3b/0x60 kernel/sched/idle.c:93<br /> cpuidle_idle_call kernel/sched/idle.c:153 [inline]<br /> do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263<br /> cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369<br /> start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271<br /> secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243<br /> BUG: unable to handle kernel NULL pointer dereference at 0000000000000010<br /> PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-<br /> gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:readl arch/x86/include/asm/io.h:59 [inline]<br /> RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline]<br /> RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c:<br /> 493<br /> Co<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad7124: Fix potential overflow due to non sequential channel numbers<br /> <br /> Channel numbering must start at 0 and then not have any holes, or<br /> it is possible to overflow the available storage. Note this bug was<br /> introduced as part of a fix to ensure we didn&amp;#39;t rely on the ordering<br /> of child nodes. So we need to support arbitrary ordering but they all<br /> need to be there somewhere.<br /> <br /> Note I hit this when using qemu to test the rest of this series.<br /> Arguably this isn&amp;#39;t the best fix, but it is probably the most minimal<br /> option for backporting etc.<br /> <br /> Alexandru&amp;#39;s sign-off is here because he carried this patch in a larger<br /> set that Jonathan then applied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: sja1105: add error handling in sja1105_setup()<br /> <br /> If any of sja1105_static_config_load(), sja1105_clocking_setup() or<br /> sja1105_devlink_setup() fails, we can&amp;#39;t just return in the middle of<br /> sja1105_setup() or memory will leak. Add a cleanup path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: ocp: Fix a resource leak in an error handling path<br /> <br /> If an error occurs after a successful &amp;#39;pci_ioremap_bar()&amp;#39; call, it must be<br /> undone by a corresponding &amp;#39;pci_iounmap()&amp;#39; call, as already done in the<br /> remove function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: i801: Don&amp;#39;t generate an interrupt on bus reset<br /> <br /> Now that the i2c-i801 driver supports interrupts, setting the KILL bit<br /> in a attempt to recover from a timed out transaction triggers an<br /> interrupt. Unfortunately, the interrupt handler (i801_isr) is not<br /> prepared for this situation and will try to process the interrupt as<br /> if it was signaling the end of a successful transaction. In the case<br /> of a block transaction, this can result in an out-of-range memory<br /> access.<br /> <br /> This condition was reproduced several times by syzbot:<br /> https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e<br /> https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e<br /> https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e<br /> https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb<br /> https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a<br /> https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79<br /> <br /> So disable interrupts while trying to reset the bus. Interrupts will<br /> be enabled again for the following transaction.