Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: Don&amp;#39;t hold the layoutget locks across multiple RPC calls<br /> <br /> When doing layoutget as part of the open() compound, we have to be<br /> careful to release the layout locks before we can call any further RPC<br /> calls, such as setattr(). The reason is that those calls could trigger<br /> a recall, which could deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: avoid infinite loop to flush node pages<br /> <br /> xfstests/generic/475 can give EIO all the time which give an infinite loop<br /> to flush node page like below. Let&amp;#39;s avoid it.<br /> <br /> [16418.518551] Call Trace:<br /> [16418.518553] ? dm_submit_bio+0x48/0x400<br /> [16418.518574] ? submit_bio_checks+0x1ac/0x5a0<br /> [16418.525207] __submit_bio+0x1a9/0x230<br /> [16418.525210] ? kmem_cache_alloc+0x29e/0x3c0<br /> [16418.525223] submit_bio_noacct+0xa8/0x2b0<br /> [16418.525226] submit_bio+0x4d/0x130<br /> [16418.525238] __submit_bio+0x49/0x310 [f2fs]<br /> [16418.525339] ? bio_add_page+0x6a/0x90<br /> [16418.525344] f2fs_submit_page_bio+0x134/0x1f0 [f2fs]<br /> [16418.525365] read_node_page+0x125/0x1b0 [f2fs]<br /> [16418.525388] __get_node_page.part.0+0x58/0x3f0 [f2fs]<br /> [16418.525409] __get_node_page+0x2f/0x60 [f2fs]<br /> [16418.525431] f2fs_get_dnode_of_data+0x423/0x860 [f2fs]<br /> [16418.525452] ? asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> [16418.525458] ? __mod_memcg_state.part.0+0x2a/0x30<br /> [16418.525465] ? __mod_memcg_lruvec_state+0x27/0x40<br /> [16418.525467] ? __xa_set_mark+0x57/0x70<br /> [16418.525472] f2fs_do_write_data_page+0x10e/0x7b0 [f2fs]<br /> [16418.525493] f2fs_write_single_data_page+0x555/0x830 [f2fs]<br /> [16418.525514] ? sysvec_apic_timer_interrupt+0x4e/0x90<br /> [16418.525518] ? asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> [16418.525523] f2fs_write_cache_pages+0x303/0x880 [f2fs]<br /> [16418.525545] ? blk_flush_plug_list+0x47/0x100<br /> [16418.525548] f2fs_write_data_pages+0xfd/0x320 [f2fs]<br /> [16418.525569] do_writepages+0xd5/0x210<br /> [16418.525648] filemap_fdatawrite_wbc+0x7d/0xc0<br /> [16418.525655] filemap_fdatawrite+0x50/0x70<br /> [16418.525658] f2fs_sync_dirty_inodes+0xa4/0x230 [f2fs]<br /> [16418.525679] f2fs_write_checkpoint+0x16d/0x1720 [f2fs]<br /> [16418.525699] ? ttwu_do_wakeup+0x1c/0x160<br /> [16418.525709] ? ttwu_do_activate+0x6d/0xd0<br /> [16418.525711] ? __wait_for_common+0x11d/0x150<br /> [16418.525715] kill_f2fs_super+0xca/0x100 [f2fs]<br /> [16418.525733] deactivate_locked_super+0x3b/0xb0<br /> [16418.525739] deactivate_super+0x40/0x50<br /> [16418.525741] cleanup_mnt+0x139/0x190<br /> [16418.525747] __cleanup_mnt+0x12/0x20<br /> [16418.525749] task_work_run+0x6d/0xa0<br /> [16418.525765] exit_to_user_mode_prepare+0x1ad/0x1b0<br /> [16418.525771] syscall_exit_to_user_mode+0x27/0x50<br /> [16418.525774] do_syscall_64+0x48/0xc0<br /> [16418.525776] entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: remove WARN_ON in f2fs_is_valid_blkaddr<br /> <br /> Syzbot triggers two WARNs in f2fs_is_valid_blkaddr and<br /> __is_bitmap_valid. For example, in f2fs_is_valid_blkaddr,<br /> if type is DATA_GENERIC_ENHANCE or DATA_GENERIC_ENHANCE_READ,<br /> it invokes WARN_ON if blkaddr is not in the right range.<br /> The call trace is as follows:<br /> <br /> f2fs_get_node_info+0x45f/0x1070<br /> read_node_page+0x577/0x1190<br /> __get_node_page.part.0+0x9e/0x10e0<br /> __get_node_page<br /> f2fs_get_node_page+0x109/0x180<br /> do_read_inode<br /> f2fs_iget+0x2a5/0x58b0<br /> f2fs_fill_super+0x3b39/0x7ca0<br /> <br /> Fix these two WARNs by replacing WARN_ON with dump_stack.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu-v3: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref if platform_get_resource() returns NULL,<br /> we need check the return value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: zynqmp_dma: In struct zynqmp_dma_chan fix desc_size data type<br /> <br /> In zynqmp_dma_alloc/free_chan_resources functions there is a<br /> potential overflow in the below expressions.<br /> <br /> dma_alloc_coherent(chan-&gt;dev, (2 * chan-&gt;desc_size *<br /> ZYNQMP_DMA_NUM_DESCS),<br /> &amp;chan-&gt;desc_pool_p, GFP_KERNEL);<br /> <br /> dma_free_coherent(chan-&gt;dev,(2 * ZYNQMP_DMA_DESC_SIZE(chan) *<br /> ZYNQMP_DMA_NUM_DESCS),<br /> chan-&gt;desc_pool_v, chan-&gt;desc_pool_p);<br /> <br /> The arguments desc_size and ZYNQMP_DMA_NUM_DESCS were 32 bit. Though<br /> this overflow condition is not observed but it is a potential problem<br /> in the case of 32-bit multiplication. Hence fix it by changing the<br /> desc_size data type to size_t.<br /> <br /> In addition to coverity fix it also reuse ZYNQMP_DMA_DESC_SIZE macro in<br /> dma_alloc_coherent API argument.<br /> <br /> Addresses-Coverity: Event overflow_before_widen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xprtrdma: treat all calls not a bcall when bc_serv is NULL<br /> <br /> When a rdma server returns a fault format reply, nfs v3 client may<br /> treats it as a bcall when bc service is not exist.<br /> <br /> The debug message at rpcrdma_bc_receive_call are,<br /> <br /> [56579.837169] RPC: rpcrdma_bc_receive_call: callback XID<br /> 00000001, length=20<br /> [56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00<br /> 00 00 00 00 00 00 00 00 00 00 00 00 04<br /> <br /> After that, rpcrdma_bc_receive_call will meets NULL pointer as,<br /> <br /> [ 226.057890] BUG: unable to handle kernel NULL pointer dereference at<br /> 00000000000000c8<br /> ...<br /> [ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20<br /> ...<br /> [ 226.059732] Call Trace:<br /> [ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma]<br /> [ 226.060011] __ib_process_cq+0x89/0x170 [ib_core]<br /> [ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core]<br /> [ 226.060257] process_one_work+0x1a7/0x360<br /> [ 226.060367] ? create_worker+0x1a0/0x1a0<br /> [ 226.060440] worker_thread+0x30/0x390<br /> [ 226.060500] ? create_worker+0x1a0/0x1a0<br /> [ 226.060574] kthread+0x116/0x130<br /> [ 226.060661] ? kthread_flush_work_fn+0x10/0x10<br /> [ 226.060724] ret_from_fork+0x35/0x40<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: host: isp116x: check return value after calling platform_get_resource()<br /> <br /> It will cause null-ptr-deref if platform_get_resource() returns NULL,<br /> we need check the return value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: staging: rtl8192eu: Fix deadlock in rtw_joinbss_event_prehandle<br /> <br /> There is a deadlock in rtw_joinbss_event_prehandle(), which is shown below:<br /> <br /> (Thread 1) | (Thread 2)<br /> | _set_timer()<br /> rtw_joinbss_event_prehandle()| mod_timer()<br /> spin_lock_bh() //(1) | (wait a time)<br /> ... | rtw_join_timeout_handler()<br /> | _rtw_join_timeout_handler()<br /> del_timer_sync() | spin_lock_bh() //(2)<br /> (wait timer to stop) | ...<br /> <br /> We hold pmlmepriv-&gt;lock in position (1) of thread 1 and<br /> use del_timer_sync() to wait timer to stop, but timer handler<br /> also need pmlmepriv-&gt;lock in position (2) of thread 2.<br /> As a result, rtw_joinbss_event_prehandle() will block forever.<br /> <br /> This patch extracts del_timer_sync() from the protection of<br /> spin_lock_bh(), which could let timer handler to obtain<br /> the needed lock. What`s more, we change spin_lock_bh() to<br /> spin_lock_irq() in _rtw_join_timeout_handler() in order to<br /> prevent deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: tty: serial: Fix deadlock in sa1100_set_termios()<br /> <br /> There is a deadlock in sa1100_set_termios(), which is shown<br /> below:<br /> <br /> (Thread 1) | (Thread 2)<br /> | sa1100_enable_ms()<br /> sa1100_set_termios() | mod_timer()<br /> spin_lock_irqsave() //(1) | (wait a time)<br /> ... | sa1100_timeout()<br /> del_timer_sync() | spin_lock_irqsave() //(2)<br /> (wait timer to stop) | ...<br /> <br /> We hold sport-&gt;port.lock in position (1) of thread 1 and<br /> use del_timer_sync() to wait timer to stop, but timer handler<br /> also need sport-&gt;port.lock in position (2) of thread 2. As a result,<br /> sa1100_set_termios() will block forever.<br /> <br /> This patch moves del_timer_sync() before spin_lock_irqsave()<br /> in order to prevent the deadlock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop()<br /> <br /> There is a deadlock in ieee80211_beacons_stop(), which is shown below:<br /> <br /> (Thread 1) | (Thread 2)<br /> | ieee80211_send_beacon()<br /> ieee80211_beacons_stop() | mod_timer()<br /> spin_lock_irqsave() //(1) | (wait a time)<br /> ... | ieee80211_send_beacon_cb()<br /> del_timer_sync() | spin_lock_irqsave() //(2)<br /> (wait timer to stop) | ...<br /> <br /> We hold ieee-&gt;beacon_lock in position (1) of thread 1 and use<br /> del_timer_sync() to wait timer to stop, but timer handler<br /> also need ieee-&gt;beacon_lock in position (2) of thread 2.<br /> As a result, ieee80211_beacons_stop() will block forever.<br /> <br /> This patch extracts del_timer_sync() from the protection of<br /> spin_lock_irqsave(), which could let timer handler to obtain<br /> the needed lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: host: Stop setting the ACPI companion<br /> <br /> It is no longer needed. The sysdev pointer is now used when<br /> assigning the ACPI companions to the xHCI ports and USB<br /> devices.<br /> <br /> Assigning the ACPI companion here resulted in the<br /> fwnode-&gt;secondary pointer to be replaced also for the parent<br /> dwc3 device since the primary fwnode (the ACPI companion)<br /> was shared. That was unintentional and it created potential<br /> side effects like resource leaks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: synclink_gt: Fix null-pointer-dereference in slgt_clean()<br /> <br /> When the driver fails at alloc_hdlcdev(), and then we remove the driver<br /> module, we will get the following splat:<br /> <br /> [ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI<br /> [ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17]<br /> [ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0<br /> [ 25.077709] Call Trace:<br /> [ 25.077924] <br /> [ 25.078108] unregister_hdlc_device+0x16/0x30<br /> [ 25.078481] slgt_cleanup+0x157/0x9f0 [synclink_gt]<br /> <br /> Fix this by checking whether the &amp;#39;info-&gt;netdev&amp;#39; is a null pointer first.