Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini<br /> <br /> The call trace occurs when the amdgpu is removed after<br /> the mode1 reset. During mode1 reset, from suspend to resume,<br /> there is no need to reinitialize the ta firmware buffer<br /> which caused the bo pin_count increase redundantly.<br /> <br /> [ 489.885525] Call Trace:<br /> [ 489.885525] <br /> [ 489.885526] amdttm_bo_put+0x34/0x50 [amdttm]<br /> [ 489.885529] amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu]<br /> [ 489.885620] psp_free_shared_bufs+0xb7/0x150 [amdgpu]<br /> [ 489.885720] psp_hw_fini+0xce/0x170 [amdgpu]<br /> [ 489.885815] amdgpu_device_fini_hw+0x2ff/0x413 [amdgpu]<br /> [ 489.885960] ? blocking_notifier_chain_unregister+0x56/0xb0<br /> [ 489.885962] amdgpu_driver_unload_kms+0x51/0x60 [amdgpu]<br /> [ 489.886049] amdgpu_pci_remove+0x5a/0x140 [amdgpu]<br /> [ 489.886132] ? __pm_runtime_resume+0x60/0x90<br /> [ 489.886134] pci_device_remove+0x3e/0xb0<br /> [ 489.886135] __device_release_driver+0x1ab/0x2a0<br /> [ 489.886137] driver_detach+0xf3/0x140<br /> [ 489.886138] bus_remove_driver+0x6c/0xf0<br /> [ 489.886140] driver_unregister+0x31/0x60<br /> [ 489.886141] pci_unregister_driver+0x40/0x90<br /> [ 489.886142] amdgpu_exit+0x15/0x451 [amdgpu]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/amd/core: Always clear status for idx<br /> <br /> The variable &amp;#39;status&amp;#39; (which contains the unhandled overflow bits) is<br /> not being properly masked in some cases, displaying the following<br /> warning:<br /> <br /> WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270<br /> <br /> This seems to be happening because the loop is being continued before<br /> the status bit being unset, in case x86_perf_event_set_period()<br /> returns 0. This is also causing an inconsistency because the "handled"<br /> counter is incremented, but the status bit is not cleaned.<br /> <br /> Move the bit cleaning together above, together when the "handled"<br /> counter is incremented.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: use the workqueue to destroy unaccepted sockets<br /> <br /> Christoph reported a UaF at token lookup time after having<br /> refactored the passive socket initialization part:<br /> <br /> BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260<br /> Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198<br /> <br /> CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6e/0x91<br /> print_report+0x16a/0x46f<br /> kasan_report+0xad/0x130<br /> __token_bucket_busy+0x253/0x260<br /> mptcp_token_new_connect+0x13d/0x490<br /> mptcp_connect+0x4ed/0x860<br /> __inet_stream_connect+0x80e/0xd90<br /> tcp_sendmsg_fastopen+0x3ce/0x710<br /> mptcp_sendmsg+0xff1/0x1a20<br /> inet_sendmsg+0x11d/0x140<br /> __sys_sendto+0x405/0x490<br /> __x64_sys_sendto+0xdc/0x1b0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> We need to properly clean-up all the paired MPTCP-level<br /> resources and be sure to release the msk last, even when<br /> the unaccepted subflow is destroyed by the TCP internals<br /> via inet_child_forget().<br /> <br /> We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra,<br /> explicitly checking that for the critical scenario: the<br /> closed subflow is the MPC one, the msk is not accepted and<br /> eventually going through full cleanup.<br /> <br /> With such change, __mptcp_destroy_sock() is always called<br /> on msk sockets, even on accepted ones. We don&amp;#39;t need anymore<br /> to transiently drop one sk reference at msk clone time.<br /> <br /> Please note this commit depends on the parent one:<br /> <br /> mptcp: refactor passive socket initialization

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: do not run mt76_unregister_device() on unregistered hw<br /> <br /> Trying to probe a mt7921e pci card without firmware results in a<br /> successful probe where ieee80211_register_hw hasn&amp;#39;t been called. When<br /> removing the driver, ieee802111_unregister_hw is called unconditionally<br /> leading to a kernel NULL pointer dereference.<br /> Fix the issue running mt76_unregister_device routine just for registered<br /> hw.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent<br /> <br /> Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")<br /> enabled to map PPTT once on the first invocation of acpi_get_pptt() and<br /> never unmapped the same allowing it to be used at runtime with out the<br /> hassle of mapping and unmapping the table. This was needed to fetch LLC<br /> information from the PPTT in the cpuhotplug path which is executed in<br /> the atomic context as the acpi_get_table() might sleep waiting for a<br /> mutex.<br /> <br /> However it missed to handle the case when there is no PPTT on the system<br /> which results in acpi_get_pptt() being called from all the secondary<br /> CPUs attempting to fetch the LLC information in the atomic context<br /> without knowing the absence of PPTT resulting in the splat like below:<br /> <br /> | BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:164<br /> | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1<br /> | preempt_count: 1, expected: 0<br /> | RCU nest depth: 0, expected: 0<br /> | no locks held by swapper/1/0.<br /> | irq event stamp: 0<br /> | hardirqs last enabled at (0): 0x0<br /> | hardirqs last disabled at (0): copy_process+0x61c/0x1b40<br /> | softirqs last enabled at (0): copy_process+0x61c/0x1b40<br /> | softirqs last disabled at (0): 0x0<br /> | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.3.0-rc1 #1<br /> | Call trace:<br /> | dump_backtrace+0xac/0x138<br /> | show_stack+0x30/0x48<br /> | dump_stack_lvl+0x60/0xb0<br /> | dump_stack+0x18/0x28<br /> | __might_resched+0x160/0x270<br /> | __might_sleep+0x58/0xb0<br /> | down_timeout+0x34/0x98<br /> | acpi_os_wait_semaphore+0x7c/0xc0<br /> | acpi_ut_acquire_mutex+0x58/0x108<br /> | acpi_get_table+0x40/0xe8<br /> | acpi_get_pptt+0x48/0xa0<br /> | acpi_get_cache_info+0x38/0x140<br /> | init_cache_level+0xf4/0x118<br /> | detect_cache_attributes+0x2e4/0x640<br /> | update_siblings_masks+0x3c/0x330<br /> | store_cpu_topology+0x88/0xf0<br /> | secondary_start_kernel+0xd0/0x168<br /> | __secondary_switched+0xb8/0xc0<br /> <br /> Update acpi_get_pptt() to consider the fact that PPTT is once checked and<br /> is not available on the system and return NULL avoiding any attempts to<br /> fetch PPTT and thereby avoiding any possible sleep waiting for a mutex<br /> in the atomic context.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: fix hang on reboot with ice<br /> <br /> When a system with E810 with existing VFs gets rebooted the following<br /> hang may be observed.<br /> <br /> Pid 1 is hung in iavf_remove(), part of a network driver:<br /> PID: 1 TASK: ffff965400e5a340 CPU: 24 COMMAND: "systemd-shutdow"<br /> #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb<br /> #1 [ffffaad04005fae8] schedule at ffffffff8b323e2d<br /> #2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc<br /> #3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930<br /> #4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf]<br /> #5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513<br /> #6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa<br /> #7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc<br /> #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e<br /> #9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429<br /> #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4<br /> #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice]<br /> #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice]<br /> #13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice]<br /> #14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1<br /> #15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386<br /> #16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870<br /> #17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6<br /> #18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159<br /> #19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc<br /> #20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d<br /> #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169<br /> #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b<br /> RIP: 00007f1baa5c13d7 RSP: 00007fffbcc55a98 RFLAGS: 00000202<br /> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1baa5c13d7<br /> RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead<br /> RBP: 00007fffbcc55ca0 R8: 0000000000000000 R9: 00007fffbcc54e90<br /> R10: 00007fffbcc55050 R11: 0000000000000202 R12: 0000000000000005<br /> R13: 0000000000000000 R14: 00007fffbcc55af0 R15: 0000000000000000<br /> ORIG_RAX: 00000000000000a9 CS: 0033 SS: 002b<br /> <br /> During reboot all drivers PM shutdown callbacks are invoked.<br /> In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE.<br /> In ice_shutdown() the call chain above is executed, which at some point<br /> calls iavf_remove(). However iavf_remove() expects the VF to be in one<br /> of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If<br /> that&amp;#39;s not the case it sleeps forever.<br /> So if iavf_shutdown() gets invoked before iavf_remove() the system will<br /> hang indefinitely because the adapter is already in state __IAVF_REMOVE.<br /> <br /> Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE,<br /> as we already went through iavf_shutdown().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: smsc95xx: Limit packet length to skb-&gt;len<br /> <br /> Packet length retrieved from descriptor may be larger than<br /> the actual socket buffer length. In such case the cloned<br /> skb passed up the network stack will leak kernel memory contents.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: revert rtnl_lock() that causes deadlock<br /> <br /> The commit 6faee3d4ee8b ("igb: Add lock to avoid data race") adds<br /> rtnl_lock to eliminate a false data race shown below<br /> <br /> (FREE from device detaching) | (USE from netdev core)<br /> igb_remove | igb_ndo_get_vf_config<br /> igb_disable_sriov | vf &gt;= adapter-&gt;vfs_allocated_count?<br /> kfree(adapter-&gt;vf_data) |<br /> adapter-&gt;vfs_allocated_count = 0 |<br /> | memcpy(... adapter-&gt;vf_data[vf]<br /> <br /> The above race will never happen and the extra rtnl_lock causes deadlock<br /> below<br /> <br /> [ 141.420169] <br /> [ 141.420672] __schedule+0x2dd/0x840<br /> [ 141.421427] schedule+0x50/0xc0<br /> [ 141.422041] schedule_preempt_disabled+0x11/0x20<br /> [ 141.422678] __mutex_lock.isra.13+0x431/0x6b0<br /> [ 141.423324] unregister_netdev+0xe/0x20<br /> [ 141.423578] igbvf_remove+0x45/0xe0 [igbvf]<br /> [ 141.423791] pci_device_remove+0x36/0xb0<br /> [ 141.423990] device_release_driver_internal+0xc1/0x160<br /> [ 141.424270] pci_stop_bus_device+0x6d/0x90<br /> [ 141.424507] pci_stop_and_remove_bus_device+0xe/0x20<br /> [ 141.424789] pci_iov_remove_virtfn+0xba/0x120<br /> [ 141.425452] sriov_disable+0x2f/0xf0<br /> [ 141.425679] igb_disable_sriov+0x4e/0x100 [igb]<br /> [ 141.426353] igb_remove+0xa0/0x130 [igb]<br /> [ 141.426599] pci_device_remove+0x36/0xb0<br /> [ 141.426796] device_release_driver_internal+0xc1/0x160<br /> [ 141.427060] driver_detach+0x44/0x90<br /> [ 141.427253] bus_remove_driver+0x55/0xe0<br /> [ 141.427477] pci_unregister_driver+0x2a/0xa0<br /> [ 141.428296] __x64_sys_delete_module+0x141/0x2b0<br /> [ 141.429126] ? mntput_no_expire+0x4a/0x240<br /> [ 141.429363] ? syscall_trace_enter.isra.19+0x126/0x1a0<br /> [ 141.429653] do_syscall_64+0x5b/0x80<br /> [ 141.429847] ? exit_to_user_mode_prepare+0x14d/0x1c0<br /> [ 141.430109] ? syscall_exit_to_user_mode+0x12/0x30<br /> [ 141.430849] ? do_syscall_64+0x67/0x80<br /> [ 141.431083] ? syscall_exit_to_user_mode_prepare+0x183/0x1b0<br /> [ 141.431770] ? syscall_exit_to_user_mode+0x12/0x30<br /> [ 141.432482] ? do_syscall_64+0x67/0x80<br /> [ 141.432714] ? exc_page_fault+0x64/0x140<br /> [ 141.432911] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> Since the igb_disable_sriov() will call pci_disable_sriov() before<br /> releasing any resources, the netdev core will synchronize the cleanup to<br /> avoid any races. This patch removes the useless rtnl_(un)lock to guarantee<br /> correctness.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix possible refcount leak in smb2_open()<br /> <br /> Reference count of acls will leak when memory allocation fails. Fix this<br /> by adding the missing posix_acl_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-vf: Add missing free for alloc_percpu<br /> <br /> Add the free_percpu for the allocated "vf-&gt;hw.lmt_info" in order to avoid<br /> memory leak, same as the "pf-&gt;hw.lmt_info" in<br /> `drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: lan78xx: Limit packet length to skb-&gt;len<br /> <br /> Packet length retrieved from descriptor may be larger than<br /> the actual socket buffer length. In such case the cloned<br /> skb passed up the network stack will leak kernel memory contents.<br /> <br /> Additionally prevent integer underflow when size is less than<br /> ETH_FCS_LEN.