Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: tun_get_user() napi_gro_frags() napi_frags_finish() case GRO_NORMAL: gro_normal_one() list_add_tail(&skb->list, &napi->rx_list); <-- While napi->rx_count < READ_ONCE(gro_normal_batch), <-- gro_normal_list() is not called, napi->rx_list is not empty <-- not ask to complete the gro work, will cause memory leaks in <-- following tun_napi_del() ... tun_napi_del() netif_napi_del() __netif_napi_del() <-- &napi->rx_list is not empty, which caused memory leaks To fix, add napi_complete() after napi_gro_frags(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/223ef6a9
i_gro_frags(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/223ef6a94e52331a6a7ef31e59921e0e82d2d40a - https://git.kernel.org/stable/c/a4f73f6adc53fd7a3f9771cbc89a03ef39b0b755 - https://git.kernel.org/stable/c/3401f964028ac941425b9b2c8ff8a022539ef44a - https://git.kernel.org/stable/c/d7569302a7a52a9305d2fb054df908ff985553bb - https://git.kernel.org/stable/c/8b12a020b20a78f62bedc50f26db3bf4fadf8cb9 - https://git.kernel.org/stable/c/1118b2049d77ca0b505775fc1a8d1909cf19a7ec
CVE ID: CVE-2022-49872 State: PUBLISHED Published: 2025-05-01T14:10:22.402Z Last Updated: 2025-05-04T12:45:19.624Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: gso: fix panic on frag_list with mixed head alloc types Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list"), it is allowed to change gso_size of a GRO packet. However, that commit assumes that "checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too". It turns out this assumption does not hold. We've seen BUG_O
mbers have non head_frag head, then the first one has too". It turns out this assumption does not hold. We've seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced. There are three different locations where this can be fixed: (1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_f
frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem. (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list. (3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down. This patch implements (3). To limit the performance impact in skb_segment, the list is walked only f
slows things down. This patch implements (3). To limit the performance impact in skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set that have gso_size changed. Normal paths thus will not hit it. We could check only the last skb but since we need to walk the whole list anyway, let's stay on the safe side. References: - https://git.kernel.org/stable/c/5876b7f249a1ecbbcc8e35072c3828d6526d1c3a - https://git.kernel.org/stable/c/0a9f56e525ea871d3950b90076912f5c7494f00f - https://git.kernel.org/stable/c/bd5362e58721e4d0d1a37796593bd6e51536ce7a - https://git.kernel.org/stable/c/65ad047fd83502447269fda8fd26c99077a9af47 - https://git.kernel.org/stable/c/50868de7dc4e7f0fcadd6029f32bf
el.org/stable/c/65ad047fd83502447269fda8fd26c99077a9af47 - https://git.kernel.org/stable/c/50868de7dc4e7f0fcadd6029f32bf4387c102ee6 - https://git.kernel.org/stable/c/ad25a115f50800c6847e0d841c5c7992a9f7c1b3 - https://git.kernel.org/stable/c/598d9e30927b15731e83797fbd700ecf399f42dd - https://git.kernel.org/stable/c/9e4b7a99a03aefd37ba7bb1f022c8efab5019165
CVE ID: CVE-2022-49873 State: PUBLISHED Published: 2025-05-01T14:10:23.128Z Last Updated: 2025-10-01T16:03:45.940Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix wrong reg type conversion in release_reference() Some helper functions will allocate memory. To avoid memory leaks, the verifier requires the eBPF program to release these memories by calling the corresponding helper functions. When a resource is released, all pointer registers corresponding to the resource should be invalidated. The verifier use release_references() to do this job, by apply __mark_reg_unknown() to each relevant register. It will give these re
use release_references() to do this job, by apply __mark_reg_unknown() to each relevant register. It will give these registers the type of SCALAR_VALUE. A register that will contain a pointer value at runtime, but of type SCALAR_VALUE, which may allow the unprivileged user to get a kernel pointer by storing this register into a map. Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate this problem. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cedd4f01f67be94735f15123158f485028571037 - https://git.kernel.org/stable/c/466ce46f251dfb259a8cbaa895ab9edd6fb56240 - https://git.kernel.org/stable/c/ae5ccad6c711db0f2ca1231be051935dd128
stable/c/466ce46f251dfb259a8cbaa895ab9edd6fb56240 - https://git.kernel.org/stable/c/ae5ccad6c711db0f2ca1231be051935dd128b8f5 - https://git.kernel.org/stable/c/f1db20814af532f85e091231223e5e4818e8464b
CVE ID: CVE-2022-49874 State: PUBLISHED Published: 2025-05-01T14:10:23.783Z Last Updated: 2025-10-01T16:03:35.110Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: fix possible memory leak in mousevsc_probe() If hid_add_device() returns error, it should call hid_destroy_device() to free hid_dev which is allocated in hid_allocate_device(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ed75d1a1c31a0cae8ecc8bcea710b25c0be68da0 - https://git.kernel.org/stable/c/249b743801c00542e9324f87b380032e957a43e8 - https://git.kernel.org/stable/c/a6d2fb1874c52ace1f5cf1966ee558829c5c
stable/c/249b743801c00542e9324f87b380032e957a43e8 - https://git.kernel.org/stable/c/a6d2fb1874c52ace1f5cf1966ee558829c5c19b6 - https://git.kernel.org/stable/c/e29289d0d8193fca6d2c1f0a1de75cfc80edec00 - https://git.kernel.org/stable/c/8597b59e3d22b27849bd3e4f92a3d466774bfb04 - https://git.kernel.org/stable/c/5ad95d71344b7ffec360d62591633b3c465dc049 - https://git.kernel.org/stable/c/5f3aba6566b866f5b0a4916f0b2e8a6ae66a6451 - https://git.kernel.org/stable/c/b5bcb94b0954a026bbd671741fdb00e7141f9c91
CVE ID: CVE-2022-49875 State: PUBLISHED Published: 2025-05-01T14:10:24.427Z Last Updated: 2025-10-01T16:03:25.233Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE When using bpftool to pin {PROG, MAP, LINK} without FILE, segmentation fault will occur. The reson is that the lack of FILE will cause strlen to trigger NULL pointer dereference. The corresponding stacktrace is shown below: do_pin do_pin_any do_pin_fd mount_bpffs_for_pin strlen(name) <- NULL pointer dereference Fix it by adding validation to the common process. Additional Analyst Notes: - CIS
len(name) <- NULL pointer dereference Fix it by adding validation to the common process. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8c80b2fca4112d724dde477aed13f7b0510a2792 - https://git.kernel.org/stable/c/6dcdd1b68b7f9333d48d48fc77b75e7f235f6a4a - https://git.kernel.org/stable/c/da5161ba94c5e9182c301dd4f09c94f715c068bd - https://git.kernel.org/stable/c/34de8e6e0e1f66e431abf4123934a2581cb5f133
CVE ID: CVE-2022-49876 State: PUBLISHED Published: 2025-05-01T14:10:25.040Z Last Updated: 2025-10-01T16:03:06.241Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit() When device is running and the interface status is changed, the gpf issue is triggered. The problem triggering process is as follows: Thread A: Thread B ieee80211_runtime_change_iftype() process_one_work() ... ... ieee80211_do_stop() ... ... ... sdata->bss = NULL ... ... ieee80211_subif_start_xmit() ieee80211_multicast_to_unicast //!sdata->bss->multicast_to_unicast cause gpf issue When the int
80211_subif_start_xmit() ieee80211_multicast_to_unicast //!sdata->bss->multicast_to_unicast cause gpf issue When the interface status is changed, the sending queue continues to send packets. After the bss is set to NULL, the bss is accessed. As a result, this causes a general-protection-fault issue. The following is the stack information: general protection fault, probably for non-canonical address 0xdffffc000000002f: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000178-0x000000000000017f] Workqueue: mld mld_ifc_work RIP: 0010:ieee80211_subif_start_xmit+0x25b/0x1310 Call Trace: <TASK> dev_hard_start_xmit+0x1be/0x990 __dev_queue_xmit+0x2c9a/0x3b60 ip6_finish_output2+
_xmit+0x25b/0x1310 Call Trace: <TASK> dev_hard_start_xmit+0x1be/0x990 __dev_queue_xmit+0x2c9a/0x3b60 ip6_finish_output2+0xf92/0x1520 ip6_finish_output+0x6af/0x11e0 ip6_output+0x1ed/0x540 mld_sendpack+0xa09/0xe70 mld_ifc_work+0x71c/0xdb0 process_one_work+0x9bf/0x1710 worker_thread+0x665/0x1080 kthread+0x2e4/0x3a0 ret_from_fork+0x1f/0x30 </TASK> Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/03eb68c72cee249aeb7af7d04a83c033aca3d6d9 - https://git.kernel.org/stable/c/780854186946e0de2be192ee7fa5125666533b3a
CVE ID: CVE-2022-49877 State: PUBLISHED Published: 2025-05-01T14:10:25.682Z Last Updated: 2025-05-04T12:45:20.880Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues When running `test_sockmap` selftests, the following warning appears: WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0 Call Trace: <TASK> inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xd28/0x1380 ? tcp_v4_do_rcv+0x77/0x2c0 tcp_v4_do_rcv+0x77/0x2c0 __release_sock+0x106/0x130 __tcp_close+0x1a7/0x4e0 tcp_close+0x20/0x70 inet_release+0x3c/0x80 __sock_relea
cv+0x77/0x2c0 __release_sock+0x106/0x130 __tcp_close+0x1a7/0x4e0 tcp_close+0x20/0x70 inet_release+0x3c/0x80 __sock_release+0x3a/0xb0 sock_close+0x14/0x20 __fput+0xa3/0x260 task_work_run+0x59/0xb0 exit_to_user_mode_prepare+0x1b3/0x1c0 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x48/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged while msg has more_data"), where I used msg->sg.size to replace the tosend, causing breakage: if (msg->apply_bytes && msg->apply_bytes < tosend) tosend = psock->apply_bytes; References: - https://git.kernel.org/stable/c/d975bec1eaeb52341acc9273db79ddb078220399 - https://git.kernel.org/stab
es; References: - https://git.kernel.org/stable/c/d975bec1eaeb52341acc9273db79ddb078220399 - https://git.kernel.org/stable/c/cc21dc48a78cc9e5af9a4d039cd456446a6e73ff - https://git.kernel.org/stable/c/95adbd2ac8de82e43fd6b347e7e1b47f74dc1abb - https://git.kernel.org/stable/c/14e8bc3bf7bd6af64d7538a0684c8238d96cdfd7 - https://git.kernel.org/stable/c/8ec95b94716a1e4d126edc3fb2bc426a717e2dba
CVE ID: CVE-2022-49878 State: PUBLISHED Published: 2025-05-01T14:10:26.389Z Last Updated: 2025-10-01T16:02:49.951Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf, verifier: Fix memory leak in array reallocation for stack state If an error (NULL) is returned by krealloc(), callers of realloc_array() were setting their allocation pointers to NULL, but on error krealloc() does not touch the original allocation. This would result in a memory resource leak. Instead, free the old allocation on the error handling path. The memory leak information is as follows as also reported by Zhengchao: unreferenced object 0xffff888019801800 (
path. The memory leak information is as follows as also reported by Zhengchao: unreferenced object 0xffff888019801800 (size 256): comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0 [<0000000086712a0b>] krealloc+0x83/0xd0 [<00000000139aab02>] realloc_array+0x82/0xe2 [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186 [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341 [<0000000081780455>] do_check_common+0x5358/0xb350 [<0000000015f6b091>] bpf_check.cold+0xc3/
em_access.cold+0x141/0x1341 [<0000000081780455>] do_check_common+0x5358/0xb350 [<0000000015f6b091>] bpf_check.cold+0xc3/0x29d [<000000002973c690>] bpf_prog_load+0x13db/0x2240 [<00000000028d1644>] __sys_bpf+0x1605/0x4ce0 [<00000000053f29bd>] __x64_sys_bpf+0x75/0xb0 [<0000000056fedaf5>] do_syscall_64+0x35/0x80 [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/06615967d4889b08b19ff3dda96e8b131282f73d - https://git.kernel.org/stable/c/3e210891c4a4c2d858cd6f9f61d5809af251d4df - https://git.kernel.org/stable/c/42378a9ca55347102bbf86708776061d8fe3ece2
CVE ID: CVE-2022-49879 State: PUBLISHED Published: 2025-05-01T14:10:27.117Z Last Updated: 2025-05-04T08:47:39.142Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix BUG_ON() when directory entry has invalid rec_len The rec_len field in the directory entry has to be a multiple of 4. A corrupted filesystem image can be used to hit a BUG() in ext4_rec_len_to_disk(), called from make_indexed_dir(). ------------[ cut here ]------------ kernel BUG at fs/ext4/ext4.h:2413! ... RIP: 0010:make_indexed_dir+0x53f/0x5f0 ... Call Trace: <TASK> ? add_dirent_to_buf+0x1b2/0x200 ext4_add_entry+0x36e/0x480 ext4_add_nondir+0x2b/0xc0 ext4_cr
x5f0 ... Call Trace: <TASK> ? add_dirent_to_buf+0x1b2/0x200 ext4_add_entry+0x36e/0x480 ext4_add_nondir+0x2b/0xc0 ext4_create+0x163/0x200 path_openat+0x635/0xe90 do_filp_open+0xb4/0x160 ? __create_object.isra.0+0x1de/0x3b0 ? _raw_spin_unlock+0x12/0x30 do_sys_openat2+0x91/0x150 __x64_sys_open+0x6c/0xa0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The fix simply adds a call to ext4_check_dir_entry() to validate the directory entry, returning -EFSCORRUPTED if the entry is invalid. References: - https://git.kernel.org/stable/c/2fa24d0274fbf913b56ee31f15bc01168669d909 - https://git.kernel.org/stable/c/156451a67b93986fb07c274ef6995ff40766c5ad - https://git.kernel.org/stable/c/99
8669d909 - https://git.kernel.org/stable/c/156451a67b93986fb07c274ef6995ff40766c5ad - https://git.kernel.org/stable/c/999cff2b6ce3b45c08abf793bf55534777421327 - https://git.kernel.org/stable/c/ce1ee2c8827fb6493e91acbd50f664cf2a972c3d - https://git.kernel.org/stable/c/17a0bc9bd697f75cfdf9b378d5eb2d7409c91340
CVE ID: CVE-2022-49880 State: PUBLISHED Published: 2025-05-01T14:10:27.947Z Last Updated: 2025-10-01T16:11:13.897Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in 'ext4_da_release_space' Syzkaller report issue as follows: EXT4-fs (loop0): Free/Dirty block details EXT4-fs (loop0): free_blocks=0 EXT4-fs (loop0): dirty_blocks=0 EXT4-fs (loop0): Block reservation details EXT4-fs (loop0): i_reserved_data_blocks=0 EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks ------------[ cut here ]------------ WARNING: CPU: 0 PID: 92 at fs/ex
ino 18, to_free 1 with only 0 reserved data blocks ------------[ cut here ]------------ WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524 Modules linked in: CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: writeback wb_workfn (flush-7:0) RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528 RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296 RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00 RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 RBP: 1ffff1100e907d96 R08: ffff
RCX: 42215896cd52ea00 RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5 R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000 R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740 FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461 mpage_r
ffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461 mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589 ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 do_writepages+0x3c3/0x680 mm/page-writeback.c:2469 __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587 writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044 wb_do_writeback fs/fs-writeback.c:2187 [inline] wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30
289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Above issue may happens as follows: ext4_da_write_begin ext4_create_inline_data ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS); ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); __ext4_ioctl ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag ext4_da_write_begin ext4_da_convert_inline_data_to_extent ext4_da_write_inline_data_begin ext4_da_map_blocks ext4_insert_delayed_block if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk)) ext4_clu_mapped(inode
can_clu(inode, &ext4_es_is_delonly, lblk)) if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk)) ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1 allocated = true; ext4_es_insert_delayed_block(inode, lblk, allocated); ext4_writepages mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1 ext4_es_remove_extent ext4_da_release_space(inode, reserved); if (unlikely(to_free > ei->i_reserved_data_blocks)) -> to_free == 1 but ei->i_reserved_data_blocks == 0 -> then trigger warning as above To solve above issue, forbid inode do migrate which has inline data. Additional Analyst Notes:
trigger warning as above To solve above issue, forbid inode do migrate which has inline data. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0de5ee103747fd3a24f1c010c79caabe35e8f0bb - https://git.kernel.org/stable/c/c3bf1e95cfa7d950dc3c064d0c2e3d06b427bc63 - https://git.kernel.org/stable/c/890d738f569fa9412b70ba09f15407f17a52da20 - https://git.kernel.org/stable/c/72743d5598b9096950bbfd6a9b7f173d156eea97 - https://git.kernel.org/stable/c/5370b965b7a945bb8f48b9ee23d83a76a947902e - https://git.kernel.org/stable/c/0a43c015e98121c91a76154edf42280ce1a8a883 - https://git.kernel.org/stable/c/89bee03d2fb8c54119b38ac6c24e7d60fae036b6 - https://git.kern
c91a76154edf42280ce1a8a883 - https://git.kernel.org/stable/c/89bee03d2fb8c54119b38ac6c24e7d60fae036b6 - https://git.kernel.org/stable/c/1b8f787ef547230a3249bcf897221ef0cc78481b
CVE ID: CVE-2022-49881 State: PUBLISHED Published: 2025-05-01T14:10:28.610Z Last Updated: 2025-10-01T16:10:57.930Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix memory leak in query_regdb_file() In the function query_regdb_file() the alpha2 parameter is duplicated using kmemdup() and subsequently freed in regdb_fw_cb(). However, request_firmware_nowait() can fail without calling regdb_fw_cb() and thus leak memory. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/219446396786330937bcd382a7bc4ccd767383bc - https://git.kernel.org/stable/c/0ede1a988299e95d54bd8955
.kernel.org/stable/c/219446396786330937bcd382a7bc4ccd767383bc - https://git.kernel.org/stable/c/0ede1a988299e95d54bd89551fd635980572e920 - https://git.kernel.org/stable/c/e1e12180321f416d83444f2cdc9259e0f5093d35 - https://git.kernel.org/stable/c/38c9fa2cc6bf4b6e1a74057aef8b5cffd23d3264 - https://git.kernel.org/stable/c/e9b5a4566d5bc71cc901be50d1fa24da00613120 - https://git.kernel.org/stable/c/57b962e627ec0ae53d4d16d7bd1033e27e67677a
CVE ID: CVE-2022-49882 State: PUBLISHED Published: 2025-05-01T14:10:29.213Z Last Updated: 2025-05-04T08:47:42.919Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: Reject attempts to consume or refresh inactive gfn_to_pfn_cache Reject kvm_gpc_check() and kvm_gpc_refresh() if the cache is inactive. Not checking the active flag during refresh is particularly egregious, as KVM can end up with a valid, inactive cache, which can lead to a variety of use-after-free bugs, e.g. consuming a NULL kernel pointer or missing an mmu_notifier invalidation due to the cache not being on the list of gfns to invalidate. Note, "active" needs to
ssing an mmu_notifier invalidation due to the cache not being on the list of gfns to invalidate. Note, "active" needs to be set if and only if the cache is on the list of caches, i.e. is reachable via mmu_notifier events. If a relevant mmu_notifier event occurs while the cache is "active" but not on the list, KVM will not acquire the cache's lock and so will not serailize the mmu_notifier event with active users and/or kvm_gpc_refresh(). A race between KVM_XEN_ATTR_TYPE_SHARED_INFO and KVM_XEN_HVM_EVTCHN_SEND can be exploited to trigger the bug. 1. Deactivate shinfo cache: kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO kvm_gpc_deactivate kvm_gpc_unmap gpc->valid = false gpc->khva =
kvm_xen_hvm_set_attr case KVM_XEN_ATTR_TYPE_SHARED_INFO kvm_gpc_deactivate kvm_gpc_unmap gpc->valid = false gpc->khva = NULL gpc->active = false Result: active = false, valid = false 2. Cause cache refresh: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn kvm_xen_set_evtchn_fast kvm_gpc_check return -EWOULDBLOCK because !gpc->valid kvm_xen_set_evtchn_fast return -EWOULDBLOCK kvm_gpc_refresh hva_to_pfn_retry gpc->valid = true gpc->khva = not NULL Result: active = false, valid = true 3. Race ioctl KVM_XEN_HVM_EVTCHN_SEND against ioctl KVM_XEN_ATTR_TYPE_SHARED_INFO: kvm_arch_vm_ioctl case KVM_XEN_HVM_EVTCHN_SEND kvm_xen_hvm_evtchn_send kvm_xen_set_evtchn