Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ting the enabled counter, which ensures that no IO is in flight and thus all counters are zero. Unfortunately, iolatency_set_limit() isn't the only place where the enabled counter is manipulated. iolatency_pd_offline() can also dec the counter and trigger disabling. As this disabling happens without freezing the q, this can easily happen while some IOs are in flight and thus leak the counts. This can be easily demonstrated by turning on iolatency on an one empty cgroup while IOs are in flight in other cgroups and then removing the cgroup. Note that iolatency shouldn't have been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device. The fol
been enabled elsewhere in the system to ensure that removing the cgroup disables iolatency for the whole device. The following keeps flipping on and off iolatency on sda: echo +io > /sys/fs/cgroup/cgroup.subtree_control while true; do mkdir -p /sys/fs/cgroup/test echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency sleep 1 rmdir /sys/fs/cgroup/test sleep 1 done and there's concurrent fio generating direct rand reads: fio --name test --filename=/dev/sda --direct=1 --rw=randread \ --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k while monitoring with the following drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in
owing drgn script: while True: for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()): for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list): blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node') pd = blkg.pd[prog['blkcg_policy_iolatency'].plid] if pd.value_() == 0: continue iolat = container_of(pd, 'struct iolatency_grp', 'pd') inflight = iolat.rq_wait.inflight.counter.value_() if inflight: print(f'inflight={inflight} {disk_name(blkg.q.disk).decode("utf-8")} ' f'{cgroup_path(css.cgroup).decode("utf-8")}') time.sleep(1) The monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /u
monitoring output looks like the following: inflight=1 sda /user.slice inflight=1 sda /user.slice ... inflight=14 sda /user.slice inflight=13 sda /user.slice inflight=17 sda /user.slice inflight=15 sda /user.slice inflight=18 sda /user.slice inflight=17 sda /user.slice inflight=20 sda /user.slice inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19 inflight=19 sda /user.slice inflight=19 sda /user.slice If a cgroup with stuck inflight ends up getting throttled, the throttled IOs will never get issued as there's no completion event to wake it up leading to an indefinite hang. This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off fr
efinite hang. This patch fixes the bug by unifying enable handling into a work item which is automatically kicked off from iolatency_set_min_lat_nsec() which is called from both iolatency_set_limit() and iolatency_pd_offline() paths. Punting to a work item is necessary as iolatency_pd_offline() is called under spinlocks while freezing a request_queue requires a sleepable context. This also simplifies the code reducing LOC sans the comments and avoids the unnecessary freezes which were happening whenever a cgroup's latency target is newly set or cleared. References: - https://git.kernel.org/stable/c/515d077ee3085ae343b6bea7fd031f9906645f38 - https://git.kernel.org/stable/c/d19fa8f252000d141f9
//git.kernel.org/stable/c/515d077ee3085ae343b6bea7fd031f9906645f38 - https://git.kernel.org/stable/c/d19fa8f252000d141f9199ca32959c50314e1f05 - https://git.kernel.org/stable/c/77692c02e1517c54f2fd0535f41aa4286ac9f140 - https://git.kernel.org/stable/c/a30acbb5dfb7bcc813ad6a18ca31011ac44e5547 - https://git.kernel.org/stable/c/968f7a239c590454ffba79c126fbe0e963a0ba78 - https://git.kernel.org/stable/c/5b0ff3ebbef791341695b718f8d2870869cf1d01 - https://git.kernel.org/stable/c/8a177a36da6c54c98b8685d4f914cb3637d53c0d
CVE ID: CVE-2022-49395 State: PUBLISHED Published: 2025-02-26T02:11:25.676Z Last Updated: 2025-10-01T19:46:50.853Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: um: Fix out-of-bounds read in LDT setup syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report
tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ====================================================
0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ================================================================== Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/668ca34a428d6ffc0f99a1a6a9b661a288d4183b - https://git.kernel.org/stable/c/ef1dc929a1e5fa1b2d842256db9fb8710d3be910 - https://git.kernel.org/stable/c/3549ab4b962cf619e8c55484a0d870a34b3f845f - https://git.kernel.org/stable/c/9caad70819aef3431abaf73ba5163b55b161aba0 - https://git.kernel.org/stable/c/cf0dabc37446c5ee538ae7b4c467ab0e53fa5463 - https://git.kernel.org/stable/c/10995a382271254bd276627ec74136da4a23c4a6 - https://git.kernel.org/stable/c/24ca648bf5f72ed887
://git.kernel.org/stable/c/10995a382271254bd276627ec74136da4a23c4a6 - https://git.kernel.org/stable/c/24ca648bf5f72ed8878cf09b5d4431935779681e - https://git.kernel.org/stable/c/91e5ba2af2d729d5126aefd5aa3eadc69b8426e5 - https://git.kernel.org/stable/c/2a4a62a14be1947fa945c5c11ebf67326381a568
CVE ID: CVE-2022-49396 State: PUBLISHED Published: 2025-02-26T02:11:26.145Z Last Updated: 2025-05-04T08:36:47.558Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix reset-controller leak on probe errors Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral). Note that due to the reset controller being defined in devicetree in "lane" child nodes, devm_reset_control_get_exclusive() cannot be used directly. References: - https://git.kernel.org/stable/c/b7b5fbcaac5355e2e695dc0c08a0fcf248250388 - https://git.kernel.org/stable/c/a39d9eccb333b8c07c43ebea1c6dfda122378a0f - htt
7b5fbcaac5355e2e695dc0c08a0fcf248250388 - https://git.kernel.org/stable/c/a39d9eccb333b8c07c43ebea1c6dfda122378a0f - https://git.kernel.org/stable/c/7ac21b24af859c097eb4034e93430056068f8f31 - https://git.kernel.org/stable/c/2156dc390402043ba5982489c6625adcb0b0975c - https://git.kernel.org/stable/c/ba173a6f8d8dffed64bb13ab23081bdddfb464f0 - https://git.kernel.org/stable/c/feb05b10b3ed3ae21b851520a0d0b71685439517 - https://git.kernel.org/stable/c/8c03eb0c8982677b4e17174073a011788891304d - https://git.kernel.org/stable/c/4d2900f20edfe541f75756a00deeb2ffe7c66bc1
CVE ID: CVE-2022-49397 State: PUBLISHED Published: 2025-02-26T02:11:26.612Z Last Updated: 2025-05-04T08:36:49.119Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: phy: qcom-qmp: fix struct clk leak on probe errors Make sure to release the pipe clock reference in case of a late probe error (e.g. probe deferral). References: - https://git.kernel.org/stable/c/b999d48b0869b8599de532ff6081575a7ab5358a - https://git.kernel.org/stable/c/621a4bcfb7aa031e7760d7b156bad7a45df58387 - https://git.kernel.org/stable/c/1668ad103679306ba2ef37f758d704e58a3ef1a0 - https://git.kernel.org/stable/c/6f3673c8d8eff0c4ab5a5ee0d3ca9717d85419b4 - https://g
03679306ba2ef37f758d704e58a3ef1a0 - https://git.kernel.org/stable/c/6f3673c8d8eff0c4ab5a5ee0d3ca9717d85419b4 - https://git.kernel.org/stable/c/b246695636a861a09f0e2cde92bb2dd8f114f024 - https://git.kernel.org/stable/c/f8d23895a41243c6a8dbf392e531fff9497bb023 - https://git.kernel.org/stable/c/ad9b0fad02f9b3a06ad5ac7df11f244e316a6254 - https://git.kernel.org/stable/c/f0a4bc38a12f5a0cc5ad68670d9480e91e6a94df
CVE ID: CVE-2022-49398 State: PUBLISHED Published: 2025-02-26T02:12:27.141Z Last Updated: 2025-05-04T12:44:36.334Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Replace list_for_each_entry_safe() if using giveback The list_for_each_entry_safe() macro saves the current item (n) and the item after (n+1), so that n can be safely removed without corrupting the list. However, when traversing the list and removing items using gadget giveback, the DWC3 lock is briefly released, allowing other routines to execute. There is a situation where, while items are being removed from the cancelled_list using dwc3_gadget_ep_
ines to execute. There is a situation where, while items are being removed from the cancelled_list using dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable routine is running in parallel (due to UDC unbind). As the cleanup routine removes n, and the pullup disable removes n+1, once the cleanup retakes the DWC3 lock, it references a request who was already removed/handled. With list debug enabled, this leads to a panic. Ensure all instances of the macro are replaced where gadget giveback is used. Example call stack: Thread#1: __dwc3_gadget_ep_set_halt() - CLEAR HALT -> dwc3_gadget_ep_cleanup_cancelled_requests() ->list_for_each_entry_safe() ->dwc3_gadget_giveback(n) ->dwc3_gadget
HALT -> dwc3_gadget_ep_cleanup_cancelled_requests() ->list_for_each_entry_safe() ->dwc3_gadget_giveback(n) ->dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list] ->spin_unlock ->Thread#2 executes ... ->dwc3_gadget_giveback(n+1) ->Already removed! Thread#2: dwc3_gadget_pullup() ->waiting for dwc3 spin_lock ... ->Thread#1 released lock ->dwc3_stop_active_transfers() ->dwc3_remove_requests() ->fetches n+1 item from cancelled_list (n removed by Thread#1) ->dwc3_gadget_giveback() ->dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list] ->spin_unlock References: - https://git.kernel.org/stable/c/1c6e5dc3b639c96e6839a8d1b8e951923fdfd34a - https://git.kernel.org/stable/c/2424307c
s: - https://git.kernel.org/stable/c/1c6e5dc3b639c96e6839a8d1b8e951923fdfd34a - https://git.kernel.org/stable/c/2424307cdf421ac72075a1384eae4e4199ab6457 - https://git.kernel.org/stable/c/26a7e6832afe9d9a991cfd9015177f083cf959cc - https://git.kernel.org/stable/c/bf594d1d0c1d7b895954018043536ffd327844f9
CVE ID: CVE-2022-49399 State: PUBLISHED Published: 2025-02-26T02:12:27.650Z Last Updated: 2025-05-04T08:36:51.387Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tty: goldfish: Use tty_port_destroy() to destroy port In goldfish_tty_probe(), the port initialized through tty_port_init() should be destroyed in error paths.In goldfish_tty_remove(), qtty->port also should be destroyed or else might leak resources. Fix the above by calling tty_port_destroy(). References: - https://git.kernel.org/stable/c/241fcb79dd1df276d80b19f5f6acc9eaaaa63309 - https://git.kernel.org/stable/c/326192b99c903a2193d820c30ed936cc2402382c - https://git.k
df276d80b19f5f6acc9eaaaa63309 - https://git.kernel.org/stable/c/326192b99c903a2193d820c30ed936cc2402382c - https://git.kernel.org/stable/c/9ae3d073f7db5578ae1907544f0c15947e9678e6 - https://git.kernel.org/stable/c/ee6c33b29e624f515202a31bf6ef0437f26a1867 - https://git.kernel.org/stable/c/da64f419d7f78272bfe40dde1262602d4ff6b32c - https://git.kernel.org/stable/c/45f6ce70abfb7ccf9d787781cbc4c03294a775a1 - https://git.kernel.org/stable/c/4639d1b992de8f37d66f698056875c274efcd45f - https://git.kernel.org/stable/c/507b05063d1b7a1fcb9f7d7c47586fc4f3508f98
CVE ID: CVE-2022-49400 State: PUBLISHED Published: 2025-02-26T02:12:28.139Z Last Updated: 2025-10-01T19:46:50.727Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md: Don't set mddev private to NULL in raid0 pers->free In normal stop process, it does like this: do_md_stop | __md_stop (pers->free(); mddev->private=NULL) | md_free (free mddev) __md_stop sets mddev->private to NULL after pers->free. The raid device will be stopped and mddev memory is free. But in reshape, it doesn't free the mddev and mddev will still be used in new raid. In reshape, it first sets mddev->private to new_pers and then runs old_pers->free(). Now raid0
till be used in new raid. In reshape, it first sets mddev->private to new_pers and then runs old_pers->free(). Now raid0 sets mddev->private to NULL in raid0_free. The new raid can't work anymore. It will panic when dereference mddev->private because of NULL pointer dereference. It can panic like this: [63010.814972] kernel BUG at drivers/md/raid10.c:928! [63010.819778] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [63010.825011] CPU: 3 PID: 44437 Comm: md0_resync Kdump: loaded Not tainted 5.14.0-86.el9.x86_64 #1 [63010.833789] Hardware name: Dell Inc. PowerEdge R6415/07YXFK, BIOS 1.15.0 09/11/2020 [63010.841440] RIP: 0010:raise_barrier+0x161/0x170 [raid10] [63010.865508] RSP: 0018:ffffc312408
BIOS 1.15.0 09/11/2020 [63010.841440] RIP: 0010:raise_barrier+0x161/0x170 [raid10] [63010.865508] RSP: 0018:ffffc312408bbc10 EFLAGS: 00010246 [63010.870734] RAX: 0000000000000000 RBX: ffffa00bf7d39800 RCX: 0000000000000000 [63010.877866] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffa00bf7d39800 [63010.884999] RBP: 0000000000000000 R08: fffffa4945e74400 R09: 0000000000000000 [63010.892132] R10: ffffa00eed02f798 R11: 0000000000000000 R12: ffffa00bbc435200 [63010.899266] R13: ffffa00bf7d39800 R14: 0000000000000400 R15: 0000000000000003 [63010.906399] FS: 0000000000000000(0000) GS:ffffa00eed000000(0000) knlGS:0000000000000000 [63010.914485] CS: 0010 DS: 0000 ES: 0000 CR0: 00000000800500
000(0000) GS:ffffa00eed000000(0000) knlGS:0000000000000000 [63010.914485] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [63010.920229] CR2: 00007f5cfbe99828 CR3: 0000000105efe000 CR4: 00000000003506e0 [63010.927363] Call Trace: [63010.929822] ? bio_reset+0xe/0x40 [63010.933144] ? raid10_alloc_init_r10buf+0x60/0xa0 [raid10] [63010.938629] raid10_sync_request+0x756/0x1610 [raid10] [63010.943770] md_do_sync.cold+0x3e4/0x94c [63010.947698] md_thread+0xab/0x160 [63010.951024] ? md_write_inc+0x50/0x50 [63010.954688] kthread+0x149/0x170 [63010.957923] ? set_kthread_struct+0x40/0x40 [63010.962107] ret_from_fork+0x22/0x30 Removing the code that sets mddev->private to NULL in raid0 can fix problem.
0x40 [63010.962107] ret_from_fork+0x22/0x30 Removing the code that sets mddev->private to NULL in raid0 can fix problem. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f63fd1e0e0fc158023cc67ea6a07e278019061ba - https://git.kernel.org/stable/c/b7a51df785031cc49caf1c59766ca89cfa97b54b - https://git.kernel.org/stable/c/7da3454a65f8a56e65dfb44fa0ccac08cbc2f5a1 - https://git.kernel.org/stable/c/0f2571ad7a30ff6b33cde142439f9378669f8b4f
CVE ID: CVE-2022-49401 State: PUBLISHED Published: 2025-02-26T02:12:28.603Z Last Updated: 2025-05-04T08:36:53.713Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/page_owner: use strscpy() instead of strlcpy() current->comm[] is not a string (no guarantee for a zero byte in it). strlcpy(s1, s2, l) is calling strlen(s2), potentially causing out-of-bound access, as reported by syzbot: detected buffer overflow in __fortify_strlen ------------[ cut here ]------------ kernel BUG at lib/string_helpers.c:980! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 4087 Comm: dhcpcd-run-hooks Not tainted 5.18.0-rc3-syzkaller-01537-g2
id opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 4087 Comm: dhcpcd-run-hooks Not tainted 5.18.0-rc3-syzkaller-01537-g20b87e7c29df #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:fortify_panic+0x18/0x1a lib/string_helpers.c:980 Code: 8c e8 c5 ba e1 fa e9 23 0f bf fa e8 0b 5d 8c f8 eb db 55 48 89 fd e8 e0 49 40 f8 48 89 ee 48 c7 c7 80 f5 26 8a e8 99 09 f1 ff <0f> 0b e8 ca 49 40 f8 48 8b 54 24 18 4c 89 f1 48 c7 c7 00 00 27 8a RSP: 0018:ffffc900000074a8 EFLAGS: 00010286 RAX: 000000000000002c RBX: ffff88801226b728 RCX: 0000000000000000 RDX: ffff8880198e0000 RSI: ffffffff81600458 RDI: fffff52000000e87 RBP: ffffffff89da2aa0 R08: 0000000000000
0000000000000 RDX: ffff8880198e0000 RSI: ffffffff81600458 RDI: fffff52000000e87 RBP: ffffffff89da2aa0 R08: 000000000000002c R09: 0000000000000000 R10: ffffffff815fae2e R11: 0000000000000000 R12: ffff88801226b700 R13: ffff8880198e0830 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5876ad6ff8 CR3: 000000001a48c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: <IRQ> __fortify_strlen include/linux/fortify-string.h:128 [inline] strlcpy include/linu
R7: 0000000000000600 Call Trace: <IRQ> __fortify_strlen include/linux/fortify-string.h:128 [inline] strlcpy include/linux/fortify-string.h:143 [inline] __set_page_owner_handle+0x2b1/0x3e0 mm/page_owner.c:171 __set_page_owner+0x3e/0x50 mm/page_owner.c:190 prep_new_page mm/page_alloc.c:2441 [inline] get_page_from_freelist+0xba2/0x3e00 mm/page_alloc.c:4182 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5408 alloc_pages+0x1aa/0x310 mm/mempolicy.c:2272 alloc_slab_page mm/slub.c:1799 [inline] allocate_slab+0x26c/0x3c0 mm/slub.c:1944 new_slab mm/slub.c:2004 [inline] ___slab_alloc+0x8df/0xf20 mm/slub.c:3005 __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3092 slab_alloc_node mm/slub.c:3183 [inline] slab_all
/0xf20 mm/slub.c:3005 __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3092 slab_alloc_node mm/slub.c:3183 [inline] slab_alloc mm/slub.c:3225 [inline] __kmem_cache_alloc_lru mm/slub.c:3232 [inline] kmem_cache_alloc+0x360/0x3b0 mm/slub.c:3242 dst_alloc+0x146/0x1f0 net/core/dst.c:92 References: - https://git.kernel.org/stable/c/5cd9900a1ac8b0a4ff3cd97d4d77b7711be435bf - https://git.kernel.org/stable/c/cd8c1fd8cdd14158f2d8bea2d1bfe8015dccfa3a
CVE ID: CVE-2022-49402 State: PUBLISHED Published: 2025-02-26T02:12:29.070Z Last Updated: 2025-05-04T08:36:54.911Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ftrace: Clean up hash direct_functions on register failures We see the following GPF when register_ftrace_direct fails: [ ] general protection fault, probably for non-canonical address \ 0x200000000000010: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [...] [ ] RIP: 0010:ftrace_find_rec_direct+0x53/0x70 [ ] Code: 48 c1 e0 03 48 03 42 08 48 8b 10 31 c0 48 85 d2 74 [...] [ ] RSP: 0018:ffffc9000138bc10 EFLAGS: 00010206 [ ] RAX: 0000000000000000 RBX: ffffffff813e0df0 RCX: 0000
85 d2 74 [...] [ ] RSP: 0018:ffffc9000138bc10 EFLAGS: 00010206 [ ] RAX: 0000000000000000 RBX: ffffffff813e0df0 RCX: 000000000000003b [ ] RDX: 0200000000000000 RSI: 000000000000000c RDI: ffffffff813e0df0 [ ] RBP: ffffffffa00a3000 R08: ffffffff81180ce0 R09: 0000000000000001 [ ] R10: ffffc9000138bc18 R11: 0000000000000001 R12: ffffffff813e0df0 [ ] R13: ffffffff813e0df0 R14: ffff888171b56400 R15: 0000000000000000 [ ] FS: 00007fa9420c7780(0000) GS:ffff888ff6a00000(0000) knlGS:000000000 [ ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ ] CR2: 000000000770d000 CR3: 0000000107d50003 CR4: 0000000000370ee0 [ ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ ] DR3: 000000000000
d50003 CR4: 0000000000370ee0 [ ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ ] Call Trace: [ ] <TASK> [ ] register_ftrace_direct+0x54/0x290 [ ] ? render_sigset_t+0xa0/0xa0 [ ] bpf_trampoline_update+0x3f5/0x4a0 [ ] ? 0xffffffffa00a3000 [ ] bpf_trampoline_link_prog+0xa9/0x140 [ ] bpf_tracing_prog_attach+0x1dc/0x450 [ ] bpf_raw_tracepoint_open+0x9a/0x1e0 [ ] ? find_held_lock+0x2d/0x90 [ ] ? lock_release+0x150/0x430 [ ] __sys_bpf+0xbd6/0x2700 [ ] ? lock_is_held_type+0xd8/0x130 [ ] __x64_sys_bpf+0x1c/0x20 [ ] do_syscall_64+0x3a/0x80 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xae [ ] RIP: 0033:0x7fa9421defa
4_sys_bpf+0x1c/0x20 [ ] do_syscall_64+0x3a/0x80 [ ] entry_SYSCALL_64_after_hwframe+0x44/0xae [ ] RIP: 0033:0x7fa9421defa9 [ ] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 9 f8 [...] [ ] RSP: 002b:00007ffed743bd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ ] RAX: ffffffffffffffda RBX: 00000000069d2480 RCX: 00007fa9421defa9 [ ] RDX: 0000000000000078 RSI: 00007ffed743bd80 RDI: 0000000000000011 [ ] RBP: 00007ffed743be00 R08: 0000000000bb7270 R09: 0000000000000000 [ ] R10: 00000000069da210 R11: 0000000000000246 R12: 0000000000000001 [ ] R13: 00007ffed743c4b0 R14: 00000000069d2480 R15: 0000000000000001 [ ] </TASK> [ ] Modules linked in: klp_vm(OK) [ ] ---[ end trace 0000000000000000
00000000069d2480 R15: 0000000000000001 [ ] </TASK> [ ] Modules linked in: klp_vm(OK) [ ] ---[ end trace 0000000000000000 ]--- One way to trigger this is: 1. load a livepatch that patches kernel function xxx; 2. run bpftrace -e 'kfunc:xxx {}', this will fail (expected for now); 3. repeat #2 => gpf. This is because the entry is added to direct_functions, but not removed. Fix this by remove the entry from direct_functions when register_ftrace_direct fails. Also remove the last trailing space from ftrace.c, so we don't have to worry about it anymore. References: - https://git.kernel.org/stable/c/82c888e51c2176a06f8b4541cf748ee81aac6e7e - https://git.kernel.org/stable/c/cae2978d6907ef2c08b9b15f70
ernel.org/stable/c/82c888e51c2176a06f8b4541cf748ee81aac6e7e - https://git.kernel.org/stable/c/cae2978d6907ef2c08b9b15f704e783f7c284713 - https://git.kernel.org/stable/c/805e87af946d8d2954171361e64d143ff37a441b - https://git.kernel.org/stable/c/a0392833a178cf109a57c2a9d4d531bdfc6cd98f - https://git.kernel.org/stable/c/7d54c15cb89a29a5f59e5ffc9ee62e6591769ef1
CVE ID: CVE-2022-49403 State: PUBLISHED Published: 2025-02-26T02:12:29.556Z Last Updated: 2025-10-01T19:46:50.601Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: lib/string_helpers: fix not adding strarray to device's resource list Add allocated strarray to device's resource list. This is a must to automatically release strarray when the device disappears. Without this fix we have a memory leak in the few drivers which use devm_kasprintf_strarray(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a152eb42fcecfe41239c3c6695342f3a128593e7 - https://git.kernel.org/stable/c/bf29edab0
: - https://git.kernel.org/stable/c/a152eb42fcecfe41239c3c6695342f3a128593e7 - https://git.kernel.org/stable/c/bf29edab0c9ff3d2633b8306a67d04c357e2a385 - https://git.kernel.org/stable/c/cd290a9839cee2f6641558877e707bd373c8f6f1