Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
01d888068a3fcc82efb6171a - https://git.kernel.org/stable/c/9fd6170c5e2d0ccd027abe26f6f5ffc528e1bb27 - https://git.kernel.org/stable/c/d0aac7146e96bf39e79c65087d21dfa02ef8db38 - https://git.kernel.org/stable/c/19e3f69d19801940abc2ac37c169882769ed9770 - https://git.kernel.org/stable/c/dc02aaf950015850e7589696521c7fca767cea77 - https://git.kernel.org/stable/c/b1727def850904e4b8ba384043775672841663a1 - https://git.kernel.org/stable/c/e230a4455ac3e9b112f0367d1b8e255e141afae0
CVE ID: CVE-2022-49957 State: PUBLISHED Published: 2025-06-18T11:00:19.238Z Last Updated: 2025-06-18T11:00:19.238Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kcm: fix strp_init() order and cleanup strp_init() is called just a few lines above this csk->sk_user_data check, it also initializes strp->work etc., therefore, it is unnecessary to call strp_done() to cancel the freshly initialized work. And if sk_user_data is already used by KCM, psock->strp should not be touched, particularly strp->work state, so we need to move strp_init() after the csk->sk_user_data check. This also makes a lockdep warning reported by syzbot go a
we need to move strp_init() after the csk->sk_user_data check. This also makes a lockdep warning reported by syzbot go away. References: - https://git.kernel.org/stable/c/473f394953216614087f4179e55cdf0cf616a13b - https://git.kernel.org/stable/c/a8a0c321319ad64a5427d6172cd9c23b4d6ca1e8 - https://git.kernel.org/stable/c/0946ff31d1a8778787bf6708beb20f38715267cc - https://git.kernel.org/stable/c/1b6666964ca1de93a7bf06e122bcf3616dbd33a9 - https://git.kernel.org/stable/c/55fb8c3baa8071c5d533a9ad48624e44e2a04ef5 - https://git.kernel.org/stable/c/f865976baa85915c7672f351b74d5974b93215f6 - https://git.kernel.org/stable/c/8fc29ff3910f3af08a7c40a75d436b5720efe2bf
CVE ID: CVE-2022-49958 State: PUBLISHED Published: 2025-06-18T11:00:20.042Z Last Updated: 2025-06-18T11:00:20.042Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/sched: fix netdevice reference leaks in attach_default_qdiscs() In attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails to attach qdisc because there is no memory in attach_one_default_qdisc(). Then dev->qdisc will be noop_qdisc by default. But the other queues may be able to successfully attach to default qdisc. In this case, the fallback to noqueue process will be triggered. If the original attached qdisc is not released and a new one is direct
he fallback to noqueue process will be triggered. If the original attached qdisc is not released and a new one is directly attached, this will cause netdevice reference leaks. The following is the bug log: veth0: default qdisc (fq_codel) fail, fallback to noqueue unregister_netdevice: waiting for veth0 to become free. Usage count = 32 leaked reference. qdisc_alloc+0x12e/0x210 qdisc_create_dflt+0x62/0x140 attach_one_default_qdisc.constprop.41+0x44/0x70 dev_activate+0x128/0x290 __dev_open+0x12a/0x190 __dev_change_flags+0x1a2/0x1f0 dev_change_flags+0x23/0x60 do_setlink+0x332/0x1150 __rtnl_newlink+0x52f/0x8e0 rtnl_newlink+0x43/0x70 rtnetlink_rcv_msg+0x140/0x3b0 netlink_rcv_skb+0x50/0x100 netlink
x1150 __rtnl_newlink+0x52f/0x8e0 rtnl_newlink+0x43/0x70 rtnetlink_rcv_msg+0x140/0x3b0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1bb/0x290 netlink_sendmsg+0x37c/0x4e0 sock_sendmsg+0x5f/0x70 ____sys_sendmsg+0x208/0x280 Fix this bug by clearing any non-noop qdiscs that may have been assigned before trying to re-attach. References: - https://git.kernel.org/stable/c/44dfa645895a56f65461249deb5b81cd16560e2a - https://git.kernel.org/stable/c/a420d587260185407eda9c5766cfa9bdd5c39a56 - https://git.kernel.org/stable/c/0c6c522857151ac00150fd01baeebf231fb7d142 - https://git.kernel.org/stable/c/f612466ebecb12a00d9152344ddda6f6345f04dc
CVE ID: CVE-2022-49959 State: PUBLISHED Published: 2025-06-18T11:00:20.749Z Last Updated: 2025-06-18T11:00:20.749Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix memory leak at failed datapath creation ovs_dp_cmd_new()->ovs_dp_change()->ovs_dp_set_upcall_portids() allocates array via kmalloc. If for some reason new_vport() fails during ovs_dp_cmd_new() dp->upcall_portids must be freed. Add missing kfree. Kmemleak example: unreferenced object 0xffff88800c382500 (size 64): comm "dump_state", pid 323, jiffies 4294955418 (age 104.347s) hex dump (first 32 bytes): 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..
323, jiffies 4294955418 (age 104.347s) hex dump (first 32 bytes): 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8..... 03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(... backtrace: [<0000000071bebc9f>] ovs_dp_set_upcall_portids+0x38/0xa0 [<000000000187d8bd>] ovs_dp_change+0x63/0xe0 [<000000002397e446>] ovs_dp_cmd_new+0x1f0/0x380 [<00000000aa06f36e>] genl_family_rcv_msg_doit+0xea/0x150 [<000000008f583bc4>] genl_rcv_msg+0xdc/0x1e0 [<00000000fa10e377>] netlink_rcv_skb+0x50/0x100 [<000000004959cece>] genl_rcv+0x24/0x40 [<000000004699ac7f>] netlink_unicast+0x23e/0x360 [<00000000c153573e>] netlink_sendmsg+0x24e/0x4b0 [<000000006f4aa380>] sock_sendmsg+0x62/0x70 [<00000000
cast+0x23e/0x360 [<00000000c153573e>] netlink_sendmsg+0x24e/0x4b0 [<000000006f4aa380>] sock_sendmsg+0x62/0x70 [<00000000d0068654>] ____sys_sendmsg+0x230/0x270 [<0000000012dacf7d>] ___sys_sendmsg+0x88/0xd0 [<0000000011776020>] __sys_sendmsg+0x59/0xa0 [<000000002e8f2dc1>] do_syscall_64+0x3b/0x90 [<000000003243e7cb>] entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/ca54b2bfaab385778e55a9fd33f6c31e7f743b48 - https://git.kernel.org/stable/c/c0c1c0241917459644326a1a3102207c871ae159 - https://git.kernel.org/stable/c/a87406f4adee9c53b311d8a1ba2849c69e29a6d0
CVE ID: CVE-2022-49960 State: PUBLISHED Published: 2025-06-18T11:00:21.621Z Last Updated: 2025-06-18T11:00:21.621Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915: fix null pointer dereference Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel. The root cause is null pointer defeference of bi_next in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c. BUG: kernel NULL pointer dereference, address: 000000000000002e PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 1 Comm: swapper/0 Tainted: G U 5.17.0-rc1 Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021 RIP: 0010
apper/0 Tainted: G U 5.17.0-rc1 Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021 RIP: 0010:tgl_get_bw_info+0x2de/0x510 ... [ 2.554467] Call Trace: [ 2.554467] <TASK> [ 2.554467] intel_bw_init_hw+0x14a/0x434 [ 2.554467] ? _printk+0x59/0x73 [ 2.554467] ? _dev_err+0x77/0x91 [ 2.554467] i915_driver_hw_probe+0x329/0x33e [ 2.554467] i915_driver_probe+0x4c8/0x638 [ 2.554467] i915_pci_probe+0xf8/0x14e [ 2.554467] ? _raw_spin_unlock_irqrestore+0x12/0x2c [ 2.554467] pci_device_probe+0xaa/0x142 [ 2.554467] really_probe+0x13f/0x2f4 [ 2.554467] __driver_probe_device+0x9e/0xd3 [ 2.554467] driver_probe_device+0x24/0x7c [ 2.554467] __driver_attach+0xba/0xcf [ 2.554467] ? driver
be_device+0x9e/0xd3 [ 2.554467] driver_probe_device+0x24/0x7c [ 2.554467] __driver_attach+0xba/0xcf [ 2.554467] ? driver_attach+0x1f/0x1f [ 2.554467] bus_for_each_dev+0x8c/0xc0 [ 2.554467] bus_add_driver+0x11b/0x1f7 [ 2.554467] driver_register+0x60/0xea [ 2.554467] ? mipi_dsi_bus_init+0x16/0x16 [ 2.554467] i915_init+0x2c/0xb9 [ 2.554467] ? mipi_dsi_bus_init+0x16/0x16 [ 2.554467] do_one_initcall+0x12e/0x2b3 [ 2.554467] do_initcall_level+0xd6/0xf3 [ 2.554467] do_initcalls+0x4e/0x79 [ 2.554467] kernel_init_freeable+0xed/0x14d [ 2.554467] ? rest_init+0xc1/0xc1 [ 2.554467] kernel_init+0x1a/0x120 [ 2.554467] ret_from_fork+0x1f/0x30 [ 2.554467] </TASK> ... Kernel panic - not syncing: Fatal exceptio
l_init+0x1a/0x120 [ 2.554467] ret_from_fork+0x1f/0x30 [ 2.554467] </TASK> ... Kernel panic - not syncing: Fatal exception (cherry picked from commit c247cd03898c4c43c3bce6d4014730403bc13032) References: - https://git.kernel.org/stable/c/c2798203315f4729bab0b917bf4c17a159abf9f8 - https://git.kernel.org/stable/c/458ec0c8f35963626ccd51c3d50b752de5f1b9d4
CVE ID: CVE-2022-49961 State: PUBLISHED Published: 2025-06-18T11:00:22.399Z Last Updated: 2025-06-18T11:00:22.399Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO Precision markers need to be propagated whenever we have an ARG_CONST_* style argument, as the verifier cannot consider imprecise scalars to be equivalent for the purposes of states_equal check when such arguments refine the return value (in this case, set mem_size for PTR_TO_MEM). The resultant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering
ltant mem_size for the R0 is derived from the constant value, and if the verifier incorrectly prunes states considering them equivalent where such arguments exist (by seeing that both registers have reg->precise as false in regsafe), we can end up with invalid programs passing the verifier which can do access beyond what should have been the correct mem_size in that explored state. To show a concrete example of the problem: 0000000000000000 <prog>: 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 <LBB5_5> 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 <LBB5_3> 10: r2 = -1 0000000000000058 <LBB5_3>: 1
(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 <LBB5_3> 10: r2 = -1 0000000000000058 <LBB5_3>: 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 <LBB5_5> 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit 00000000000000b8 <LBB5_5>: 23: w0 = 0 24: exit For the first case, the single line execution's exploration will prune the search at insn 14 for the branch insn 9's second leg as it will be verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier du
always be 0 so at runtime we don't get error for being greater than UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just sees reg->precise as false for both r2 registers in both states, hence considers them equal for purposes of states_equal. If we propagated precise markers using the backtracking support, we would use the precise marking to then ensure that old r2 (UINT_MAX) was within the new r2 (1) and this would never be true, so the verification would rightfully fail. The end result is that the out of bounds access at instruction 19 would be permitted without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is
without this fix. Note that reg->precise is always set to true when user does not have CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static or global functions)), hence this is only a problem when precision marks need to be explicitly propagated (i.e. privileged users with CAP_BPF). A simplified test case has been included in the next patch to prevent future regressions. References: - https://git.kernel.org/stable/c/2459615a8d7f44ac81f0965bc094e55ccb254717 - https://git.kernel.org/stable/c/2fc31465c5373b5ca4edf2e5238558cb62902311
CVE ID: CVE-2022-49962 State: PUBLISHED Published: 2025-06-18T11:00:23.321Z Last Updated: 2025-06-18T11:00:23.321Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xhci: Fix null pointer dereference in remove if xHC has only one roothub The remove path in xhci platform driver tries to remove and put both main and shared hcds even if only a main hcd exists (one roothub) This causes a null pointer dereference in reboot for those controllers. Check that the shared_hcd exists before trying to remove it. References: - https://git.kernel.org/stable/c/7081b2f34ff291ada012bd6abacaf7d51c4cf73f - https://git.kernel.org/stable/c/4a593a62a9e
- https://git.kernel.org/stable/c/7081b2f34ff291ada012bd6abacaf7d51c4cf73f - https://git.kernel.org/stable/c/4a593a62a9e3a25ab4bc37f612e4edec144f7f43
CVE ID: CVE-2022-49963 State: PUBLISHED Published: 2025-06-18T11:00:24.021Z Last Updated: 2025-06-18T11:00:24.021Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915/ttm: fix CCS handling Crucible + recent Mesa seems to sometimes hit: GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER) And it looks like we can also trigger this with gem_lmem_swapping, if we modify the test to use slightly larger object sizes. Looking closer it looks like we have the following issues in migrate_copy(): - We are using plain integer in various places, which we can easily overflow with a large object. - We pass the entire object size (when the sr
teger in various places, which we can easily overflow with a large object. - We pass the entire object size (when the src is lmem) into emit_pte() and then try to copy it, which doesn't work, since we only have a few fixed sized windows in which to map the pages and perform the copy. With an object > 8M we therefore aren't properly copying the pages. And then with an object > 64M we trigger the GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER). So it looks like our copy handling for any object > 8M (which is our CHUNK_SZ) is currently broken on DG2. Testcase: igt@gem_lmem_swapping (cherry picked from commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2) References: - https://git.kernel.org/stable/
apping (cherry picked from commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2) References: - https://git.kernel.org/stable/c/97434cb55bd884bd268626ec41489f79b261b2d4 - https://git.kernel.org/stable/c/8d905254162965c8e6be697d82c7dbf5d08f574d
CVE ID: CVE-2022-49964 State: PUBLISHED Published: 2025-06-18T11:00:29.710Z Last Updated: 2025-07-15T15:43:40.747Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level Though acpi_find_last_cache_level() always returned signed value and the document states it will return any errors caused by lack of a PPTT table, it never returned negative values before. Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage") however changed it by returning -ENOENT if no PPTT was found. The value returned from acpi_find_last_cache_level() is
") however changed it by returning -ENOENT if no PPTT was found. The value returned from acpi_find_last_cache_level() is then assigned to unsigned fw_level. It will result in the number of cache leaves calculated incorrectly as a huge value which will then cause the following warning from __alloc_pages as the order would be great than MAX_ORDER because of incorrect and huge cache leaves value. | WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:5407 __alloc_pages+0x74/0x314 | Modules linked in: | CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73 | pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __alloc_pages+0x74/0x314 | lr : alloc_pages+0xe8/0x318 | Cal
00005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : __alloc_pages+0x74/0x314 | lr : alloc_pages+0xe8/0x318 | Call trace: | __alloc_pages+0x74/0x314 | alloc_pages+0xe8/0x318 | kmalloc_order_trace+0x68/0x1dc | __kmalloc+0x240/0x338 | detect_cache_attributes+0xe0/0x56c | update_siblings_masks+0x38/0x284 | store_cpu_topology+0x78/0x84 | smp_prepare_cpus+0x48/0x134 | kernel_init_freeable+0xc4/0x14c | kernel_init+0x2c/0x1b4 | ret_from_fork+0x10/0x20 Fix the same by changing fw_level to be signed integer and return the error from init_cache_level() early in case of error. References: - https://git.kernel.org/stable/c/a754ee1c66bd0a23e613f0bf865053b29cb90e16 - https://git.kernel.org/stable/c
References: - https://git.kernel.org/stable/c/a754ee1c66bd0a23e613f0bf865053b29cb90e16 - https://git.kernel.org/stable/c/e75d18cecbb3805895d8ed64da4f78575ec96043
CVE ID: CVE-2022-49965 State: PUBLISHED Published: 2025-06-18T11:00:30.391Z Last Updated: 2025-06-19T13:10:40.567Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: add missing ->fini_xxxx interfaces for some SMU13 asics Without these, potential memory leak may be induced. References: - https://git.kernel.org/stable/c/22a75c616f1971c23838506b14971a4ef4a66bd7 - https://git.kernel.org/stable/c/4bac1c846eff8042dd59ddecd0a43f3b9de5fd23
CVE ID: CVE-2022-49966 State: PUBLISHED Published: 2025-06-18T11:00:31.078Z Last Updated: 2025-06-19T13:10:41.622Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid To avoid any potential memory leak. References: - https://git.kernel.org/stable/c/60d522f317078381ff8a3599fe808f96fc256cd5 - https://git.kernel.org/stable/c/a89e753d5a9f3b321f4a3098e2755c5aabcff0af - https://git.kernel.org/stable/c/4d21584ac6392aa66171b7efd647ecd1a447556b - https://git.kernel.org/stable/c/0a2d922a5618377cdf8fa476351362733ef55342
CVE ID: CVE-2022-49967 State: PUBLISHED Published: 2025-06-18T11:00:31.782Z Last Updated: 2025-06-18T11:00:31.782Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a data-race around bpf_jit_limit. While reading bpf_jit_limit, it can be changed concurrently via sysctl, WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit is long, so we need to add a paired READ_ONCE() to avoid load-tearing. References: - https://git.kernel.org/stable/c/ba632ad0bacb13197a8f38e7526448974e87f292 - https://git.kernel.org/stable/c/0947ae1121083d363d522ff7518ee72b55bd8d29
CVE ID: CVE-2022-49968 State: PUBLISHED Published: 2025-06-18T11:00:32.443Z Last Updated: 2025-06-18T11:00:32.443Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ieee802154/adf7242: defer destroy_workqueue call There is a possible race condition (use-after-free) like below (FREE) | (USE) adf7242_remove | adf7242_channel cancel_delayed_work_sync | destroy_workqueue (1) | adf7242_cmd_rx | mod_delayed_work (2) | The root cause for this race is that the upper layer (ieee802154) is unaware of this detaching event and the function adf7242_channel can be called without any checks. To fix this, we can add a flag write at the beginning
nd the function adf7242_channel can be called without any checks. To fix this, we can add a flag write at the beginning of adf7242_remove and add flag check in adf7242_channel. Or we can just defer the destructive operation like other commit 3e0588c291d6 ("hamradio: defer ax25 kfree after unregister_netdev") which let the ieee802154_unregister_hw() to handle the synchronization. This patch takes the second option. runs") References: - https://git.kernel.org/stable/c/dede80aaf01f4b6e8657d23726cb4a3da226ec4c - https://git.kernel.org/stable/c/bed12d7531df1417fc92c691999ff95e03835008 - https://git.kernel.org/stable/c/23a29932715ca43bceb2eae1bdb770995afe7271 - https://git.kernel.org/stable/c/9f85
835008 - https://git.kernel.org/stable/c/23a29932715ca43bceb2eae1bdb770995afe7271 - https://git.kernel.org/stable/c/9f8558c5c642c62c450c98c99b7d18a709fff485 - https://git.kernel.org/stable/c/15f3b89bd521d5770d36a61fc04a77c293138ba6 - https://git.kernel.org/stable/c/afe7116f6d3b888778ed6d95e3cf724767b9aedf
CVE ID: CVE-2022-49969 State: PUBLISHED Published: 2025-06-18T11:00:33.226Z Last Updated: 2025-07-11T17:19:23.743Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: clear optc underflow before turn off odm clock [Why] After ODM clock off, optc underflow bit will be kept there always and clear not work. We need to clear that before clock off. [How] Clear that if have when clock off. References: - https://git.kernel.org/stable/c/443687798d6f094412b7312b64b3bb4d99aedff7 - https://git.kernel.org/stable/c/814b756d4ec3a8728debb116cf49005feada7750 - https://git.kernel.org/stable/c/3c1dfeaeb3b4e3ea656041da1241e6ee3c3b3202
le/c/814b756d4ec3a8728debb116cf49005feada7750 - https://git.kernel.org/stable/c/3c1dfeaeb3b4e3ea656041da1241e6ee3c3b3202 - https://git.kernel.org/stable/c/5ee30bcfdb32526233d2572f3d9ec371928679f1 - https://git.kernel.org/stable/c/3101839b080137c367f3f88c2a040f791de880aa - https://git.kernel.org/stable/c/b2a93490201300a749ad261b5c5d05cb50179c44
CVE ID: CVE-2022-49970 State: PUBLISHED Published: 2025-06-18T11:00:33.934Z Last Updated: 2025-06-18T11:00:33.934Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, cgroup: Fix kernel BUG in purge_effective_progs Syzkaller reported a triggered kernel BUG as follows: ------------[ cut here ]------------ kernel BUG at kernel/bpf/cgroup.c:925! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 194 Comm: detach Not tainted 5.19.0-14184-g69dac8e431af #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0 Code: 00 e8 92 60
BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0 Code: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84 28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 <0f> 0b 48 8b 0c5 RSP: 0018:ffffc9000055bdb0 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578 RBP: 0000000000000000 R08: ffff888100ec0800 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000 R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00 FS: 00007f68213d2b80(0000) GS:ffff88813bc80000(0000) knlGS:00000000000000
0d R14: ffffc90000199000 R15: ffff888100effb00 FS: 00007f68213d2b80(0000) GS:ffff88813bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0 Call Trace: <TASK> cgroup_bpf_prog_detach+0xcc/0x100 __sys_bpf+0x2273/0x2a00 __x64_sys_bpf+0x17/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f68214dbcb9 Code: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff8 RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0
SP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007f68214dbcb9 RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009 RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003 R10: 00007ffeb487db70 R11: 0000000000000246 R12: 00007ffeb487dc20 R13: 0000000000000004 R14: 0000000000000001 R15: 000055f74a1011b0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- Repetition steps: For the following cgroup tree, root | cg1 | cg2 1. attach prog2 to cg2, and then attach prog1 to cg1, both bpf progs attach type is NONE or OVERRIDE. 2. write 1 to /proc/thread-self/fail-nth for failslab. 3. detach pro