Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
#2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc #3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930 #4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf] #5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513 #6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa #7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e #9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429 #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4 #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice] #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe
8e4 #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice] #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice] #13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice] #14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1 #15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386 #16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870 #17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6 #18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159 #19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc #20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169 #22 [ffffaad04005ff50]
ll_exit_to_user_mode at ffffffff8b31b50d #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169 #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b RIP: 00007f1baa5c13d7 RSP: 00007fffbcc55a98 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1baa5c13d7 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007fffbcc55ca0 R8: 0000000000000000 R9: 00007fffbcc54e90 R10: 00007fffbcc55050 R11: 0000000000000202 R12: 0000000000000005 R13: 0000000000000000 R14: 00007fffbcc55af0 R15: 0000000000000000 ORIG_RAX: 00000000000000a9 CS: 0033 SS: 002b During reboot all drivers PM shutdown callbacks are invoked. In iavf_shutdown() the adapter st
00000a9 CS: 0033 SS: 002b During reboot all drivers PM shutdown callbacks are invoked. In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE. In ice_shutdown() the call chain above is executed, which at some point calls iavf_remove(). However iavf_remove() expects the VF to be in one of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If that's not the case it sleeps forever. So if iavf_shutdown() gets invoked before iavf_remove() the system will hang indefinitely because the adapter is already in state __IAVF_REMOVE. Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE, as we already went through iavf_shutdown(). References: - https://git.kernel.org
remove() if the state is __IAVF_REMOVE, as we already went through iavf_shutdown(). References: - https://git.kernel.org/stable/c/7a29799fc141ba9e6cf921fc8e958e3398ad1a4f - https://git.kernel.org/stable/c/502b898235f06130750c91512c86dd0e9efe28e6 - https://git.kernel.org/stable/c/f752ace58867de3c063512b21e0f1694fc27f043 - https://git.kernel.org/stable/c/4e264be98b88a6d6f476c11087fe865696e8bef5
CVE ID: CVE-2023-53065 State: PUBLISHED Published: 2025-05-02T15:55:18.789Z Last Updated: 2025-05-04T07:49:03.253Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix perf_output_begin parameter is incorrectly invoked in perf_event_bpf_output syzkaller reportes a KASAN issue with stack-out-of-bounds. The call trace is as follows: dump_stack+0x9c/0xd3 print_address_description.constprop.0+0x19/0x170 __kasan_report.cold+0x6c/0x84 kasan_report+0x3a/0x50 __perf_event_header__init_id+0x34/0x290 perf_event_header__init_id+0x48/0x60 perf_output_begin+0x4a4/0x560 perf_event_bpf_output+0x161/0x1e0 perf_iterate_sb_cpu+0x29e/0x3
_header__init_id+0x48/0x60 perf_output_begin+0x4a4/0x560 perf_event_bpf_output+0x161/0x1e0 perf_iterate_sb_cpu+0x29e/0x340 perf_iterate_sb+0x4c/0xc0 perf_event_bpf_event+0x194/0x2c0 __bpf_prog_put.constprop.0+0x55/0xf0 __cls_bpf_delete_prog+0xea/0x120 [cls_bpf] cls_bpf_delete_prog_work+0x1c/0x30 [cls_bpf] process_one_work+0x3c2/0x730 worker_thread+0x93/0x650 kthread+0x1b8/0x210 ret_from_fork+0x1f/0x30 commit 267fb27352b6 ("perf: Reduce stack usage of perf_output_begin()") use on-stack struct perf_sample_data of the caller function. However, perf_event_bpf_output uses incorrect parameter to convert small-sized data (struct perf_bpf_event) into large-sized data (struct perf_sample_data), which
ect parameter to convert small-sized data (struct perf_bpf_event) into large-sized data (struct perf_sample_data), which causes memory overwriting occurs in __perf_event_header__init_id. References: - https://git.kernel.org/stable/c/ddcf8320003638a06eb1e46412e045d0c5701575 - https://git.kernel.org/stable/c/ac5f88642cb211152041f84a985309e9af4baf59 - https://git.kernel.org/stable/c/ff8137727a2af4ad5f6e6c8b9f7ec5e8db9da86c - https://git.kernel.org/stable/c/3a776fddb4e5598c8bfcd4ad094fba34f9856fc9 - https://git.kernel.org/stable/c/eb81a2ed4f52be831c9fb879752d89645a312c13
CVE ID: CVE-2023-53066 State: PUBLISHED Published: 2025-05-02T15:55:19.730Z Last Updated: 2025-05-04T07:49:04.496Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info We have to make sure that the info returned by the helper is valid before using it. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. References: - https://git.kernel.org/stable/c/7bd0037822fd04da13721f77a42ee5a077d4c5fb - https://git.kernel.org/stable/c/7742c08e012eb65405e8304d100641638c5ff882 - https://git.kernel.org/stable/c/42d72c6d1edc9dc09a5d6f6695d257fa9e9c
stable/c/7742c08e012eb65405e8304d100641638c5ff882 - https://git.kernel.org/stable/c/42d72c6d1edc9dc09a5d6f6695d257fa9e9cc270 - https://git.kernel.org/stable/c/39c3b9dd481c3afce9439b29bafe00444cb4406b - https://git.kernel.org/stable/c/e42d3bde4ec03c863259878dddaef5c351cca7ad - https://git.kernel.org/stable/c/97ea704f39b5ded96f071e98701aa543f6f89683 - https://git.kernel.org/stable/c/b224b0cab3a66e93d414825065a2e667a1d28c32 - https://git.kernel.org/stable/c/25143b6a01d0cc5319edd3de22ffa2578b045550
CVE ID: CVE-2023-53067 State: PUBLISHED Published: 2025-05-02T15:55:20.477Z Last Updated: 2025-05-08T15:38:15.225Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: LoongArch: Only call get_timer_irq() once in constant_clockevent_init() Under CONFIG_DEBUG_ATOMIC_SLEEP=y and CONFIG_DEBUG_PREEMPT=y, we can see the following messages on LoongArch, this is because using might_sleep() in preemption disable context. [ 0.001127] smp: Bringing up secondary CPUs ... [ 0.001222] Booting CPU#1... [ 0.001244] 64-bit Loongson Processor probed (LA464 Core) [ 0.001247] CPU1 revision is: 0014c012 (Loongson-64bit) [ 0.001250] FPU1 revision is: 000
Processor probed (LA464 Core) [ 0.001247] CPU1 revision is: 0014c012 (Loongson-64bit) [ 0.001250] FPU1 revision is: 00000000 [ 0.001252] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 [ 0.001255] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 [ 0.001257] preempt_count: 1, expected: 0 [ 0.001258] RCU nest depth: 0, expected: 0 [ 0.001259] Preemption disabled at: [ 0.001261] [<9000000000223800>] arch_dup_task_struct+0x20/0x110 [ 0.001272] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc7+ #43 [ 0.001275] Hardware name: Loongson Loongson-3A5000-7A1000-1w-A2101/Loongson-LS3A5000-7A1000-1w-A2101, BIOS vUDK2018-LoongArch-V4.0.05132-be
name: Loongson Loongson-3A5000-7A1000-1w-A2101/Loongson-LS3A5000-7A1000-1w-A2101, BIOS vUDK2018-LoongArch-V4.0.05132-beta10 12/13/202 [ 0.001277] Stack : 0072617764726148 0000000000000000 9000000000222f1c 90000001001e0000 [ 0.001286] 90000001001e3be0 90000001001e3be8 0000000000000000 0000000000000000 [ 0.001292] 90000001001e3be8 0000000000000040 90000001001e3cb8 90000001001e3a50 [ 0.001297] 9000000001642000 90000001001e3be8 be694d10ce4139dd 9000000100174500 [ 0.001303] 0000000000000001 0000000000000001 00000000ffffe0a2 0000000000000020 [ 0.001309] 000000000000002f 9000000001354116 00000000056b0000 ffffffffffffffff [ 0.001314] 0000000000000000 0000000000000000 90000000014f6e90 90000000016420
01354116 00000000056b0000 ffffffffffffffff [ 0.001314] 0000000000000000 0000000000000000 90000000014f6e90 9000000001642000 [ 0.001320] 900000000022b69c 0000000000000001 0000000000000000 9000000001736a90 [ 0.001325] 9000000100038000 0000000000000000 9000000000222f34 0000000000000000 [ 0.001331] 00000000000000b0 0000000000000004 0000000000000000 0000000000070000 [ 0.001337] ... [ 0.001339] Call Trace: [ 0.001342] [<9000000000222f34>] show_stack+0x5c/0x180 [ 0.001346] [<90000000010bdd80>] dump_stack_lvl+0x60/0x88 [ 0.001352] [<9000000000266418>] __might_resched+0x180/0x1cc [ 0.001356] [<90000000010c742c>] mutex_lock+0x20/0x64 [ 0.001359] [<90000000002a8ccc>] irq_find_matching_fwspec+0x48/0x124
.001356] [<90000000010c742c>] mutex_lock+0x20/0x64 [ 0.001359] [<90000000002a8ccc>] irq_find_matching_fwspec+0x48/0x124 [ 0.001364] [<90000000002259c4>] constant_clockevent_init+0x68/0x204 [ 0.001368] [<900000000022acf4>] start_secondary+0x40/0xa8 [ 0.001371] [<90000000010c0124>] smpboot_entry+0x60/0x64 Here are the complete call chains: smpboot_entry() start_secondary() constant_clockevent_init() get_timer_irq() irq_find_matching_fwnode() irq_find_matching_fwspec() mutex_lock() might_sleep() __might_sleep() __might_resched() In order to avoid the above issue, we should break the call chains, using timer_irq_installed variable as check condition to only call get_timer_irq() once in constant_
ak the call chains, using timer_irq_installed variable as check condition to only call get_timer_irq() once in constant_clockevent_init() is a simple and proper way. References: - https://git.kernel.org/stable/c/b9c379e1d7e141b102f41858c9b8f6f36e7c89a4 - https://git.kernel.org/stable/c/acadbd058fa12b510fbecca11eae22bd6f654250 - https://git.kernel.org/stable/c/bb7a78e343468873bf00b2b181fcfd3c02d8cb56
CVE ID: CVE-2023-53068 State: PUBLISHED Published: 2025-05-02T15:55:21.142Z Last Updated: 2025-05-04T07:49:06.721Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: usb: lan78xx: Limit packet length to skb->len Packet length retrieved from descriptor may be larger than the actual socket buffer length. In such case the cloned skb passed up the network stack will leak kernel memory contents. Additionally prevent integer underflow when size is less than ETH_FCS_LEN. References: - https://git.kernel.org/stable/c/83de34967473ed31d276381373713cc2869a42e5 - https://git.kernel.org/stable/c/44b9ed73369fc5ec85dd2ee487e986301792a82d - h
/83de34967473ed31d276381373713cc2869a42e5 - https://git.kernel.org/stable/c/44b9ed73369fc5ec85dd2ee487e986301792a82d - https://git.kernel.org/stable/c/7f247f5a2c18b3f21206cdd51193df4f38e1b9f5
CVE ID: CVE-2023-53069 State: PUBLISHED Published: 2025-05-02T15:55:21.790Z Last Updated: 2025-05-04T07:49:07.814Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: octeontx2-vf: Add missing free for alloc_percpu Add the free_percpu for the allocated "vf->hw.lmt_info" in order to avoid memory leak, same as the "pf->hw.lmt_info" in `drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`. References: - https://git.kernel.org/stable/c/90874b76e5f82eaa3309714d72ff2cd8bb8d1b02 - https://git.kernel.org/stable/c/840631bcf21f58c0a3f01378a54d79e9ce86b226 - https://git.kernel.org/stable/c/813b590840771890c738ce6dbfd0c5938a1bafb9 - https://gi
f21f58c0a3f01378a54d79e9ce86b226 - https://git.kernel.org/stable/c/813b590840771890c738ce6dbfd0c5938a1bafb9 - https://git.kernel.org/stable/c/f038f3917baf04835ba2b7bcf2a04ac93fbf8a9c
CVE ID: CVE-2023-53070 State: PUBLISHED Published: 2025-05-02T15:55:22.435Z Last Updated: 2025-05-04T12:50:16.423Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") enabled to map PPTT once on the first invocation of acpi_get_pptt() and never unmapped the same allowing it to be used at runtime with out the hassle of mapping and unmapping the table. This was needed to fetch LLC information from the PPTT in the cpuhotplug path which is executed in the atomic context as the acpi_get
ed to fetch LLC information from the PPTT in the cpuhotplug path which is executed in the atomic context as the acpi_get_table() might sleep waiting for a mutex. However it missed to handle the case when there is no PPTT on the system which results in acpi_get_pptt() being called from all the secondary CPUs attempting to fetch the LLC information in the atomic context without knowing the absence of PPTT resulting in the splat like below: | BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:164 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0
pid: 0, name: swapper/1 | preempt_count: 1, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0. | irq event stamp: 0 | hardirqs last enabled at (0): 0x0 | hardirqs last disabled at (0): copy_process+0x61c/0x1b40 | softirqs last enabled at (0): copy_process+0x61c/0x1b40 | softirqs last disabled at (0): 0x0 | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.3.0-rc1 #1 | Call trace: | dump_backtrace+0xac/0x138 | show_stack+0x30/0x48 | dump_stack_lvl+0x60/0xb0 | dump_stack+0x18/0x28 | __might_resched+0x160/0x270 | __might_sleep+0x58/0xb0 | down_timeout+0x34/0x98 | acpi_os_wait_semaphore+0x7c/0xc0 | acpi_ut_acquire_mutex+0x58/0x108 | acpi_get_table+0x40/0xe8 | acpi_get_pptt+0
/0x98 | acpi_os_wait_semaphore+0x7c/0xc0 | acpi_ut_acquire_mutex+0x58/0x108 | acpi_get_table+0x40/0xe8 | acpi_get_pptt+0x48/0xa0 | acpi_get_cache_info+0x38/0x140 | init_cache_level+0xf4/0x118 | detect_cache_attributes+0x2e4/0x640 | update_siblings_masks+0x3c/0x330 | store_cpu_topology+0x88/0xf0 | secondary_start_kernel+0xd0/0x168 | __secondary_switched+0xb8/0xc0 Update acpi_get_pptt() to consider the fact that PPTT is once checked and is not available on the system and return NULL avoiding any attempts to fetch PPTT and thereby avoiding any possible sleep waiting for a mutex in the atomic context. References: - https://git.kernel.org/stable/c/1318a07706bb2f8c65f88f39a16c2b5260bcdcd4 - https:
x in the atomic context. References: - https://git.kernel.org/stable/c/1318a07706bb2f8c65f88f39a16c2b5260bcdcd4 - https://git.kernel.org/stable/c/e0c1106d51b9abc8eae03c5522b20649b6a55f6e - https://git.kernel.org/stable/c/91d7b60a65d9f71230ea09b86d2058a884a3c2af
CVE ID: CVE-2023-53071 State: PUBLISHED Published: 2025-05-02T15:55:23.130Z Last Updated: 2025-05-04T07:49:10.228Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: do not run mt76_unregister_device() on unregistered hw Trying to probe a mt7921e pci card without firmware results in a successful probe where ieee80211_register_hw hasn't been called. When removing the driver, ieee802111_unregister_hw is called unconditionally leading to a kernel NULL pointer dereference. Fix the issue running mt76_unregister_device routine just for registered hw. References: - https://git.kernel.org/stable/c/dffe86df26aee01a5fc56a175b7a7f
ster_device routine just for registered hw. References: - https://git.kernel.org/stable/c/dffe86df26aee01a5fc56a175b7a7f157961e370 - https://git.kernel.org/stable/c/2d34f27714c97a9786a30b3bb54944d6d8ed612f - https://git.kernel.org/stable/c/41130c32f3a18fcc930316da17f3a5f3bc326aa1
CVE ID: CVE-2023-53072 State: PUBLISHED Published: 2025-05-02T15:55:23.765Z Last Updated: 2025-05-04T07:49:11.317Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: use the workqueue to destroy unaccepted sockets Christoph reported a UaF at token lookup time after having refactored the passive socket initialization part: BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260 Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198 CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-
rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 __token_bucket_busy+0x253/0x260 mptcp_token_new_connect+0x13d/0x490 mptcp_connect+0x4ed/0x860 __inet_stream_connect+0x80e/0xd90 tcp_sendmsg_fastopen+0x3ce/0x710 mptcp_sendmsg+0xff1/0x1a20 inet_sendmsg+0x11d/0x140 __sys_sendto+0x405/0x490 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc We need to properly clean-up all the paired MPTCP-level resources and be sure to release the msk last, even when
2/0xdc We need to properly clean-up all the paired MPTCP-level resources and be sure to release the msk last, even when the unaccepted subflow is destroyed by the TCP internals via inet_child_forget(). We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra, explicitly checking that for the critical scenario: the closed subflow is the MPC one, the msk is not accepted and eventually going through full cleanup. With such change, __mptcp_destroy_sock() is always called on msk sockets, even on accepted ones. We don't need anymore to transiently drop one sk reference at msk clone time. Please note this commit depends on the parent one: mptcp: refactor passive socket initialization References: -
one time. Please note this commit depends on the parent one: mptcp: refactor passive socket initialization References: - https://git.kernel.org/stable/c/2827f099b3fb9a59263c997400e9182f5d423e84 - https://git.kernel.org/stable/c/804cf487fb0031f3c74755b78d8663333f0ba636 - https://git.kernel.org/stable/c/b6985b9b82954caa53f862d6059d06c0526254f0
CVE ID: CVE-2023-53073 State: PUBLISHED Published: 2025-05-02T15:55:24.413Z Last Updated: 2025-05-04T07:49:12.403Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/core: Always clear status for idx The variable 'status' (which contains the unhandled overflow bits) is not being properly masked in some cases, displaying the following warning: WARNING: CPU: 156 PID: 475601 at arch/x86/events/amd/core.c:972 amd_pmu_v2_handle_irq+0x216/0x270 This seems to be happening because the loop is being continued before the status bit being unset, in case x86_perf_event_set_period() returns 0. This is also causing an inconsistency
before the status bit being unset, in case x86_perf_event_set_period() returns 0. This is also causing an inconsistency because the "handled" counter is incremented, but the status bit is not cleaned. Move the bit cleaning together above, together when the "handled" counter is incremented. References: - https://git.kernel.org/stable/c/ab33a8f7649b0324639a336e1081aaea51a4523e - https://git.kernel.org/stable/c/9d4c7b1f12e101d6d6253092588b127416ddfb6c - https://git.kernel.org/stable/c/263f5ecaf7080513efc248ec739b6d9e00f4129f
CVE ID: CVE-2023-53074 State: PUBLISHED Published: 2025-05-02T15:55:25.302Z Last Updated: 2025-09-16T08:02:16.529Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix ttm_bo calltrace warning in psp_hw_fini The call trace occurs when the amdgpu is removed after the mode1 reset. During mode1 reset, from suspend to resume, there is no need to reinitialize the ta firmware buffer which caused the bo pin_count increase redundantly. [ 489.885525] Call Trace: [ 489.885525] <TASK> [ 489.885526] amdttm_bo_put+0x34/0x50 [amdttm] [ 489.885529] amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu] [ 489.885620] psp_free_shared_bufs+0xb7/0x1
t+0x34/0x50 [amdttm] [ 489.885529] amdgpu_bo_free_kernel+0xe8/0x130 [amdgpu] [ 489.885620] psp_free_shared_bufs+0xb7/0x150 [amdgpu] [ 489.885720] psp_hw_fini+0xce/0x170 [amdgpu] [ 489.885815] amdgpu_device_fini_hw+0x2ff/0x413 [amdgpu] [ 489.885960] ? blocking_notifier_chain_unregister+0x56/0xb0 [ 489.885962] amdgpu_driver_unload_kms+0x51/0x60 [amdgpu] [ 489.886049] amdgpu_pci_remove+0x5a/0x140 [amdgpu] [ 489.886132] ? __pm_runtime_resume+0x60/0x90 [ 489.886134] pci_device_remove+0x3e/0xb0 [ 489.886135] __device_release_driver+0x1ab/0x2a0 [ 489.886137] driver_detach+0xf3/0x140 [ 489.886138] bus_remove_driver+0x6c/0xf0 [ 489.886140] driver_unregister+0x31/0x60 [ 489.886141] pci_unregister_driv
40 [ 489.886138] bus_remove_driver+0x6c/0xf0 [ 489.886140] driver_unregister+0x31/0x60 [ 489.886141] pci_unregister_driver+0x40/0x90 [ 489.886142] amdgpu_exit+0x15/0x451 [amdgpu] References: - https://git.kernel.org/stable/c/7be9a2f8c5179520a7d5570e648e0c97d09e4fae - https://git.kernel.org/stable/c/55a7c647ebf6e376c45d8322568dd6eb71937139 - https://git.kernel.org/stable/c/23f4a2d29ba57bf88095f817de5809d427fcbe7e
CVE ID: CVE-2023-53075 State: PUBLISHED Published: 2025-05-02T15:55:26.023Z Last Updated: 2025-05-04T07:49:14.766Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix invalid address access in lookup_rec() when index is 0 KASAN reported follow problem: BUG: KASAN: use-after-free in lookup_rec Read of size 8 at addr ffff000199270ff0 by task modprobe CPU: 2 Comm: modprobe Call trace: kasan_report __asan_load8 lookup_rec ftrace_location arch_check_ftrace_location check_kprobe_address_safe register_kprobe When checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a pg which is newly added to ftrace_pages_start i
hen checking pg->records[pg->index - 1].ip in lookup_rec(), it can get a pg which is newly added to ftrace_pages_start in ftrace_process_locs(). Before the first pg->index++, index is 0 and accessing pg->records[-1].ip will cause this problem. Don't check the ip when pg->index is 0. References: - https://git.kernel.org/stable/c/2de28e5ce34b22b73b833a21e2c45ae3aade3964 - https://git.kernel.org/stable/c/7569ee04b0e3b32df79f64db3a7138573edad9bc - https://git.kernel.org/stable/c/ac58b88ccbbb8e9fb83e137cee04a856b1ea6635 - https://git.kernel.org/stable/c/83c3b2f4e7c61367c7b24551f4c6eb94bbdda283 - https://git.kernel.org/stable/c/2a0d71fabfeb349216d33f001a6421b1768bd3a9 - https://git.kernel.org/stab
4c6eb94bbdda283 - https://git.kernel.org/stable/c/2a0d71fabfeb349216d33f001a6421b1768bd3a9 - https://git.kernel.org/stable/c/4f84f31f63416b0f02fc146ffdc4ab32723eb7e8 - https://git.kernel.org/stable/c/f1bd8b7fd890d87d0dc4dedc6287ea34dd07c0b4 - https://git.kernel.org/stable/c/ee92fa443358f4fc0017c1d0d325c27b37802504
CVE ID: CVE-2023-53076 State: REJECTED Published: 2025-05-02T15:55:26.722Z Last Updated: 2025-05-05T14:45:06.828Z Description: No description available.
CVE ID: CVE-2023-53077 State: PUBLISHED Published: 2025-05-02T15:55:27.613Z Last Updated: 2025-09-03T13:06:38.200Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes [WHY] When PTEBufferSizeInRequests is zero, UBSAN reports the following warning because dml_log2 returns an unexpected negative value: shift exponent 4294966273 is too large for 32-bit type 'int' [HOW] In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and assign the result directly. References: - https://git.kernel.org/stable/c/7257070be70e19a9138f39009c1a26c83a8a7cfa - https://git.kernel