Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
g1, both bpf progs attach type is NONE or OVERRIDE. 2. write 1 to /proc/thread-self/fail-nth for failslab. 3. detach prog1 for cg1, and then kernel BUG occur. Failslab injection will cause kmalloc fail and fall back to purge_effective_progs. The problem is that cg2 have attached another prog, so when go through cg2 layer, iteration will add pos to 1, and subsequent operations will be skipped by the following condition, and cg will meet NULL in the end. `if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))` The NULL cg means no link or prog match, this is as expected, and it's not a bug. So here just skip the no match situation. References: - https://git.kernel.org/stable/c/c5f975e3ebfa57b
it's not a bug. So here just skip the no match situation. References: - https://git.kernel.org/stable/c/c5f975e3ebfa57be13393c585a4b58ea707023cb - https://git.kernel.org/stable/c/222bd95c89b135fde21f0bd0cb5cc1611c0c576c - https://git.kernel.org/stable/c/a1a05d3ae58299b040da4d5b27e72e81c2132e0b - https://git.kernel.org/stable/c/7d6620f107bae6ed687ff07668e8e8f855487aa9
CVE ID: CVE-2022-49971 State: PUBLISHED Published: 2025-06-18T11:00:34.649Z Last Updated: 2025-06-19T13:10:42.688Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix a potential gpu_metrics_table memory leak Memory is allocated for gpu_metrics_table in smu_v13_0_4_init_smc_tables(), but not freed in smu_v13_0_4_fini_smc_tables(). This may cause memory leaks, fix it. References: - https://git.kernel.org/stable/c/4b25bdb54578f3b96ff055e5d27bc1cb82950e51 - https://git.kernel.org/stable/c/5afb76522a0af0513b6dc01f84128a73206b051b
CVE ID: CVE-2022-49972 State: PUBLISHED Published: 2025-06-18T11:00:35.382Z Last Updated: 2025-06-18T11:00:35.382Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xsk: Fix corrupted packets for XDP_SHARED_UMEM Fix an issue in XDP_SHARED_UMEM mode together with aligned mode where packets are corrupted for the second and any further sockets bound to the same umem. In other words, this does not affect the first socket bound to the umem. The culprit for this bug is that the initialization of the DMA addresses for the pre-populated xsk buffer pool entries was not performed for any socket but the first one bound to the umem. Only the
he pre-populated xsk buffer pool entries was not performed for any socket but the first one bound to the umem. Only the linear array of DMA addresses was populated. Fix this by populating the DMA addresses in the xsk buffer pool for every socket bound to the same umem. References: - https://git.kernel.org/stable/c/2c75891d56ab6fe5ba0d415bfad91d514a4027cd - https://git.kernel.org/stable/c/58ca14ed98c87cfe0d1408cc65a9745d9e9b7a56
CVE ID: CVE-2022-49973 State: PUBLISHED Published: 2025-06-18T11:00:36.303Z Last Updated: 2025-06-18T11:00:36.303Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: skmsg: Fix wrong last sg check in sk_msg_recvmsg() Fix one kernel NULL pointer dereference as below: [ 224.462334] Call Trace: [ 224.462394] __tcp_bpf_recvmsg+0xd3/0x380 [ 224.462441] ? sock_has_perm+0x78/0xa0 [ 224.462463] tcp_bpf_recvmsg+0x12e/0x220 [ 224.462494] inet_recvmsg+0x5b/0xd0 [ 224.462534] __sys_recvfrom+0xc8/0x130 [ 224.462574] ? syscall_trace_enter+0x1df/0x2e0 [ 224.462606] ? __do_page_fault+0x2de/0x500 [ 224.462635] __x64_sys_recvfrom+0x24/0x30 [ 224.462
trace_enter+0x1df/0x2e0 [ 224.462606] ? __do_page_fault+0x2de/0x500 [ 224.462635] __x64_sys_recvfrom+0x24/0x30 [ 224.462660] do_syscall_64+0x5d/0x1d0 [ 224.462709] entry_SYSCALL_64_after_hwframe+0x65/0xca In commit 9974d37ea75f ("skmsg: Fix invalid last sg check in sk_msg_recvmsg()"), we change last sg check to sg_is_last(), but in sockmap redirection case (without stream_parser/stream_verdict/ skb_verdict), we did not mark the end of the scatterlist. Check the sk_msg_alloc, sk_msg_page_add, and bpf_msg_push_data functions, they all do not mark the end of sg. They are expected to use sg.end for end judgment. So the judgment of '(i != msg_rx->sg.end)' is added back here. References: - https:/
ted to use sg.end for end judgment. So the judgment of '(i != msg_rx->sg.end)' is added back here. References: - https://git.kernel.org/stable/c/de22cba333d8699ad77e79f862fe1320cb1284de - https://git.kernel.org/stable/c/10ee118a1756141f8e9c87aa7344ed12b41630a8 - https://git.kernel.org/stable/c/583585e48d965338e73e1eb383768d16e0922d73
CVE ID: CVE-2022-49974 State: PUBLISHED Published: 2025-06-18T11:00:37.224Z Last Updated: 2025-06-19T13:10:44.005Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: nintendo: fix rumble worker null pointer deref We can dereference a null pointer trying to queue work to a destroyed workqueue. If the device is disconnected, nintendo_hid_remove is called, in which the rumble_queue is destroyed. Avoid using that queue to defer rumble work once the controller state is set to JOYCON_CTLR_STATE_REMOVED. This eliminates the null pointer dereference. References: - https://git.kernel.org/stable/c/7c6e6c334154be16740b44dcd7638fb510b9bd9
ates the null pointer dereference. References: - https://git.kernel.org/stable/c/7c6e6c334154be16740b44dcd7638fb510b9bd91 - https://git.kernel.org/stable/c/1ff89e06c2e5fab30274e4b02360d4241d6e605e
CVE ID: CVE-2022-49975 State: PUBLISHED Published: 2025-06-18T11:00:38.157Z Last Updated: 2025-06-18T11:00:38.157Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Don't redirect packets with invalid pkt_len Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any skbs, that is, the flow->head is null. The root cause, as the [2] says, is because that bpf_prog_test_run_skb() run a bpf prog which redirects empty skbs. So we should determine whether the length of the packet modified by bpf prog or others like bpf_prog_test is valid before forwarding it directly. References: - https://git.kernel.org/stable/c/8b6
g or others like bpf_prog_test is valid before forwarding it directly. References: - https://git.kernel.org/stable/c/8b68e53d56697a59b5c53893b53f508bbdf272a0 - https://git.kernel.org/stable/c/6204bf78b2a903b96ba43afff6abc0b04d6e0462 - https://git.kernel.org/stable/c/a75987714bd2d8e59840667a28e15c1fa5c47554 - https://git.kernel.org/stable/c/72f2dc8993f10262092745a88cb2dd0fef094f23 - https://git.kernel.org/stable/c/fd1894224407c484f652ad456e1ce423e89bb3eb
CVE ID: CVE-2022-49976 State: PUBLISHED Published: 2025-06-18T11:00:38.959Z Last Updated: 2025-06-18T11:00:38.959Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix broken touchscreen on Chuwi Hi8 with Windows BIOS The x86-android-tablets handling for the Chuwi Hi8 is only necessary with the Android BIOS and it is causing problems with the Windows BIOS version. Specifically when trying to register the already present touchscreen x86_acpi_irq_helper_get() calls acpi_unregister_gsi(), this breaks the working of the touchscreen and also leads to an oops: [ 14.248946] ------------[ cut here ]----
r_gsi(), this breaks the working of the touchscreen and also leads to an oops: [ 14.248946] ------------[ cut here ]------------ [ 14.248954] remove_proc_entry: removing non-empty directory 'irq/75', leaking at least 'MSSL0001:00' [ 14.248983] WARNING: CPU: 3 PID: 440 at fs/proc/generic.c:718 remove_proc_entry ... [ 14.249293] unregister_irq_proc+0xe0/0x100 [ 14.249305] free_desc+0x29/0x70 [ 14.249312] irq_free_descs+0x4b/0x80 [ 14.249320] mp_unmap_irq+0x5c/0x60 [ 14.249329] acpi_unregister_gsi_ioapic+0x2a/0x40 [ 14.249338] x86_acpi_irq_helper_get+0x4b/0x190 [x86_android_tablets] [ 14.249355] x86_android_tablet_init+0x178/0xe34 [x86_android_tablets] Add an init callback for the Chuwi Hi8, wh
blets] [ 14.249355] x86_android_tablet_init+0x178/0xe34 [x86_android_tablets] Add an init callback for the Chuwi Hi8, which detects when the Windows BIOS is in use and exits with -ENODEV in that case, fixing this. References: - https://git.kernel.org/stable/c/c77b724cddfb8ac1291a60e3e68937e62cbfc5e0 - https://git.kernel.org/stable/c/2986c51540ed50ac654ffb5a772e546c02628c91
CVE ID: CVE-2022-49977 State: PUBLISHED Published: 2025-06-18T11:00:39.871Z Last Updated: 2025-06-18T11:00:39.871Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead ftrace_startup does not remove ops from ftrace_ops_list when ftrace_startup_enable fails: register_ftrace_function ftrace_startup __register_ftrace_function ... add_ftrace_ops(&ftrace_ops_list, ops) ... ... ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1 ... return 0 // ops is in the ftrace_ops_list. When ftrace_disabled = 1, unregister_ftrace_function simp
led is set to 1 ... return 0 // ops is in the ftrace_ops_list. When ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything: unregister_ftrace_function ftrace_shutdown if (unlikely(ftrace_disabled)) return -ENODEV; // return here, __unregister_ftrace_function is not executed, // as a result, ops is still in the ftrace_ops_list __unregister_ftrace_function ... If ops is dynamically allocated, it will be free later, in this case, is_ftrace_trampoline accesses NULL pointer: is_ftrace_trampoline ftrace_ops_trampoline do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL! Syzkaller reports as follows: [ 1203.506103] BUG: kernel NULL pointer dereference,
e_ops_list) // OOPS! op may be NULL! Syzkaller reports as follows: [ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b [ 1203.508039] #PF: supervisor read access in kernel mode [ 1203.508798] #PF: error_code(0x0000) - not-present page [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0 [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W 5.10.0 #8 [ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89
rg 04/01/2014 [ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00 [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246 [ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866 [ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399 [ 1203.524596] R13: 000000000000
f18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399 [ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008 [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000 [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0 [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Therefore, when ftrace_startup_enable fails, we need to rollback registration process and remove ops from ftrace_ops_list. References
en ftrace_startup_enable fails, we need to rollback registration process and remove ops from ftrace_ops_list. References: - https://git.kernel.org/stable/c/8569b4ada1e0b9bfaa125bd0c0967918b6560fa2 - https://git.kernel.org/stable/c/4c34a2a6c9927c239dd2e295a03d49b37b618d2c - https://git.kernel.org/stable/c/ddffe882d74ef43a3494f0ab0c24baf076c45f96 - https://git.kernel.org/stable/c/934e49f7d696afdae9f979abe3f308408184e17b - https://git.kernel.org/stable/c/dbd8c8fc60480e3faa3ae7e27ebe03371ecd1b77 - https://git.kernel.org/stable/c/e4ae97295984ff1b9b340ed18ae1b066f36b7835 - https://git.kernel.org/stable/c/d81bd6671f45fde4c3ac7fd7733c6e3082ae9d8e - https://git.kernel.org/stable/c/c3b0f72e805f0801f05
//git.kernel.org/stable/c/d81bd6671f45fde4c3ac7fd7733c6e3082ae9d8e - https://git.kernel.org/stable/c/c3b0f72e805f0801f05fa2aa52011c4bfc694c44
CVE ID: CVE-2022-49978 State: PUBLISHED Published: 2025-06-18T11:00:40.693Z Last Updated: 2025-06-18T11:00:40.693Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fbdev: fb_pm2fb: Avoid potential divide by zero error In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be copied from user, then go through `fb_set_var()` and `info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`. Along the path, `var->pixclock` won't be modified. This function checks whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is zero, there will be a divide by zero error. So, it is necessary to check whet
xclock` is too high. If `var->pixclock` is zero, there will be a divide by zero error. So, it is necessary to check whether denominator is zero to avoid crash. As this bug is found by Syzkaller, logs are listed below. divide error in pm2fb_check_var Call Trace: <TASK> fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 References: - https://git.kernel.org/stable/c/0f1174f4972ea9fad6becf8881d71adca8e9ca91 - https://git.kernel.org/stable/c/3ec326a6a0d4667585ca595f438c7293e5ced7c4 - https://git.kernel.org/stable/c/7f88cdfea8d7f4dbaf423d808241403b2bb945e4 - https://git
0d4667585ca595f438c7293e5ced7c4 - https://git.kernel.org/stable/c/7f88cdfea8d7f4dbaf423d808241403b2bb945e4 - https://git.kernel.org/stable/c/7d9591b32a9092fc6391a316b56e8016c6181c3d - https://git.kernel.org/stable/c/8fc778ee2fb2853f7a3531fa7273349640d8e4e9 - https://git.kernel.org/stable/c/34c3dea1189525cd533071ed5c176fc4ea8d982b - https://git.kernel.org/stable/c/cb4bb011a683532841344ca7f281b5e04389b4f8 - https://git.kernel.org/stable/c/19f953e7435644b81332dd632ba1b2d80b1e37af
CVE ID: CVE-2022-49979 State: PUBLISHED Published: 2025-06-18T11:00:41.513Z Last Updated: 2025-06-18T11:00:41.513Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: fix refcount bug in sk_psock_get (2) Syzkaller reports refcount bug as follows: ------------[ cut here ]------------ refcount_t: saturated; leaking memory. WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19 Modules linked in: CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0 <TASK> __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/li
g7e062cda7d90 #0 <TASK> __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/i
lease_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> During SMC fallback process in connect syscall, kernel will replaces TCP with SMC. In order to forward wakeup smc socket waitqueue after
ack process in connect syscall, kernel will replaces TCP with SMC. In order to forward wakeup smc socket waitqueue after fallback, kernel will sets clcsk->sk_user_data to origin smc socket in smc_fback_replace_callbacks(). Later, in shutdown syscall, kernel will calls sk_psock_get(), which treats the clcsk->sk_user_data as psock type, triggering the refcnt warning. So, the root cause is that smc and psock, both will use sk_user_data field. So they will mismatch this field easily. This patch solves it by using another bit(defined as SK_USER_DATA_PSOCK) in PTRMASK, to mark whether sk_user_data points to a psock object or not. This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e ("
ether sk_user_data points to a psock object or not. This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e ("net, sk_msg: Clear sk_user_data pointer on clone if tagged"). For there will possibly be more flags in the sk_user_data field, this patch also refactor sk_user_data flags code to be more generic to improve its maintainability. References: - https://git.kernel.org/stable/c/61cc798591a36ca27eb7d8d6c09bf20e50a59968 - https://git.kernel.org/stable/c/a5d1cb908131e939bd8b63b8e5e23365bbc2edaf - https://git.kernel.org/stable/c/86026be8535c16fcc5e4f960286faf04d7f77815 - https://git.kernel.org/stable/c/2a0133723f9ebeb751cfce19f74ec07e108bef1f
CVE ID: CVE-2022-49980 State: PUBLISHED Published: 2025-06-18T11:00:42.433Z Last Updated: 2025-06-18T11:00:42.433Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: USB: gadget: Fix use-after-free Read in usb_udc_uevent() The syzbot fuzzer found a race between uevent callbacks and gadget driver unregistration that can cause a use-after-free bug: --------------------------------------------------------------- BUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 Read of size 8 at addr ffff888078ce2050 by task udevd/2968 CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller
at addr ffff888078ce2050 by task udevd/2968 CPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/29/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495 usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732 dev_uevent+0x290/0x770 drivers/base/core.c:2424 --------------------------------------------------------------- The bug occurs because usb_udc_uevent() dereferen
c:2424 --------------------------------------------------------------- The bug occurs because usb_udc_uevent() dereferences udc->driver but does so without acquiring the udc_lock mutex, which protects this field. If the gadget driver is unbound from the udc concurrently with uevent processing, the driver structure may be accessed after it has been deallocated. To prevent the race, we make sure that the routine holds the mutex around the racing accesses. References: - https://git.kernel.org/stable/c/f44b0b95d50fffeca036e1ba36770390e0b519dd - https://git.kernel.org/stable/c/2191c00855b03aa59c20e698be713d952d51fc18
CVE ID: CVE-2022-49981 State: PUBLISHED Published: 2025-06-18T11:00:43.351Z Last Updated: 2025-07-15T15:43:41.866Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: hidraw: fix memory leak in hidraw_release() Free the buffered reports before deleting the list entry. BUG: memory leak unreferenced object 0xffff88810e72f180 (size 32): comm "softirq", pid 0, jiffies 4294945143 (age 16.080s) hex dump (first 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128 [<ffffffff8357c1d2>] k
0 00 00 00 00 00 ................ backtrace: [<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128 [<ffffffff8357c1d2>] kmemdup include/linux/fortify-string.h:440 [inline] [<ffffffff8357c1d2>] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.c:521 [<ffffffff8356ddad>] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-core.c:1992 [<ffffffff8356e41e>] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.c:2065 [<ffffffff835f0d3f>] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284 [<ffffffff82d3c7f9>] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core/hcd.c:1670 [<ffffffff82d3cc26>] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [<ffffffff82ef1e14>] dummy_timer+0x8e4/0x14c0 dri
2d3cc26>] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [<ffffffff82ef1e14>] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummy_hcd.c:1988 [<ffffffff812f50a8>] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [<ffffffff812f5586>] expire_timers kernel/time/timer.c:1519 [inline] [<ffffffff812f5586>] __run_timers.part.0+0x316/0x430 kernel/time/timer.c:1790 [<ffffffff812f56e4>] __run_timers kernel/time/timer.c:1768 [inline] [<ffffffff812f56e4>] run_timer_softirq+0x44/0x90 kernel/time/timer.c:1803 [<ffffffff848000e6>] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [<ffffffff81246db0>] invoke_softirq kernel/softirq.c:445 [inline] [<ffffffff81246db0>] __irq_exit_rcu kernel/softirq.
71 [<ffffffff81246db0>] invoke_softirq kernel/softirq.c:445 [inline] [<ffffffff81246db0>] __irq_exit_rcu kernel/softirq.c:650 [inline] [<ffffffff81246db0>] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [<ffffffff84574f02>] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106 [<ffffffff84600c8b>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649 [<ffffffff8458a070>] native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline] [<ffffffff8458a070>] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline] [<ffffffff8458a070>] acpi_safe_halt drivers/acpi/processor_idle.c:111 [inline] [<ffffffff8458a070>] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/proc
safe_halt drivers/acpi/processor_idle.c:111 [inline] [<ffffffff8458a070>] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processor_idle.c:554 References: - https://git.kernel.org/stable/c/1bea0bbf66001b0c7bf239a4d70eaf47824d3feb - https://git.kernel.org/stable/c/c06b013f5cbfeafe0a9cfa5a7128604c34e0e517 - https://git.kernel.org/stable/c/f5b7e9611cffec345d62d5bdd8b6e30e89956818 - https://git.kernel.org/stable/c/53c7c4d5d40b45c127cb1193bf3e9670f844c3cf - https://git.kernel.org/stable/c/7e2fa79226580b035b00260d9f240ab9bda4af5d - https://git.kernel.org/stable/c/dfd27a737283313a3e626e97b9d9b2d8d6a94188 - https://git.kernel.org/stable/c/52a3c62a815161c2dcf38ac421f6c41d8679462b - https://git.kernel.org/s
97b9d9b2d8d6a94188 - https://git.kernel.org/stable/c/52a3c62a815161c2dcf38ac421f6c41d8679462b - https://git.kernel.org/stable/c/a5623a203cffe2d2b84d2f6c989d9017db1856af