Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
d.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x
mci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 ... Local variable ev created at: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100 Use mems
uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100 Use memset() to prevent the infoleaks. Also speculatively fix qp_notify_peer_local(), which may suffer from the same problem. References: - https://git.kernel.org/stable/c/7ccf7229b96fadc3a185d1391f814a604c7ef609 - https://git.kernel.org/stable/c/f04586c2315cfd03d72ad0395705435e7ed07b1a - https://git.kernel.org/stable/c/5a275528025ae4bc7e2232866856dfebf84b2fad - https://git.kernel.org/stable/c/e7061dd1fef2dfb6458cd521aef27aa66f510d31 - https://git.kernel.org/stable/c/62634b43d3c4e1bf62fd540196f7081bf0885c0a - https://git.kernel.org/stable/c/8e2f33c598370bcf828bab4d667d1d38bcd3c57d
e/c/62634b43d3c4e1bf62fd540196f7081bf0885c0a - https://git.kernel.org/stable/c/8e2f33c598370bcf828bab4d667d1d38bcd3c57d - https://git.kernel.org/stable/c/76c50d77b928a33e5290aaa9fdc10e88254ff8c7 - https://git.kernel.org/stable/c/e5b0d06d9b10f5f43101bd6598b076c347f9295f
CVE ID: CVE-2022-49789 State: PUBLISHED Published: 2025-05-01T14:09:21.481Z Last Updated: 2025-05-04T08:45:24.202Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: zfcp: Fix double free of FSF request when qdio send fails We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again). In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the
we free the request again). In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn't match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to '
as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to 'unsigned long'. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once we pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the request again all the leading zeros will be flipped to ones to extend the sign and won't match the original ID anymore (this has been observed in practice). If we can't successfully remove the request from the hash table again after 'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify
ove the request from the hash table again after 'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify the adapter about new work because the adapter is already gone during e.g. a ChpID toggle) we will end up with a double free. We unconditionally free the request in the calling function when 'zfcp_fsf_req_send()' fails, but because the request is still in the hash table we end up with a stale memory reference, and once the zfcp adapter is either reset during recovery or shutdown we end up freeing the same memory twice. The resulting stack traces vary depending on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have
nding on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have been seen in practice: list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001
AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,
3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] ---truncated--- References: - https://git.kernel.org/stable/c/1bf8ed585501bb2dd0b5f67c824eab45adfbdccd - https://git.kernel.org/stable/c/d2c7d8f58e9cde8ac8d1f75e9d66c2a813ffe0ab - https://git.kernel.org/stable/c/11edbdee4399401f533adda9bffe94567aa08b96 - https://git.kernel.org/stable/c/90a49a6b015fa439cd62e45121390284c
rg/stable/c/11edbdee4399401f533adda9bffe94567aa08b96 - https://git.kernel.org/stable/c/90a49a6b015fa439cd62e45121390284c125a91f - https://git.kernel.org/stable/c/0954256e970ecf371b03a6c9af2cf91b9c4085ff
CVE ID: CVE-2022-49790 State: PUBLISHED Published: 2025-05-01T14:09:22.158Z Last Updated: 2025-05-04T08:45:25.494Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Input: iforce - invert valid length check when fetching device IDs syzbot is reporting uninitialized value at iforce_init_device() [1], for commit 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer when fetching device IDs") is checking that valid length is shorter than bytes to read. Since iforce_get_id_packet() stores valid length when returning 0, the caller needs to check that valid length is longer than or equals to bytes to read. References: - https:
returning 0, the caller needs to check that valid length is longer than or equals to bytes to read. References: - https://git.kernel.org/stable/c/5d53797ce7ce8fb1d95a5bebc5efa9418c4217a3 - https://git.kernel.org/stable/c/24cc679abbf31477d0cc6106ec83c2fbae6b3cdf - https://git.kernel.org/stable/c/fdd57c20d4408cac3c3c535c120d244e083406c9 - https://git.kernel.org/stable/c/6365569d62a75ddf53fb0c2936c16587a365984c - https://git.kernel.org/stable/c/b8ebf250997c5fb253582f42bfe98673801ebebd
CVE ID: CVE-2022-49791 State: PUBLISHED Published: 2025-05-01T14:09:23.010Z Last Updated: 2025-05-04T08:45:26.853Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring: fix multishot accept request leaks Having REQ_F_POLLED set doesn't guarantee that the request is executed as a multishot from the polling path. Fortunately for us, if the code thinks it's multishot issue when it's not, it can only ask to skip completion so leaking the request. Use issue_flags to mark multipoll issues. References: - https://git.kernel.org/stable/c/0e4626de856ef8f25ecd9c716e76d4f95ce95639 - https://git.kernel.org/stable/c/91482864768a874c4290ef
it.kernel.org/stable/c/0e4626de856ef8f25ecd9c716e76d4f95ce95639 - https://git.kernel.org/stable/c/91482864768a874c4290ef93b84a78f4f1dac51b
CVE ID: CVE-2022-49792 State: PUBLISHED Published: 2025-05-01T14:09:23.655Z Last Updated: 2025-05-04T08:45:27.943Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: adc: mp2629: fix potential array out of bound access Add sentinel at end of maps to avoid potential array out of bound access in iio core. References: - https://git.kernel.org/stable/c/d95b85c5084ad70011988861ee864529eefa1da0 - https://git.kernel.org/stable/c/1678d4abb2dc2ca3b05b998a9d88616976e4f947 - https://git.kernel.org/stable/c/399b2105a2240e730b9f3880bd8f154247539aa7 - https://git.kernel.org/stable/c/ca1547ab15f48dc81624183ae17a2fd1bad06dfc
CVE ID: CVE-2022-49793 State: PUBLISHED Published: 2025-05-01T14:09:24.442Z Last Updated: 2025-05-04T08:45:29.276Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init() dev_set_name() allocates memory for name, it need be freed when device_add() fails, call put_device() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. Fault injection test can trigger this: unreferenced object 0xffff8e8340a7b4c0 (size 32): comm "modprobe", pid 243, jiffies 4294678145 (age 48.845s) hex dump (first 32 b
ced object 0xffff8e8340a7b4c0 (size 32): comm "modprobe", pid 243, jiffies 4294678145 (age 48.845s) hex dump (first 32 bytes): 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge 72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............ backtrace: [<0000000074999de8>] __kmem_cache_alloc_node+0x1e9/0x360 [<00000000497fd30b>] __kmalloc_node_track_caller+0x44/0x1a0 [<000000003636c520>] kstrdup+0x2d/0x60 [<0000000032f84da2>] kobject_set_name_vargs+0x1e/0x90 [<0000000092efe493>] dev_set_name+0x4e/0x70 References: - https://git.kernel.org/stable/c/f68c96821b61d2c71a35dbb8bf90c347fad624d9 - https://git.kernel.org/stable/c/5a39382aa5411d64b25a71516c2c7480aab13bb7 - https://git.ke
d2c71a35dbb8bf90c347fad624d9 - https://git.kernel.org/stable/c/5a39382aa5411d64b25a71516c2c7480aab13bb7 - https://git.kernel.org/stable/c/b47bb521961f027b4dcf8683337a7a1ba9e5ea1f - https://git.kernel.org/stable/c/0dd52e141afde089304de470148d311b05c14564 - https://git.kernel.org/stable/c/8dddf2699da296c84205582aaead6b43dd7e8c4b - https://git.kernel.org/stable/c/656f670613662b6cc77aad14112db2803ad18fa8 - https://git.kernel.org/stable/c/2c4e65285bdea23fd36d2ff376006ac64db6f42e - https://git.kernel.org/stable/c/efa17e90e1711bdb084e3954fa44afb6647331c0
CVE ID: CVE-2022-49794 State: PUBLISHED Published: 2025-05-01T14:09:25.124Z Last Updated: 2025-05-04T08:45:30.350Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger() If iio_trigger_register() returns error, it should call iio_trigger_free() to give up the reference that hold in iio_trigger_alloc(), so that it can call iio_trig_release() to free memory when the refcount hit to 0. References: - https://git.kernel.org/stable/c/c3ce73f60599a483dca7becd4112508833a40ef9 - https://git.kernel.org/stable/c/a0d98ae5a62a7bbad8fcf9fa22e0a1274197bbc4 - https://git.kerne
3dca7becd4112508833a40ef9 - https://git.kernel.org/stable/c/a0d98ae5a62a7bbad8fcf9fa22e0a1274197bbc4 - https://git.kernel.org/stable/c/2b29a7f2d52fb5281b30cf61c947d88bab18a29b - https://git.kernel.org/stable/c/7b75515728b628a9a7540f201efdeb8ca7299385 - https://git.kernel.org/stable/c/85d2a8b287a89853c0dcfc5a97b5e9d36376fe37 - https://git.kernel.org/stable/c/1bf8c0aff8fb5c4edf3ba6728e6bedbd610d7f4b - https://git.kernel.org/stable/c/c27a3b6ba23350708cf5ab9962337447b51eb76d - https://git.kernel.org/stable/c/65f20301607d07ee279b0804d11a05a62a6c1a1c
CVE ID: CVE-2022-49795 State: PUBLISHED Published: 2025-05-01T14:09:25.764Z Last Updated: 2025-05-04T08:45:31.504Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rethook: fix a potential memleak in rethook_alloc() In rethook_alloc(), the variable rh is not freed or passed out if handler is NULL, which could lead to a memleak, fix it. [Masami: Add "rethook:" tag to the title.] Acke-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> References: - https://git.kernel.org/stable/c/cbc5d1f9a8cc40ba2bc6779b36d2ea1f65bc027c - https://git.kernel.org/stable/c/0a1ebe35cb3b7aa1f4b26b37e2a0b9ae68dc4ffb
CVE ID: CVE-2022-49796 State: PUBLISHED Published: 2025-05-01T14:09:26.392Z Last Updated: 2025-05-04T08:45:32.625Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix potential null-ptr-deref on trace_array in kprobe_event_gen_test_exit() When test_gen_kprobe_cmd() failed after kprobe_event_gen_cmd_end(), it will goto delete, which will call kprobe_event_delete() and release the corresponding resource. However, the trace_array in gen_kretprobe_test will point to the invalid resource. Set gen_kretprobe_test to NULL after called kprobe_event_delete() to prevent null-ptr-deref. BUG: kernel NULL pointer dereference,
etprobe_test to NULL after called kprobe_event_delete() to prevent null-ptr-deref. BUG: kernel NULL pointer dereference, address: 0000000000000070 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 246 Comm: modprobe Tainted: G W 6.1.0-rc1-00174-g9522dc5c87da-dirty #248 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0 Code: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c 01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 <44> 8b 65 70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f RSP: 0018:ffffc9000159fe00 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88810
4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f RSP: 0018:ffffc9000159fe00 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000 RDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064 R13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000 FS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00
04 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __ftrace_set_clr_event+0x3e/0x60 trace_array_set_clr_event+0x35/0x50 ? 0xffffffffa0000000 kprobe_event_gen_test_exit+0xcd/0x10b [kprobe_event_gen_test] __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f89eeb061b7 References: - https://git.kernel.org/stable/c/28a54854a95923b6266a9479ad660ca2cc0e1d5f - https://git.kernel.org/stable/c/e57daa750369fedbf678346aec724a43b9a51749 -
c/28a54854a95923b6266a9479ad660ca2cc0e1d5f - https://git.kernel.org/stable/c/e57daa750369fedbf678346aec724a43b9a51749 - https://git.kernel.org/stable/c/510c12f93674ea0a1423b24f36c67357168a262a - https://git.kernel.org/stable/c/22ea4ca9631eb137e64e5ab899e9c89cb6670959
CVE ID: CVE-2022-49797 State: PUBLISHED Published: 2025-05-01T14:09:26.998Z Last Updated: 2025-05-04T08:45:33.907Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix potential null-ptr-deref on trace_event_file in kprobe_event_gen_test_exit() When trace_get_event_file() failed, gen_kretprobe_test will be assigned as the error code. If module kprobe_event_gen_test is removed now, the null pointer dereference will happen in kprobe_event_gen_test_exit(). Check if gen_kprobe_test or gen_kretprobe_test is error code or NULL before dereference them. BUG: kernel NULL pointer dereference, address: 0000000000000012 PGD
test is error code or NULL before dereference them. BUG: kernel NULL pointer dereference, address: 0000000000000012 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 2210 Comm: modprobe Not tainted 6.1.0-rc1-00171-g2159299a3b74-dirty #217 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test] Code: Unable to access opcode bytes at 0xffffffff9ffffff2. RSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246 RAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 0000000000000000 RDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c RBP: ffffffffa0000000 R08: 00000000000000
000000000000 RDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c RBP: ffffffffa0000000 R08: 0000000000000004 R09: 00000000001e95c0 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000800 R13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? sy
7: 0000000000000400 Call Trace: <TASK> __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/bb70fcae4115d24b7e8cee17a6da8b1943f546bb - https://git.kernel.org/stable/c/3a41c0f2a5c3bf72b4c4e9dd4b1025378201e332 - https://git.kernel.org/stable/c/fd0efd4f7bfe611a8339ba01bc2ac3c33e79159d - https://git.kernel.org/stable/c/e0d75267f59d7084e0468bd68beeb1bf9c71d7c0
CVE ID: CVE-2022-49798 State: PUBLISHED Published: 2025-05-01T14:09:27.722Z Last Updated: 2025-05-04T08:45:35.052Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Fix race where eprobes can be called before the event The flag that tells the event to call its triggers after reading the event is set for eprobes after the eprobe is enabled. This leads to a race where the eprobe may be triggered at the beginning of the event where the record information is NULL. The eprobe then dereferences the NULL record causing a NULL kernel pointer bug. Test for a NULL record to keep this from happening. References: - https://git.kernel
causing a NULL kernel pointer bug. Test for a NULL record to keep this from happening. References: - https://git.kernel.org/stable/c/7291dec4f2d17a2d3fd1f789fb41e58476539f21 - https://git.kernel.org/stable/c/73f5191467ffe3af82f27fe0ea6a8c2fac724d3f - https://git.kernel.org/stable/c/94eedf3dded5fb472ce97bfaf3ac1c6c29c35d26
CVE ID: CVE-2022-49799 State: PUBLISHED Published: 2025-05-01T14:09:28.377Z Last Updated: 2025-05-04T08:45:36.249Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Fix wild-memory-access in register_synth_event() In register_synth_event(), if set_synth_event_print_fmt() failed, then both trace_remove_event_call() and unregister_trace_event() will be called, which means the trace_event_call will call __unregister_trace_event() twice. As the result, the second unregister will causes the wild-memory-access. register_synth_event set_synth_event_print_fmt failed trace_remove_event_call event_remove if call->event.funcs then _
. register_synth_event set_synth_event_print_fmt failed trace_remove_event_call event_remove if call->event.funcs then __unregister_trace_event (first call) unregister_trace_event __unregister_trace_event (second call) Fix the bug by avoiding to call the second __unregister_trace_event() by checking if the first one is called. general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] CPU: 0 PID: 3807 Comm: modprobe Not tainted 6.1.0-rc1-00186-g76f33a7eedb4 #299 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 0
3a7eedb4 #299 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_trace_event+0x6e/0x280 Code: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b RSP: 0018:ffff88810413f370 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 RBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481 R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122 R13: ffff888105d05
0000000000000 R09: fffffbfff0913481 R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122 R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __create_synth_event+0x1e37/0x1eb0 create_or_delete_synth_event+0x110/0x250 synth_event_run_command+0x2f/0x110 test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] synth_event_gen_test_init
0x250 synth_event_run_command+0x2f/0x110 test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/315b149f08229a233d47532eb5da1707b28f764c - https://git.kernel.org/stable/c/6517b97134f724d12f673f9fb4f456d75c7a905f - https://git.kernel.org/stable/c/a5bfa53e5036b3e7a80be902dd3719a930accabd - https://git.kernel.org/stable/c/1b5f1c34d3f5a664a57a5a7557a50e4e3cc2505c