Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vduse: Fix NULL pointer dereference on sysfs access<br /> <br /> The control device has no drvdata. So we will get a<br /> NULL pointer dereference when accessing control<br /> device&amp;#39;s msg_timeout attribute via sysfs:<br /> <br /> [ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8<br /> [ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271)<br /> [ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094)<br /> [ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59)<br /> [ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088)<br /> [ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164)<br /> [ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230)<br /> [ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041)<br /> [ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238)<br /> [ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1))<br /> [ 132.876319][ T3644] kernel_read (fs/read_write.c:459)<br /> [ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94)<br /> [ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186)<br /> [ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207)<br /> [ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189)<br /> [ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132)<br /> [ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419)<br /> <br /> To fix it, don&amp;#39;t create the unneeded attribute for<br /> control device anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix tcp_mtup_probe_success vs wrong snd_cwnd<br /> <br /> syzbot got a new report [1] finally pointing to a very old bug,<br /> added in initial support for MTU probing.<br /> <br /> tcp_mtu_probe() has checks about starting an MTU probe if<br /> tcp_snd_cwnd(tp) &gt;= 11.<br /> <br /> But nothing prevents tcp_snd_cwnd(tp) to be reduced later<br /> and before the MTU probe succeeds.<br /> <br /> This bug would lead to potential zero-divides.<br /> <br /> Debugging added in commit 40570375356c ("tcp: add accessors<br /> to read/set tp-&gt;snd_cwnd") has paid off :)<br /> <br /> While we are at it, address potential overflows in this code.<br /> <br /> [1]<br /> WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712<br /> Modules linked in:<br /> CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]<br /> RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712<br /> Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ff<br /> RSP: 0018:ffffc900079e70f8 EFLAGS: 00010287<br /> RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000<br /> RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9f<br /> RBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520<br /> R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50<br /> R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000<br /> FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356<br /> tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861<br /> tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973<br /> tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476<br /> sk_backlog_rcv include/net/sock.h:1061 [inline]<br /> __release_sock+0x1d8/0x4c0 net/core/sock.c:2849<br /> release_sock+0x5d/0x1c0 net/core/sock.c:3404<br /> sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145<br /> tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410<br /> tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> __sys_sendto+0x439/0x5c0 net/socket.c:2119<br /> __do_sys_sendto net/socket.c:2131 [inline]<br /> __se_sys_sendto net/socket.c:2127 [inline]<br /> __x64_sys_sendto+0xda/0xf0 net/socket.c:2127<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f6431289109<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109<br /> RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000a<br /> RBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling<br /> <br /> Error paths do not free previously allocated memory. Add devm_kfree() to<br /> those failure paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Address NULL pointer dereference after starget_to_rport()<br /> <br /> Calls to starget_to_rport() may return NULL. Add check for NULL rport<br /> before dereference.

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: Fix a possible resource leak in icom_probe<br /> <br /> When pci_read_config_dword failed, call pci_release_regions() and<br /> pci_disable_device() to recycle the resource previously allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop()<br /> <br /> There is a deadlock in rtllib_beacons_stop(), which is shown<br /> below:<br /> <br /> (Thread 1) | (Thread 2)<br /> | rtllib_send_beacon()<br /> rtllib_beacons_stop() | mod_timer()<br /> spin_lock_irqsave() //(1) | (wait a time)<br /> ... | rtllib_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<br /> use 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, rtllib_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 /> 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.