Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
7 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205 #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540dd1 i
ltin-trace.c:3205 #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s). [root@quaco ~]# With this we plug all leaks
.6+0x2750f) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s). [root@quaco ~]# With this we plug all leaks with "perf trace sleep 1". References: - https://git.kernel.org/stable/c/c3bc668581e71e7c3bc7eb1d647f25f8db222163 - https://git.kernel.org/stable/c/62dd514c34be63d3d5cae1f52a7e8b96c6dd6630 - https://git.kernel.org/stable/c/27f396f64537b1ae48d0644d7cbf0d250b3c0b33 - https://git.kernel.org/stable/c/7962ef13651a9163f07b530607392ea123482e8a
CVE ID: CVE-2023-53650 State: PUBLISHED Published: 2025-10-07T15:19:47.118Z Last Updated: 2025-10-07T15:19:47.118Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe() If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak. References: - https://git.kernel.org/stable/c/d97840bf5a388c6cbf6e46216887bf17be62acc2 - https://git.kernel.org/stable/c/7a8f9293bee51183023c5e37e7ebf0543cd2a134 - https://git.kernel.org/stable/c/9e3858f82e3ced1e990ef7116c3a16c84e62093e - https://git.kernel.org/stable/c/ce6e0434e502abdf966164b7c72523fb5fe54635 - https://git.kern
1e990ef7116c3a16c84e62093e - https://git.kernel.org/stable/c/ce6e0434e502abdf966164b7c72523fb5fe54635 - https://git.kernel.org/stable/c/716efd08985e3104031d1b655930b1f1c45fa8a7 - https://git.kernel.org/stable/c/3b4c21804076e461a6453ee4d09872172336aa1d - https://git.kernel.org/stable/c/7cca0af3167dd9603da5fa6fff3392f8338e97e1 - https://git.kernel.org/stable/c/09ea1ae4a2ec17774892cfcff50f6d33dfa1e06f - https://git.kernel.org/stable/c/79a3908d1ea6c35157a6d907b1a9d8ec06015e7a
CVE ID: CVE-2023-53651 State: PUBLISHED Published: 2025-10-07T15:19:47.832Z Last Updated: 2025-10-07T15:19:47.832Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Input: exc3000 - properly stop timer on shutdown We need to stop the timer on driver unbind or probe failures, otherwise we get UAF/Oops. References: - https://git.kernel.org/stable/c/526a177ac6353d65057eadb5d6edafc168f64484 - https://git.kernel.org/stable/c/bee57c20fc0ca5ef9b9a53a0335eab2ac9e9cae1 - https://git.kernel.org/stable/c/79c81d137d36f9635bbcbc3916c0cccb418a61dd
CVE ID: CVE-2023-53652 State: PUBLISHED Published: 2025-10-07T15:19:48.628Z Last Updated: 2025-10-07T15:19:48.628Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vdpa: Add features attr to vdpa_nl_policy for nlattr length check The vdpa_nl_policy structure is used to validate the nlattr when parsing the incoming nlmsg. It will ensure the attribute being described produces a valid nlattr pointer in info->attrs before entering into each handler in vdpa_nl_ops. That is to say, the missing part in vdpa_nl_policy may lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missi
ay lead to illegal nlattr after parsing, which could lead to OOB read just like CVE-2023-3773. This patch adds the missing nla_policy for vdpa features attr to avoid such bugs. References: - https://git.kernel.org/stable/c/44b508cc96889e61799cc0fc6c00766a54f3ab5a - https://git.kernel.org/stable/c/645d17e06c502e71b880b2b854930e5a64014640 - https://git.kernel.org/stable/c/79c8651587504ba263d2fd67fd4406240fb21f69
CVE ID: CVE-2023-53653 State: PUBLISHED Published: 2025-10-07T15:19:49.303Z Last Updated: 2025-10-07T15:19:49.303Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: amphion: fix REVERSE_INULL issues reported by coverity null-checking of a pointor is suggested before dereferencing it References: - https://git.kernel.org/stable/c/bddd678fd2864b435d00d51a4d3808a0d89c79de - https://git.kernel.org/stable/c/e59d0cd8f414592187ead97b5832600ff7a0dd61 - https://git.kernel.org/stable/c/ef56b2db216f130c4240aed907d1c5272c2d298d - https://git.kernel.org/stable/c/79d3bafaecc13bccab1ebbd28a15e669c5a4cdaf
CVE ID: CVE-2023-53654 State: PUBLISHED Published: 2025-10-07T15:19:49.985Z Last Updated: 2025-10-07T15:19:49.985Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Add validation before accessing cgx and lmac with the addition of new MAC blocks like CN10K RPM and CN10KB RPM_USX, LMACs are noncontiguous and CGX blocks are also noncontiguous. But during RVU driver initialization, the driver is assuming they are contiguous and trying to access cgx or lmac with their id which is resulting in kernel panic. This patch fixes the issue by adding proper checks. [ 23.219150] pc : cgx_lmac_read+0x38/0x70 [ 23.219154] lr : rvu_
ic. This patch fixes the issue by adding proper checks. [ 23.219150] pc : cgx_lmac_read+0x38/0x70 [ 23.219154] lr : rvu_program_channels+0x3f0/0x498 [ 23.223852] sp : ffff000100d6fc80 [ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27: 000000000000005a [ 23.234288] x26: ffff000102586768 x25: 0000000000002500 x24: fffffffffff0f000 References: - https://git.kernel.org/stable/c/e425e2ba933618ee5ec8e4f3eb341efeb6c9ddef - https://git.kernel.org/stable/c/a5485a943193e55c79150382e6461e8ea759e96e - https://git.kernel.org/stable/c/b04872e15f3df62cb2fd530950f769626e1ef489 - https://git.kernel.org/stable/c/79ebb53772c95d3a6ae51b3c65f9985fdd430df6
CVE ID: CVE-2023-53655 State: PUBLISHED Published: 2025-10-07T15:21:16.889Z Last Updated: 2025-10-07T15:21:16.889Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-ed Registering a kprobe on __rcu_irq_enter_check_tick() can cause kernel stack overflow as shown below. This issue can be reproduced by enabling CONFIG_NO_HZ_FULL and booting the kernel with argument "nohz_full=", and then giving the following commands at the shell prompt: # cd /sys/kernel/tracing/ # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events # echo 1 > events/kprobes/enable This c
/sys/kernel/tracing/ # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events # echo 1 > events/kprobes/enable This commit therefore adds __rcu_irq_enter_check_tick() to the kprobes blacklist using NOKPROBE_SYMBOL(). Insufficient stack space to handle exception! ESR: 0x00000000f2000004 -- BRK (AArch64) FAR: 0x0000ffffccf3e510 Task stack: [0xffff80000ad30000..0xffff80000ad38000] IRQ stack: [0xffff800008050000..0xffff800008058000] Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310] CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19 Hardware name: linux,dummy-virt (DT) pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __rcu_irq_enter_check_tick+0
linux,dummy-virt (DT) pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __rcu_irq_enter_check_tick+0x0/0x1b8 lr : ct_nmi_enter+0x11c/0x138 sp : ffff80000ad30080 x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000 x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000 x23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148 x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6c x14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809 x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000 x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 00000000
: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000 x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001 x5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4 x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000 Kernel panic - not syncing: kernel stack overflow CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0xf8/0x108 show_stack+0x20/0x30 dump_stack_lvl+0x68/0x84 dump_stack+0x1c/0x38 panic+0x214/0x404 add_taint+0x0/0xf8 panic_bad_stack+0x144/0x160 handle_bad_stack+0x38/0x58 __bad_stack+0x78/0x7c __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isr
x144/0x160 handle_bad_stack+0x38/0x58 __bad_stack+0x78/0x7c __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 [...] el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/
0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 el1_interrupt+0x28/0x60 el1h_64_irq_handler+0x18/0x28 el1h_64_irq+0x64/0x68 __ftrace_set_clr_event_nolock+0x98/0x198 __ftrace_set_clr_event+0x58/0x80 system_enable_write+0x144/0x178 vfs_write+0x174/0x738 ksys_write+0xd0/0x188 __arm64_sys_write+0x4c/0x60 invoke_syscall+0x64/0x180 el0_svc_common.constprop.0+0x84/0x160 do_el0_svc+0x48/0xe8
0/0x188 __arm64_sys_write+0x4c/0x60 invoke_syscall+0x64/0x180 el0_svc_common.constprop.0+0x84/0x160 do_el0_svc+0x48/0xe8 el0_svc+0x34/0xd0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x190/0x194 SMP: stopping secondary CPUs Kernel Offset: 0x28da86000000 from 0xffff800008000000 PHYS_OFFSET: 0xfffff76600000000 CPU features: 0x00000,01a00100,0000421b Memory Limit: none References: - https://git.kernel.org/stable/c/eb18bc5a8678f431c500e6da1b8b5f34478d5bc1 - https://git.kernel.org/stable/c/4c3d1a6720aefb02403ddfebe85db521d3af2c3b - https://git.kernel.org/stable/c/c8a3341b339285495cf7c8d061d659465f2311e0 - https://git.kernel.org/stable/c/93b6295f677d96b73cfcb703532f6c7369a60d96 - https://git.kerne
95cf7c8d061d659465f2311e0 - https://git.kernel.org/stable/c/93b6295f677d96b73cfcb703532f6c7369a60d96 - https://git.kernel.org/stable/c/7b5a97333e920b69356e097f185bdc51d61e66ee - https://git.kernel.org/stable/c/7a29fb4a4771124bc61de397dbfc1554dbbcc19c
CVE ID: CVE-2023-53656 State: PUBLISHED Published: 2025-10-07T15:21:17.572Z Last Updated: 2025-10-07T15:21:17.572Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drivers/perf: hisi: Don't migrate perf to the CPU going to teardown The driver needs to migrate the perf context if the current using CPU going to teardown. By the time calling the cpuhp::teardown() callback the cpu_online_mask() hasn't updated yet and still includes the CPU going to teardown. In current driver's implementation we may migrate the context to the teardown CPU and leads to the below calltrace: ... [ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15
ext to the teardown CPU and leads to the below calltrace: ... [ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008 [ 368.113699][ T932] Call trace: [ 368.116834][ T932] __switch_to+0x7c/0xbc [ 368.120924][ T932] __schedule+0x338/0x6f0 [ 368.125098][ T932] schedule+0x50/0xe0 [ 368.128926][ T932] schedule_preempt_disabled+0x18/0x24 [ 368.134229][ T932] __mutex_lock.constprop.0+0x1d4/0x5dc [ 368.139617][ T932] __mutex_lock_slowpath+0x1c/0x30 [ 368.144573][ T932] mutex_lock+0x50/0x60 [ 368.148579][ T932] perf_pmu_migrate_context+0x84/0x2b0 [ 368.153884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu] [ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650
53884][ T932] hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu] [ 368.160579][ T932] cpuhp_invoke_callback+0x2a0/0x650 [ 368.165707][ T932] cpuhp_thread_fun+0xe4/0x190 [ 368.170316][ T932] smpboot_thread_fn+0x15c/0x1a0 [ 368.175099][ T932] kthread+0x108/0x13c [ 368.179012][ T932] ret_from_fork+0x10/0x18 ... Use function cpumask_any_but() to find one correct active cpu to fixes this issue. References: - https://git.kernel.org/stable/c/be9c8c9c84b6d25a7b7d39954030aba6f759feb6 - https://git.kernel.org/stable/c/f564e543a43d0f1cabac791672c8a6fc78ce12d0 - https://git.kernel.org/stable/c/b64569897d86b611befbb895d815280fea94e1ed - https://git.kernel.org/stable/c/7a6a9f1c5a0a875a421db798d4b2ee022dc
/stable/c/b64569897d86b611befbb895d815280fea94e1ed - https://git.kernel.org/stable/c/7a6a9f1c5a0a875a421db798d4b2ee022dc1ee1a
CVE ID: CVE-2023-53657 State: PUBLISHED Published: 2025-10-07T15:21:18.268Z Last Updated: 2025-10-29T10:50:40.984Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: Don't tx before switchdev is fully configured There is possibility that ice_eswitch_port_start_xmit might be called while some resources are still not allocated which might cause NULL pointer dereference. Fix this by checking if switchdev configuration was finished. References: - https://git.kernel.org/stable/c/5760a72b3060150b587eff3e879648c7470efddd - https://git.kernel.org/stable/c/63ff5a94649837d980e3b9ef535c793ec8cb0ca7 - https://git.kernel.org/stable/c/7aa52
efddd - https://git.kernel.org/stable/c/63ff5a94649837d980e3b9ef535c793ec8cb0ca7 - https://git.kernel.org/stable/c/7aa529a69e92b9aff585e569d5003f7c15d8d60b
CVE ID: CVE-2023-53658 State: PUBLISHED Published: 2025-10-07T15:21:18.950Z Last Updated: 2025-10-07T15:21:18.950Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: spi: bcm-qspi: return error if neither hif_mspi nor mspi is available If neither a "hif_mspi" nor "mspi" resource is present, the driver will just early exit in probe but still return success. Apart from not doing anything meaningful, this would then also lead to a null pointer access on removal, as platform_get_drvdata() would return NULL, which it would then try to dereference when trying to unregister the spi master. Fix this by unconditionally calling devm_ioremap_
ould then try to dereference when trying to unregister the spi master. Fix this by unconditionally calling devm_ioremap_resource(), as it can handle a NULL res and will then return a viable ERR_PTR() if we get one. The "return 0;" was previously a "goto qspi_resource_err;" where then ret was returned, but since ret was still initialized to 0 at this place this was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fix use-after-free on unbind"). The issue was not introduced by this commit, only made more obvious. References: - https://git.kernel.org/stable/c/a91c34357afcfaa5307e254f22a8452550a07b34 - https://git.kernel.org/stable/c/d20db3c58a7f9361e370a7850ceb60dbdf62eea3 - https://git.kern
a5307e254f22a8452550a07b34 - https://git.kernel.org/stable/c/d20db3c58a7f9361e370a7850ceb60dbdf62eea3 - https://git.kernel.org/stable/c/398e6a015877d44327f754aeb48ff3354945c78c - https://git.kernel.org/stable/c/32b9c8f7892c19f7f5c9fed5fb410b9fd5990bb6 - https://git.kernel.org/stable/c/217b6ea8cf7b819477bca597a6ae2d43d38ba283 - https://git.kernel.org/stable/c/d3dcdb43c872a3b967345144151a2c9bb9124c9b - https://git.kernel.org/stable/c/22ae32d80ef590d12a2364e4621f90f7c58445c7 - https://git.kernel.org/stable/c/7c1f23ad34fcdace50275a6aa1e1969b41c6233f
CVE ID: CVE-2023-53659 State: PUBLISHED Published: 2025-10-07T15:21:19.619Z Last Updated: 2025-10-07T15:21:19.619Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iavf: Fix out-of-bounds when setting channels on remove If we set channels greater during iavf_remove(), and waiting reset done would be timeout, then returned with error but changed num_active_queues directly, that will lead to OOB like the following logs. Because the num_active_queues is greater than tx/rx_rings[] allocated actually. 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() {
ot@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_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_pid
ion 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+=($!) wait Result: [ 3506.152887] iavf 0000:41:02.0: Removing device [ 3510.400799] ================================================================== [ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf] [ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536 [ 3510.400823] [ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1 [ 3510.400832] H
] [ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1 [ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021 [ 3510.400835] Call Trace: [ 3510.400851] dump_stack+0x71/0xab [ 3510.400860] print_address_description+0x6b/0x290 [ 3510.400865] ? iavf_free_all_tx_resources+0x156/0x160 [iavf] [ 3510.400868] kasan_report+0x14a/0x2b0 [ 3510.400873] iavf_free_all_tx_resources+0x156/0x160 [iavf] [ 3510.400880] iavf_remove+0x2b6/0xc70 [iavf] [ 3510.400884] ? iavf_free_all_rx_resources+0x160/0x160 [iavf] [ 3510.400891] ? wait_woken+0x1d0/0x1d0 [ 3510.400895] ? notifier_call_chain+0xc1/0x130 [ 3510.400903] pci_device_remove+0xa8/
.400891] ? wait_woken+0x1d0/0x1d0 [ 3510.400895] ? notifier_call_chain+0xc1/0x130 [ 3510.400903] pci_device_remove+0xa8/0x1f0 [ 3510.400910] device_release_driver_internal+0x1c6/0x460 [ 3510.400916] pci_stop_bus_device+0x101/0x150 [ 3510.400919] pci_stop_and_remove_bus_device+0xe/0x20 [ 3510.400924] pci_iov_remove_virtfn+0x187/0x420 [ 3510.400927] ? pci_iov_add_virtfn+0xe10/0xe10 [ 3510.400929] ? pci_get_subsys+0x90/0x90 [ 3510.400932] sriov_disable+0xed/0x3e0 [ 3510.400936] ? bus_find_device+0x12d/0x1a0 [ 3510.400953] i40e_free_vfs+0x754/0x1210 [i40e] [ 3510.400966] ? i40e_reset_all_vfs+0x880/0x880 [i40e] [ 3510.400968] ? pci_get_device+0x7c/0x90 [ 3510.400970] ? pci_get_subsys+0x90/0x90 [
_reset_all_vfs+0x880/0x880 [i40e] [ 3510.400968] ? pci_get_device+0x7c/0x90 [ 3510.400970] ? pci_get_subsys+0x90/0x90 [ 3510.400982] ? pci_vfs_assigned.part.7+0x144/0x210 [ 3510.400987] ? __mutex_lock_slowpath+0x10/0x10 [ 3510.400996] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e] [ 3510.401001] sriov_numvfs_store+0x214/0x290 [ 3510.401005] ? sriov_totalvfs_show+0x30/0x30 [ 3510.401007] ? __mutex_lock_slowpath+0x10/0x10 [ 3510.401011] ? __check_object_size+0x15a/0x350 [ 3510.401018] kernfs_fop_write+0x280/0x3f0 [ 3510.401022] vfs_write+0x145/0x440 [ 3510.401025] ksys_write+0xab/0x160 [ 3510.401028] ? __ia32_sys_read+0xb0/0xb0 [ 3510.401031] ? fput_many+0x1a/0x120 [ 3510.401032] ? filp_close+0xf
b/0x160 [ 3510.401028] ? __ia32_sys_read+0xb0/0xb0 [ 3510.401031] ? fput_many+0x1a/0x120 [ 3510.401032] ? filp_close+0xf0/0x130 [ 3510.401038] do_syscall_64+0xa0/0x370 [ 3510.401041] ? page_fault+0x8/0x30 [ 3510.401043] entry_SYSCALL_64_after_hwframe+0x65/0xca [ 3510.401073] RIP: 0033:0x7f3a9bb842c0 [ 3510.401079] 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 ---truncated--- References: - https://git.kernel.org/stable/c/b92defe4e8ee86996c16417ad8c804cb4395fddd - https://git.kernel.org/stable/c/0fb37ce6c01e17839e26d03222f0b44e6a3ed2b9 - https://git.kernel.org/stable/c/6e1d8f1332076a002e6d910d255aa590
org/stable/c/0fb37ce6c01e17839e26d03222f0b44e6a3ed2b9 - https://git.kernel.org/stable/c/6e1d8f1332076a002e6d910d255aa5903d341c56 - https://git.kernel.org/stable/c/65ecebc9ac09427b2c65f271cd5e5bd536c3fe38 - https://git.kernel.org/stable/c/7c4bced3caa749ce468b0c5de711c98476b23a52
CVE ID: CVE-2023-53660 State: PUBLISHED Published: 2025-10-07T15:21:20.307Z Last Updated: 2025-10-07T15:21:20.307Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, cpumap: Handle skb as well when clean up ptr_ring The following warning was reported when running xdp_redirect_cpu with both skb-mode and stress-mode enabled: ------------[ cut here ]------------ Incorrect XDP memory type (-2128176192) usage WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405 Modules linked in: CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events __cpu_map_entry_free RIP: 0
ted: G 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events __cpu_map_entry_free RIP: 0010:__xdp_return+0x1e4/0x4a0 ...... Call Trace: <TASK> ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ? __xdp_return+0x1e4/0x4a0 ...... xdp_return_frame+0x4d/0x150 __cpu_map_entry_free+0xf9/0x230 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> The reason for the warning is twofold. One is due to the kthread cpu_map_kthread_run() is stopped prematurely. Another one is __cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs in ptr_ring as XDP frames. Prematurely-stopped kthread will be f
_ring_cleanup() doesn't handle skb mode and treats skbs in ptr_ring as XDP frames. Prematurely-stopped kthread will be fixed by the preceding patch and ptr_ring will be empty when __cpu_map_ring_cleanup() is called. But as the comments in __cpu_map_ring_cleanup() said, handling and freeing skbs in ptr_ring as well to "catch any broken behaviour gracefully". References: - https://git.kernel.org/stable/c/b58d34068fd9f96bfc7d389988dfaf9a92a8fe00 - https://git.kernel.org/stable/c/cbd000451885801e9bbfd9cf7a7946806a85cb5e - https://git.kernel.org/stable/c/937345720d18f1ad006ba3d5dcb3fa121037b8a2 - https://git.kernel.org/stable/c/7c62b75cd1a792e14b037fa4f61f9b18914e7de1