Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: fix a potential ttm-&gt;sg memory leak<br /> <br /> Memory is allocated for ttm-&gt;sg by kmalloc in kfd_mem_dmamap_userptr,<br /> but isn&amp;#39;t freed by kfree in kfd_mem_dmaunmap_userptr. Free it!

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/kms/nv50-: fix file release memory leak<br /> <br /> When using single_open() for opening, single_release() should be<br /> called, otherwise the &amp;#39;op&amp;#39; allocated in single_open() will be leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/debugfs: fix file release memory leak<br /> <br /> When using single_open() for opening, single_release() should be<br /> called, otherwise the &amp;#39;op&amp;#39; allocated in single_open() will be leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix freeing of uninitialized misc IRQ vector<br /> <br /> When VSI set up failed in i40e_probe() as part of PF switch set up<br /> driver was trying to free misc IRQ vectors in<br /> i40e_clear_interrupt_scheme and produced a kernel Oops:<br /> <br /> Trying to free already-free IRQ 266<br /> WARNING: CPU: 0 PID: 5 at kernel/irq/manage.c:1731 __free_irq+0x9a/0x300<br /> Workqueue: events work_for_cpu_fn<br /> RIP: 0010:__free_irq+0x9a/0x300<br /> Call Trace:<br /> ? synchronize_irq+0x3a/0xa0<br /> free_irq+0x2e/0x60<br /> i40e_clear_interrupt_scheme+0x53/0x190 [i40e]<br /> i40e_probe.part.108+0x134b/0x1a40 [i40e]<br /> ? kmem_cache_alloc+0x158/0x1c0<br /> ? acpi_ut_update_ref_count.part.1+0x8e/0x345<br /> ? acpi_ut_update_object_reference+0x15e/0x1e2<br /> ? strstr+0x21/0x70<br /> ? irq_get_irq_data+0xa/0x20<br /> ? mp_check_pin_attr+0x13/0xc0<br /> ? irq_get_irq_data+0xa/0x20<br /> ? mp_map_pin_to_irq+0xd3/0x2f0<br /> ? acpi_register_gsi_ioapic+0x93/0x170<br /> ? pci_conf1_read+0xa4/0x100<br /> ? pci_bus_read_config_word+0x49/0x70<br /> ? do_pci_enable_device+0xcc/0x100<br /> local_pci_probe+0x41/0x90<br /> work_for_cpu_fn+0x16/0x20<br /> process_one_work+0x1a7/0x360<br /> worker_thread+0x1cf/0x390<br /> ? create_worker+0x1a0/0x1a0<br /> kthread+0x112/0x130<br /> ? kthread_flush_work_fn+0x10/0x10<br /> ret_from_fork+0x1f/0x40<br /> <br /> The problem is that at that point misc IRQ vectors<br /> were not allocated yet and we get a call trace<br /> that driver is trying to free already free IRQ vectors.<br /> <br /> Add a check in i40e_clear_interrupt_scheme for __I40E_MISC_IRQ_REQUESTED<br /> PF state before calling i40e_free_misc_vector. This state is set only if<br /> misc IRQ vectors were properly initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: acpi: fix resource leak in reconfiguration device addition<br /> <br /> acpi_i2c_find_adapter_by_handle() calls bus_find_device() which takes a<br /> reference on the adapter which is never released which will result in a<br /> reference count leak and render the adapter unremovable. Make sure to<br /> put the adapter after creating the client in the same manner that we do<br /> for OF.<br /> <br /> [wsa: fixed title]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume<br /> <br /> In current code, when a PCI error state pci_channel_io_normal is detectd,<br /> it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI<br /> driver will continue the execution of PCI resume callback report_resume by<br /> pci_walk_bridge, and the callback will go into amdgpu_pci_resume<br /> finally, where write lock is releasd unconditionally without acquiring<br /> such lock first. In this case, a deadlock will happen when other threads<br /> start to acquire the read lock.<br /> <br /> To fix this, add a member in amdgpu_device strucutre to cache<br /> pci_channel_state, and only continue the execution in amdgpu_pci_resume<br /> when it&amp;#39;s pci_channel_io_frozen.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: usbhid: free raw_report buffers in usbhid_stop<br /> <br /> Free the unsent raw_report buffers when the device is removed.<br /> <br /> Fixes a memory leak reported by syzbot at:<br /> https://syzkaller.appspot.com/bug?id=7b4fa7cb1a7c2d3342a2a8a6c53371c8c418ab47

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: add error checking to ext4_ext_replay_set_iblocks()<br /> <br /> If the call to ext4_map_blocks() fails due to an corrupted file<br /> system, ext4_ext_replay_set_iblocks() can get stuck in an infinite<br /> loop. This could be reproduced by running generic/526 with a file<br /> system that has inline_data and fast_commit enabled. The system will<br /> repeatedly log to the console:<br /> <br /> EXT4-fs warning (device dm-3): ext4_block_to_path:105: block 1074800922 &gt; max in inode 131076<br /> <br /> and the stack that it gets stuck in is:<br /> <br /> ext4_block_to_path+0xe3/0x130<br /> ext4_ind_map_blocks+0x93/0x690<br /> ext4_map_blocks+0x100/0x660<br /> skip_hole+0x47/0x70<br /> ext4_ext_replay_set_iblocks+0x223/0x440<br /> ext4_fc_replay_inode+0x29e/0x3b0<br /> ext4_fc_replay+0x278/0x550<br /> do_one_pass+0x646/0xc10<br /> jbd2_journal_recover+0x14a/0x270<br /> jbd2_journal_load+0xc4/0x150<br /> ext4_load_journal+0x1f3/0x490<br /> ext4_fill_super+0x22d4/0x2c00<br /> <br /> With this patch, generic/526 still fails, but system is no longer<br /> locking up in a tight loop. It&amp;#39;s likely the root casue is that<br /> fast_commit replay is corrupting file systems with inline_data, and we<br /> probably need to add better error handling in the fast commit replay<br /> code path beyond what is done here, which essentially just breaks the<br /> infinite loop without reporting the to the higher levels of the code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Handle SRCU initialization failure during page track init<br /> <br /> Check the return of init_srcu_struct(), which can fail due to OOM, when<br /> initializing the page track mechanism. Lack of checking leads to a NULL<br /> pointer deref found by a modified syzkaller.<br /> <br /> [Move the call towards the beginning of kvm_arch_init_vm. - Paolo]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: conntrack: serialize hash resizes and cleanups<br /> <br /> Syzbot was able to trigger the following warning [1]<br /> <br /> No repro found by syzbot yet but I was able to trigger similar issue<br /> by having 2 scripts running in parallel, changing conntrack hash sizes,<br /> and:<br /> <br /> for j in `seq 1 1000` ; do unshare -n /bin/true &gt;/dev/null ; done<br /> <br /> It would take more than 5 minutes for net_namespace structures<br /> to be cleaned up.<br /> <br /> This is because nf_ct_iterate_cleanup() has to restart everytime<br /> a resize happened.<br /> <br /> By adding a mutex, we can serialize hash resizes and cleanups<br /> and also make get_next_corpse() faster by skipping over empty<br /> buckets.<br /> <br /> Even without resizes in the picture, this patch considerably<br /> speeds up network namespace dismantles.<br /> <br /> [1]<br /> INFO: task syz-executor.0:8312 can&amp;#39;t die for more than 144 seconds.<br /> task:syz-executor.0 state:R running task stack:25672 pid: 8312 ppid: 6573 flags:0x00004006<br /> Call Trace:<br /> context_switch kernel/sched/core.c:4955 [inline]<br /> __schedule+0x940/0x26f0 kernel/sched/core.c:6236<br /> preempt_schedule_common+0x45/0xc0 kernel/sched/core.c:6408<br /> preempt_schedule_thunk+0x16/0x18 arch/x86/entry/thunk_64.S:35<br /> __local_bh_enable_ip+0x109/0x120 kernel/softirq.c:390<br /> local_bh_enable include/linux/bottom_half.h:32 [inline]<br /> get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]<br /> nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275<br /> nf_conntrack_cleanup_net_list+0x14c/0x4f0 net/netfilter/nf_conntrack_core.c:2469<br /> ops_exit_list+0x10d/0x160 net/core/net_namespace.c:171<br /> setup_net+0x639/0xa30 net/core/net_namespace.c:349<br /> copy_net_ns+0x319/0x760 net/core/net_namespace.c:470<br /> create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110<br /> unshare_nsproxy_namespaces+0xc1/0x1f0 kernel/nsproxy.c:226<br /> ksys_unshare+0x445/0x920 kernel/fork.c:3128<br /> __do_sys_unshare kernel/fork.c:3202 [inline]<br /> __se_sys_unshare kernel/fork.c:3200 [inline]<br /> __x64_sys_unshare+0x2d/0x40 kernel/fork.c:3200<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f63da68e739<br /> RSP: 002b:00007f63d7c05188 EFLAGS: 00000246 ORIG_RAX: 0000000000000110<br /> RAX: ffffffffffffffda RBX: 00007f63da792f80 RCX: 00007f63da68e739<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040000000<br /> RBP: 00007f63da6e8cc4 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f63da792f80<br /> R13: 00007fff50b75d3f R14: 00007f63d7c05300 R15: 0000000000022000<br /> <br /> Showing all locks held in the system:<br /> 1 lock held by khungtaskd/27:<br /> #0: ffffffff8b980020 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6446<br /> 2 locks held by kworker/u4:2/153:<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: arch_atomic_long_set include/linux/atomic/atomic-long.h:41 [inline]<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: atomic_long_set include/linux/atomic/atomic-instrumented.h:1198 [inline]<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_data kernel/workqueue.c:634 [inline]<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: set_work_pool_and_clear_pending kernel/workqueue.c:661 [inline]<br /> #0: ffff888010c69138 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x896/0x1690 kernel/workqueue.c:2268<br /> #1: ffffc9000140fdb0 ((kfence_timer).work){+.+.}-{0:0}, at: process_one_work+0x8ca/0x1690 kernel/workqueue.c:2272<br /> 1 lock held by systemd-udevd/2970:<br /> 1 lock held by in:imklog/6258:<br /> #0: ffff88807f970ff0 (&amp;f-&gt;f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:990<br /> 3 locks held by kworker/1:6/8158:<br /> 1 lock held by syz-executor.0/8312:<br /> 2 locks held by kworker/u4:13/9320:<br /> 1 lock held by<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc2: 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 /> drm/amdkfd: fix svm_migrate_fini warning<br /> <br /> Device manager releases device-specific resources when a driver<br /> disconnects from a device, devm_memunmap_pages and<br /> devm_release_mem_region calls in svm_migrate_fini are redundant.<br /> <br /> It causes below warning trace after patch "drm/amdgpu: Split<br /> amdgpu_device_fini into early and late", so remove function<br /> svm_migrate_fini.<br /> <br /> BUG: https://gitlab.freedesktop.org/drm/amd/-/issues/1718<br /> <br /> WARNING: CPU: 1 PID: 3646 at drivers/base/devres.c:795<br /> devm_release_action+0x51/0x60<br /> Call Trace:<br /> ? memunmap_pages+0x360/0x360<br /> svm_migrate_fini+0x2d/0x60 [amdgpu]<br /> kgd2kfd_device_exit+0x23/0xa0 [amdgpu]<br /> amdgpu_amdkfd_device_fini_sw+0x1d/0x30 [amdgpu]<br /> amdgpu_device_fini_sw+0x45/0x290 [amdgpu]<br /> amdgpu_driver_release_kms+0x12/0x30 [amdgpu]<br /> drm_dev_release+0x20/0x40 [drm]<br /> release_nodes+0x196/0x1e0<br /> device_release_driver_internal+0x104/0x1d0<br /> driver_detach+0x47/0x90<br /> bus_remove_driver+0x7a/0xd0<br /> pci_unregister_driver+0x3d/0x90<br /> amdgpu_exit+0x11/0x20 [amdgpu]