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 /> net: dsa: mt7530: fix VLAN traffic leaks<br /> <br /> PCR_MATRIX field was set to all 1&amp;#39;s when VLAN filtering is enabled, but<br /> was not reset when it is disabled, which may cause traffic leaks:<br /> <br /> ip link add br0 type bridge vlan_filtering 1<br /> ip link add br1 type bridge vlan_filtering 1<br /> ip link set swp0 master br0<br /> ip link set swp1 master br1<br /> ip link set br0 type bridge vlan_filtering 0<br /> ip link set br1 type bridge vlan_filtering 0<br /> # traffic in br0 and br1 will start leaking to each other<br /> <br /> As port_bridge_{add,del} have set up PCR_MATRIX properly, remove the<br /> PCR_MATRIX write from mt7530_port_set_vlan_aware.

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 /> tipc: skb_linearize the head skb when reassembling msgs<br /> <br /> It&amp;#39;s not a good idea to append the frag skb to a skb&amp;#39;s frag_list if<br /> the frag_list already has skbs from elsewhere, such as this skb was<br /> created by pskb_copy() where the frag_list was cloned (all the skbs<br /> in it were skb_get&amp;#39;ed) and shared by multiple skbs.<br /> <br /> However, the new appended frag skb should have been only seen by the<br /> current skb. Otherwise, it will cause use after free crashes as this<br /> appended frag skb are seen by multiple skbs but it only got skb_get<br /> called once.<br /> <br /> The same thing happens with a skb updated by pskb_may_pull() with a<br /> skb_cloned skb. Li Shuang has reported quite a few crashes caused<br /> by this when doing testing over macvlan devices:<br /> <br /> [] kernel BUG at net/core/skbuff.c:1970!<br /> [] Call Trace:<br /> [] skb_clone+0x4d/0xb0<br /> [] macvlan_broadcast+0xd8/0x160 [macvlan]<br /> [] macvlan_process_broadcast+0x148/0x150 [macvlan]<br /> [] process_one_work+0x1a7/0x360<br /> [] worker_thread+0x30/0x390<br /> <br /> [] kernel BUG at mm/usercopy.c:102!<br /> [] Call Trace:<br /> [] __check_heap_object+0xd3/0x100<br /> [] __check_object_size+0xff/0x16b<br /> [] simple_copy_to_iter+0x1c/0x30<br /> [] __skb_datagram_iter+0x7d/0x310<br /> [] __skb_datagram_iter+0x2a5/0x310<br /> [] skb_copy_datagram_iter+0x3b/0x90<br /> [] tipc_recvmsg+0x14a/0x3a0 [tipc]<br /> [] ____sys_recvmsg+0x91/0x150<br /> [] ___sys_recvmsg+0x7b/0xc0<br /> <br /> [] kernel BUG at mm/slub.c:305!<br /> [] Call Trace:<br /> [] <br /> [] kmem_cache_free+0x3ff/0x400<br /> [] __netif_receive_skb_core+0x12c/0xc40<br /> [] ? kmem_cache_alloc+0x12e/0x270<br /> [] netif_receive_skb_internal+0x3d/0xb0<br /> [] ? get_rx_page_info+0x8e/0xa0 [be2net]<br /> [] be_poll+0x6ef/0xd00 [be2net]<br /> [] ? irq_exit+0x4f/0x100<br /> [] net_rx_action+0x149/0x3b0<br /> <br /> ...<br /> <br /> This patch is to fix it by linearizing the head skb if it has frag_list<br /> set in tipc_buf_append(). Note that we choose to do this before calling<br /> skb_unshare(), as __skb_linearize() will avoid skb_copy(). Also, we can<br /> not just drop the frag_list either as the early time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: wait and exit until all work queues are done<br /> <br /> On some host, a crash could be triggered simply by repeating these<br /> commands several times:<br /> <br /> # modprobe tipc<br /> # tipc bearer enable media udp name UDP1 localip 127.0.0.1<br /> # rmmod tipc<br /> <br /> [] BUG: unable to handle kernel paging request at ffffffffc096bb00<br /> [] Workqueue: events 0xffffffffc096bb00<br /> [] Call Trace:<br /> [] ? process_one_work+0x1a7/0x360<br /> [] ? worker_thread+0x30/0x390<br /> [] ? create_worker+0x1a0/0x1a0<br /> [] ? kthread+0x116/0x130<br /> [] ? kthread_flush_work_fn+0x10/0x10<br /> [] ? ret_from_fork+0x35/0x40<br /> <br /> When removing the TIPC module, the UDP tunnel sock will be delayed to<br /> release in a work queue as sock_release() can&amp;#39;t be done in rtnl_lock().<br /> If the work queue is schedule to run after the TIPC module is removed,<br /> kernel will crash as the work queue function cleanup_beareri() code no<br /> longer exists when trying to invoke it.<br /> <br /> To fix it, this patch introduce a member wq_count in tipc_net to track<br /> the numbers of work queues in schedule, and wait and exit until all<br /> work queues are done in tipc_exit_net().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix null deref accessing lag dev<br /> <br /> It could be the lag dev is null so stop processing the event.<br /> In bond_enslave() the active/backup slave being set before setting the<br /> upper dev so first event is without an upper dev.<br /> After setting the upper dev with bond_master_upper_dev_link() there is<br /> a second event and in that event we have an upper dev.

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 /> 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 /> 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: 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 /> 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 /> 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.