Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2023-53544 State: PUBLISHED Published: 2025-10-04T15:16:52.791Z Last Updated: 2025-10-04T15:16:52.791Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq: davinci: Fix clk use after free The remove function first frees the clks and only then calls cpufreq_unregister_driver(). If one of the cpufreq callbacks is called just before cpufreq_unregister_driver() is run, the freed clks might be used. References: - https://git.kernel.org/stable/c/66b3bbe6fbd8dd410868e5b53ac3944a934b9310 - https://git.kernel.org/stable/c/a5f024d0e6f91e05c816ad4ee8837173369dd5cb - https://git.kernel.org/stable/c/ab05ae4ab831f64bbc427592c8
ernel.org/stable/c/a5f024d0e6f91e05c816ad4ee8837173369dd5cb - https://git.kernel.org/stable/c/ab05ae4ab831f64bbc427592c86f599ed9c4324f - https://git.kernel.org/stable/c/5d8f384a9b4fc50f6a18405f1c08e5a87a77b5b3
CVE ID: CVE-2023-53545 State: PUBLISHED Published: 2025-10-04T15:16:53.452Z Last Updated: 2025-10-04T15:16:53.452Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: unmap and remove csa_va properly Root PD BO should be reserved before unmap and remove a bo_va from VM otherwise lockdep will complain. v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian) [14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu] [14616.937096] Call Trace: [14616.937097] <TASK> [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187]
37096] Call Trace: [14616.937097] <TASK> [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187] drm_file_free+0x1d6/0x300 [drm] [14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm] [14616.937220] drm_release+0x5e/0x100 [drm] [14616.937234] __fput+0x9f/0x280 [14616.937239] ____fput+0xe/0x20 [14616.937241] task_work_run+0x61/0x90 [14616.937246] exit_to_user_mode_prepare+0x215/0x220 [14616.937251] syscall_exit_to_user_mode+0x2a/0x60 [14616.937254] do_syscall_64+0x48/0x90 [14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/a3a96bf843c356d1d9b2d7f6d0784b6ee28ca9d0 - https://git.kernel.org/stable/c/5daff15cd013422bc6d1efcf
.kernel.org/stable/c/a3a96bf843c356d1d9b2d7f6d0784b6ee28ca9d0 - https://git.kernel.org/stable/c/5daff15cd013422bc6d1efcfe82b586800025384
CVE ID: CVE-2023-53546 State: PUBLISHED Published: 2025-10-04T15:16:54.132Z Last Updated: 2025-10-04T15:16:54.132Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctx when mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memory pointed by 'in' is not released, which will cause memory leak. Move memory release after mlx5_cmd_exec. References: - https://git.kernel.org/stable/c/800d8c96bf997da5eb76ccf8d88795c4231c83fb - https://git.kernel.org/stable/c/165159854757dbae0dfd1812b27051da35aa6223 - https://git.kernel.org/stable/c/00cecb0a8f9e7a21754d5ad85813ab6b47b33
table/c/165159854757dbae0dfd1812b27051da35aa6223 - https://git.kernel.org/stable/c/00cecb0a8f9e7a21754d5ad85813ab6b47b3308f - https://git.kernel.org/stable/c/3169c3854397f3070a63b1b772db16dcb8cba7b4 - https://git.kernel.org/stable/c/622d71d99124e69f7bf2e2b7a89f5f444a24d235 - https://git.kernel.org/stable/c/5dd77585dd9d0e03dd1bceb95f0269a7eaf6b936
CVE ID: CVE-2023-53547 State: PUBLISHED Published: 2025-10-04T15:16:54.794Z Last Updated: 2025-10-29T10:50:29.575Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix sdma v4 sw fini error Fix sdma v4 sw fini error for sdma 4.2.2 to solve the following general protection fault [ +0.108196] general protection fault, probably for non-canonical address 0xd5e5a4ae79d24a32: 0000 [#1] PREEMPT SMP PTI [ +0.000018] RIP: 0010:free_fw_priv+0xd/0x70 [ +0.000022] Call Trace: [ +0.000012] <TASK> [ +0.000011] release_firmware+0x55/0x80 [ +0.000021] amdgpu_ucode_release+0x11/0x20 [amdgpu] [ +0.000415] amdgpu_sdma_destroy_inst_ctx+0
ease_firmware+0x55/0x80 [ +0.000021] amdgpu_ucode_release+0x11/0x20 [amdgpu] [ +0.000415] amdgpu_sdma_destroy_inst_ctx+0x4f/0x90 [amdgpu] [ +0.000360] sdma_v4_0_sw_fini+0xce/0x110 [amdgpu] References: - https://git.kernel.org/stable/c/210ef6cd8e634f18fd889421012192b81325b27b - https://git.kernel.org/stable/c/0ebc02d9ff85626a526353584526da6aa9c96792 - https://git.kernel.org/stable/c/5e08e9c742a00384e5abe74bd40cf4dc15cb3a2e
CVE ID: CVE-2023-53548 State: PUBLISHED Published: 2025-10-04T15:16:55.612Z Last Updated: 2025-10-04T15:16:55.612Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urb The syzbot fuzzer identified a problem in the usbnet driver: usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Modules linked in: CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 W
aller-00014-g692b7dc87ca6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Workqueue: mld mld_ifc_work RIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7 RSP: 0018:ffffc9000463f568 EFLAGS: 00010086 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001 RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R1
0000001 RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003 R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500 FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0 Call Trace: <TASK> usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453 __netdev_start_xmit include/linux/netdevice.h:4918 [inline] netdev_start_xmit include/linux/netdevice.h:4932 [inline] xmit_one net/core/dev.c:3578 [inline] dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594 ... This bug is
:4932 [inline] xmit_one net/core/dev.c:3578 [inline] dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594 ... This bug is caused by the fact that usbnet trusts the bulk endpoint addresses its probe routine receives in the driver_info structure, and it does not check to see that these endpoints actually exist and have the expected type and directions. The fix is simply to add such a check. References: - https://git.kernel.org/stable/c/a0715d04cf687a7e21f0d6ac8c1d479294a3f6f8 - https://git.kernel.org/stable/c/53c250ea57cf03af41339234b9855ae284f9db91 - https://git.kernel.org/stable/c/a05ac5d00eb7fcb2fda806caa4f56e88df6bc6bb - https://git.kernel.org/stable/c/ec0d0be41721aca683c5606354a58ee2c687e3
able/c/a05ac5d00eb7fcb2fda806caa4f56e88df6bc6bb - https://git.kernel.org/stable/c/ec0d0be41721aca683c5606354a58ee2c687e3f8 - https://git.kernel.org/stable/c/27d0f755d649d388fcd12f01436c9a33289e14e3 - https://git.kernel.org/stable/c/1bebbd9b8037a9cc75984317cb495dec4824c399 - https://git.kernel.org/stable/c/0dd3e0c31bf3e933fb85faf1443833aef90b8e46 - https://git.kernel.org/stable/c/5e1627cb43ddf1b24b92eb26f8d958a3f5676ccb
CVE ID: CVE-2023-53549 State: PUBLISHED Published: 2025-10-04T15:16:56.382Z Last Updated: 2025-10-04T15:16:56.382Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: Rework long task execution when adding/deleting entries When adding/deleting large number of elements in one step in ipset, it can take a reasonable amount of time and can result in soft lockup errors. The patch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range of consecutive elements to add/delete") tried to fix it by limiting the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering t
g the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering the limit is not reasonable, so the approach in this patch is as follows: rely on the method used at resizing sets and save the state when we reach a smaller internal batch limit, unlock/lock and proceed from the saved state. Thus we can avoid long continuous tasks and at the same time removed the limit to add/delete large number of elements in one step. The nfnl mutex is held during the whole operation which prevents one to issue other ipset commands in parallel. References: - https://git.kernel.org/stable/c/ee756980e491c829ba0495bb420b7224a9ee26b2 - https://git.kernel.org/
rallel. References: - https://git.kernel.org/stable/c/ee756980e491c829ba0495bb420b7224a9ee26b2 - https://git.kernel.org/stable/c/a1e1521b463968b4eca7163f61fb6cc54d008061 - https://git.kernel.org/stable/c/24a828f5a54bdeca0846526860d72b3766c5fe95 - https://git.kernel.org/stable/c/8964cc36ba011dc0e1041131fa2e91fb4c2a811b - https://git.kernel.org/stable/c/5e29dc36bd5e2166b834ceb19990d9e68a734d7d
CVE ID: CVE-2023-53550 State: PUBLISHED Published: 2025-10-04T15:16:57.061Z Last Updated: 2025-10-04T15:16:57.061Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: fix global sysfs attribute type In commit 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()") the "amd_pstate" attributes where moved from a dedicated kobject to the cpu root kobject. While the dedicated kobject expects to contain kobj_attributes the root kobject needs device_attributes. As the changed arguments are not used by the callbacks it works most of the time. However CFI will detect this issue: [ 4947.849350] CFI failure a
re not used by the callbacks it works most of the time. However CFI will detect this issue: [ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de) ... [ 4947.849409] Call Trace: [ 4947.849410] <TASK> [ 4947.849411] ? __warn+0xcf/0x1c0 [ 4947.849414] ? dev_attr_show+0x24/0x60 [ 4947.849415] ? report_cfi_failure+0x4e/0x60 [ 4947.849417] ? handle_cfi_failure+0x14c/0x1d0 [ 4947.849419] ? __cfi_show_status+0x10/0x10 [ 4947.849420] ? handle_bug+0x4f/0x90 [ 4947.849421] ? exc_invalid_op+0x1a/0x60 [ 4947.849422] ? asm_exc_invalid_op+0x1a/0x20 [ 4947.849424] ? __cfi_show_status+0x10/0x10 [ 4947.849425] ? dev_attr_show+0x24/0x60 [ 4947.849426] s
alid_op+0x1a/0x20 [ 4947.849424] ? __cfi_show_status+0x10/0x10 [ 4947.849425] ? dev_attr_show+0x24/0x60 [ 4947.849426] sysfs_kf_seq_show+0xa6/0x110 [ 4947.849433] seq_read_iter+0x16c/0x4b0 [ 4947.849436] vfs_read+0x272/0x2d0 [ 4947.849438] ksys_read+0x72/0xe0 [ 4947.849439] do_syscall_64+0x76/0xb0 [ 4947.849440] ? do_user_addr_fault+0x252/0x650 [ 4947.849442] ? exc_page_fault+0x7a/0x1b0 [ 4947.849443] entry_SYSCALL_64_after_hwframe+0x72/0xdc References: - https://git.kernel.org/stable/c/ddcfc33a20380508f7fea18e1c330abe17ed4fc0 - https://git.kernel.org/stable/c/5e720f8c8c9d959283c3908bbf32a91a01a86547
CVE ID: CVE-2023-53551 State: PUBLISHED Published: 2025-10-04T15:16:57.736Z Last Updated: 2025-10-04T15:16:57.736Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Add null pointer check in gserial_resume Consider a case where gserial_disconnect has already cleared gser->ioport. And if a wakeup interrupt triggers afterwards, gserial_resume gets called, which will lead to accessing of gser->ioport and thus causing null pointer dereference.Add a null pointer check to prevent this. Added a static spinlock to prevent gser->ioport from becoming null after the newly added check. References: - https://git.kernel.o
atic spinlock to prevent gser->ioport from becoming null after the newly added check. References: - https://git.kernel.org/stable/c/c5360eec648bd506afa304ae4a71f82e13d41897 - https://git.kernel.org/stable/c/3b24c980dc07be4550a9d1450ed7057f882530e5 - https://git.kernel.org/stable/c/ec357cd3e8af614855d286dd378725cdc7264df6 - https://git.kernel.org/stable/c/44e004f757a7ae13dfebaadbcfdb1a6f98c10377 - https://git.kernel.org/stable/c/5ec63fdbca604568890c577753c6f66c5b3ef0b5
CVE ID: CVE-2023-53552 State: PUBLISHED Published: 2025-10-04T15:16:58.429Z Last Updated: 2025-10-04T15:16:58.429Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915: mark requests for GuC virtual engines to avoid use-after-free References to i915_requests may be trapped by userspace inside a sync_file or dmabuf (dma-resv) and held indefinitely across different proceses. To counter-act the memory leaks, we try to not to keep references from the request past their completion. On the other side on fence release we need to know if rq->engine is valid and points to hw engine (true for non-virtual requests). To make it possible
ease we need to know if rq->engine is valid and points to hw engine (true for non-virtual requests). To make it possible extra bit has been added to rq->execution_mask, for marking virtual engines. (cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580) References: - https://git.kernel.org/stable/c/8017a27cec32eac8c8f9430b0a3055840136b856 - https://git.kernel.org/stable/c/7fb464d52fa41c31a6fd1ad82888e67c65935d94 - https://git.kernel.org/stable/c/5eefc5307c983b59344a4cb89009819f580c84fa
CVE ID: CVE-2023-53553 State: PUBLISHED Published: 2025-10-04T15:16:59.091Z Last Updated: 2025-10-04T15:16:59.091Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: avoid struct memcpy overrun warning A previous patch addressed the fortified memcpy warning for most builds, but I still see this one with gcc-9: In file included from include/linux/string.h:254, from drivers/hid/hid-hyperv.c:8: In function 'fortify_memcpy_chk', inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3: include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write b
/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 583 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ My guess is that the WARN_ON() itself is what confuses gcc, so it no longer sees that there is a correct range check. Rework the code in a way that helps readability and avoids the warning. References: - https://git.kernel.org/stable/c/a7902cc5f5b9c95997017c8e309da760fb1deb6e - https://git.kernel.org/stable/c/5f151364b1da6bd217632fd4ee8cc24eaf66a497
CVE ID: CVE-2023-53554 State: PUBLISHED Published: 2025-10-04T15:16:59.749Z Last Updated: 2025-10-04T15:16:59.749Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext() The "exc->key_len" is a u16 that comes from the user. If it's over IW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption. References: - https://git.kernel.org/stable/c/9496fb96ddeb740dc6b966f4a7d8dfb8b93921c6 - https://git.kernel.org/stable/c/663fff29fd613e2b0d30c4138157312ba93c4939 - https://git.kernel.org/stable/c/5373a1aa91b2298f9305794b8270cf9896be96b6 - https://git.kernel.org/stable/c
12ba93c4939 - https://git.kernel.org/stable/c/5373a1aa91b2298f9305794b8270cf9896be96b6 - https://git.kernel.org/stable/c/caac4b6c15b66feae4d83f602e1e46f124540202 - https://git.kernel.org/stable/c/baf420e30364ef9efe3e29a5c0e01e612aebf3fe - https://git.kernel.org/stable/c/7ae9f55a495077f838bab466411ee6f38574df9b - https://git.kernel.org/stable/c/b1b04b56745bc79286c80aa876fabfab1e08ebf1 - https://git.kernel.org/stable/c/5f1c7031e044cb2fba82836d55cc235e2ad619dc
CVE ID: CVE-2023-53555 State: PUBLISHED Published: 2025-10-04T15:17:00.514Z Last Updated: 2025-10-04T15:17:00.514Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: initialize damo_filter->list from damos_new_filter() damos_new_filter() is not initializing the list field of newly allocated filter object. However, DAMON sysfs interface and DAMON_RECLAIM are not initializing it after calling damos_new_filter(). As a result, accessing uninitialized memory is possible. Actually, adding multiple DAMOS filters via DAMON sysfs interface caused NULL pointer dereferencing. Initialize the field just after the allocation from
ilters via DAMON sysfs interface caused NULL pointer dereferencing. Initialize the field just after the allocation from damos_new_filter(). References: - https://git.kernel.org/stable/c/da7beebb49c643cd03c54447ed66595936a7a1ce - https://git.kernel.org/stable/c/5f1fc67f2cb8d3035d3acd273b48b97835af8afd
CVE ID: CVE-2023-53556 State: PUBLISHED Published: 2025-10-04T15:17:01.238Z Last Updated: 2025-10-04T15:17:01.238Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iavf: Fix use-after-free in free_netdev We do netif_napi_add() for all allocated q_vectors[], but potentially do netif_napi_del() for part of them, then kfree q_vectors and leave invalid pointers at dev->napi_list. Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf="0000:41:00.0" vf0_dbsf="0000:41:02.0" g_pids=() function do_set_numvf() { echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_nu
o 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combined 1 ethtool -L $nic combined 4 sleep $((RANDOM%3)) } function on_exit() { local pid for pid in "${g_pids[@]}"; do kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null done g_pids=() } trap "on_exit; exit" EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+
) } trap "on_exit; exit" EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+=($!) wait Result: [ 4093.900222] ================================================================== [ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390 [ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699 [ 4093.900233] [ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1 [ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021 [ 4093.900239] Call Trace: [ 4093.900244] dump_stack+0x71/0xab [ 4093.900249] print_address_description+0x6b/0x290 [ 4093.900251] ? free
all Trace: [ 4093.900244] dump_stack+0x71/0xab [ 4093.900249] print_address_description+0x6b/0x290 [ 4093.900251] ? free_netdev+0x308/0x390 [ 4093.900252] kasan_report+0x14a/0x2b0 [ 4093.900254] free_netdev+0x308/0x390 [ 4093.900261] iavf_remove+0x825/0xd20 [iavf] [ 4093.900265] pci_device_remove+0xa8/0x1f0 [ 4093.900268] device_release_driver_internal+0x1c6/0x460 [ 4093.900271] pci_stop_bus_device+0x101/0x150 [ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20 [ 4093.900275] pci_iov_remove_virtfn+0x187/0x420 [ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10 [ 4093.900278] ? pci_get_subsys+0x90/0x90 [ 4093.900280] sriov_disable+0xed/0x3e0 [ 4093.900282] ? bus_find_device+0x12d/0x1a0 [ 4093.
? pci_get_subsys+0x90/0x90 [ 4093.900280] sriov_disable+0xed/0x3e0 [ 4093.900282] ? bus_find_device+0x12d/0x1a0 [ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e] [ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e] [ 4093.900299] ? pci_get_device+0x7c/0x90 [ 4093.900300] ? pci_get_subsys+0x90/0x90 [ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210 [ 4093.900309] ? __mutex_lock_slowpath+0x10/0x10 [ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e] [ 4093.900318] sriov_numvfs_store+0x214/0x290 [ 4093.900320] ? sriov_totalvfs_show+0x30/0x30 [ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10 [ 4093.900323] ? __check_object_size+0x15a/0x350 [ 4093.900326] kernfs_fop_write+0x280/0x3f0 [ 4
lock_slowpath+0x10/0x10 [ 4093.900323] ? __check_object_size+0x15a/0x350 [ 4093.900326] kernfs_fop_write+0x280/0x3f0 [ 4093.900329] vfs_write+0x145/0x440 [ 4093.900330] ksys_write+0xab/0x160 [ 4093.900332] ? __ia32_sys_read+0xb0/0xb0 [ 4093.900334] ? fput_many+0x1a/0x120 [ 4093.900335] ? filp_close+0xf0/0x130 [ 4093.900338] do_syscall_64+0xa0/0x370 [ 4093.900339] ? page_fault+0x8/0x30 [ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 4093.900357] RIP: 0033:0x7f16ad4d22c0 [ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24 [
00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24 [ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0 [ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001 [ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700 [ 4093.9003 ---truncated--- References: - https://git.kernel.org/stable/c/17046107ca15d7571551539d94e76aba2bf71fd3 - https://git.kernel.org/stable/c/a4635f190f332304db4a49e827ece790b804b5db - https://git.kernel.org/stable/c/345c44e18cc10cded85cb9134830
nel.org/stable/c/a4635f190f332304db4a49e827ece790b804b5db - https://git.kernel.org/stable/c/345c44e18cc10cded85cb9134830e1684495c866 - https://git.kernel.org/stable/c/ca12b98e04b5d1902ac08fe826d3500cb4b6e891 - https://git.kernel.org/stable/c/8d781a9c53034813c3194b7d94409c7d24ac73eb - https://git.kernel.org/stable/c/5f4fa1672d98fe99d2297b03add35346f1685d6b
CVE ID: CVE-2023-53557 State: PUBLISHED Published: 2025-10-04T15:17:02.077Z Last Updated: 2025-10-04T15:17:02.077Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fprobe: Release rethook after the ftrace_ops is unregistered While running bpf selftests it's possible to get following fault: general protection fault, probably for non-canonical address \ 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI ... Call Trace: <TASK> fprobe_handler+0xc1/0x270 ? __pfx_bpf_testmod_init+0x10/0x10 ? __pfx_bpf_testmod_init+0x10/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_testmod_init+0x22/0x80 ? do_one_initca
tmod_init+0x10/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_fentry_test1+0x5/0x10 ? bpf_testmod_init+0x22/0x80 ? do_one_initcall+0x63/0x2e0 ? rcu_is_watching+0xd/0x40 ? kmalloc_trace+0xaf/0xc0 ? do_init_module+0x60/0x250 ? __do_sys_finit_module+0xac/0x120 ? do_syscall_64+0x37/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc </TASK> In unregister_fprobe function we can't release fp->rethook while it's possible there are some of its users still running on another cpu. Moving rethook_free call after fp->ops is unregistered with unregister_ftrace_function call. References: - https://git.kernel.org/stable/c/ce3ec57faff559ccae1e0150c1f077eb2df648a4 - https://git.kernel.org/stable/c/03d63255a5783243c110ae
it.kernel.org/stable/c/ce3ec57faff559ccae1e0150c1f077eb2df648a4 - https://git.kernel.org/stable/c/03d63255a5783243c110aec5e6ae2f1475c3be76 - https://git.kernel.org/stable/c/5f81018753dfd4989e33ece1f0cb6b8aae498b82