Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
y in callers to qede_build_skb(). References: - https://git.kernel.org/stable/c/9648adb1b3ece55c657d3a4f52bfee663b710dfe - https://git.kernel.org/stable/c/034a92c6a81048128fc7b18d278d52438a13902a - https://git.kernel.org/stable/c/8928239e5e2e460d95b8a0b89f61671625e7ece0 - https://git.kernel.org/stable/c/c9bdce2359b5f4986eb38d1e81865b3586cc20d2 - https://git.kernel.org/stable/c/b2d6b3db9d1cf80908964036dbe1c52a86b1afb1 - https://git.kernel.org/stable/c/e1fd0c42acfa22bb34d2ab6a111484f466ab8093 - https://git.kernel.org/stable/c/4e910dbe36508654a896d5735b318c0b88172570
CVE ID: CVE-2022-49085 State: PUBLISHED Published: 2025-02-26T01:54:43.579Z Last Updated: 2025-05-04T08:29:24.372Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drbd: Fix five use after free bugs in get_initial_state In get_initial_state, it calls notify_initial_state_done(skb,..) if cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(), the skb will be freed by nlmsg_free(skb). Then get_initial_state will goto out and the freed skb will be used by return value skb->len, which is a uaf bug. What's worse, the same problem goes even further: skb can also be freed in the notify_*_state_change -> notify_*_state ca
hat's worse, the same problem goes even further: skb can also be freed in the notify_*_state_change -> notify_*_state calls below. Thus 4 additional uaf bugs happened. My patch lets the problem callee functions: notify_initial_state_done and notify_*_state_change return an error code if errors happen. So that the error codes could be propagated and the uaf bugs can be avoid. v2 reports a compilation warning. This v3 fixed this warning and built successfully in my local environment with no additional warnings. v2: https://lore.kernel.org/patchwork/patch/1435218/ Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0489700bfeb1e53eb2039c2291c67e71b0b
nalyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0489700bfeb1e53eb2039c2291c67e71b0b40103 - https://git.kernel.org/stable/c/dcf6be17b5c53b741898d2223b23e66d682de300 - https://git.kernel.org/stable/c/188fe6b26765edbad4055611c0f788b6870f4024 - https://git.kernel.org/stable/c/b6a4055036eed1f5e239ce3d8b0db1ce38bba447 - https://git.kernel.org/stable/c/594205b4936771a250f9d141e7e0fff21c3dd2d9 - https://git.kernel.org/stable/c/a972c768723359ec995579902473028fe3cd64b1 - https://git.kernel.org/stable/c/de63e74da2333b4068bb79983e632db730fea97e - https://git.kernel.org/stable/c/226e993c39405292781bfcf4b039a8db56aab362 - https://git.kernel.org/stable/c/aadb22ba2f65658
tps://git.kernel.org/stable/c/226e993c39405292781bfcf4b039a8db56aab362 - https://git.kernel.org/stable/c/aadb22ba2f656581b2f733deb3a467c48cc618f6
CVE ID: CVE-2022-49086 State: PUBLISHED Published: 2025-02-26T01:54:44.072Z Last Updated: 2025-05-04T08:29:25.798Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix leak of nested actions While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions. Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory. For example, removal
d nested lists of actions and ovs_nla_free_flow_actions() just jumps over them leaking the memory. For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nf_ct_tmpl_alloc(): actions:clone(ct(commit),0) Non-freed set() action may also leak the 'dst' structure for the tunnel info including device references. Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter's case). The problem is also hard to mitigate, because the user doesn't have direct control over the datapath flows generated by OVS. Fix that by iterating over all the nested actions and freeing everything
ntrol over the datapath flows generated by OVS. Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively. New build time assertion should protect us from this problem if new actions will be added in the future. Unfortunately, openvswitch module doesn't use NLA_F_NESTED, so all attributes has to be explicitly checked. sample() and clone() actions are mixing extra attributes into the user-provided action list. That prevents some code generalization too. References: - https://git.kernel.org/stable/c/7438dc55c0709819b813f4778aec2c48b782990b - https://git.kernel.org/stable/c/ef6f9ce0a79aa23b10fc5f3b3cab3814a25aac40 - https://git.kernel.org/stable
c2c48b782990b - https://git.kernel.org/stable/c/ef6f9ce0a79aa23b10fc5f3b3cab3814a25aac40 - https://git.kernel.org/stable/c/5ae05b5eb58773cfec307ff88aff4cfd843c4cff - https://git.kernel.org/stable/c/837b96d8103938e35e7d92cd9db96af914ca4fff - https://git.kernel.org/stable/c/3554c214b83ec9a839ed574263a34218f372990c - https://git.kernel.org/stable/c/53bce9d19b0a9d245b25cd050b81652ed974a509 - https://git.kernel.org/stable/c/1f30fb9166d4f15a1aa19449b9da871fe0ed4796
CVE ID: CVE-2022-49087 State: PUBLISHED Published: 2025-02-26T01:54:44.557Z Last Updated: 2025-05-04T08:29:27.039Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix a race in rxrpc_exit_net() Current code can lead to the following race: CPU0 CPU1 rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->live) rxnet->live = false; del_timer_sync(&rxnet->peer_keepalive_timer); timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay); cancel_work_sync(&rxnet->peer_keepalive_work); rxrpc_exit_net() exits while peer_keepalive_timer is still armed, leading to use-after-free. syzbot report was: ODEBUG: free active (active s
s while peer_keepalive_timer is still armed, leading to use-after-free. syzbot report was: ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0 WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Modules linked in: CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00
jects.c:505 Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0 R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000
00000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __debug_check_no_obj_freed lib/debugobjects.c:992 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176 ops_free_list net/core/net_namespace.c:174 [inline] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 ker
core/net_namespace.c:174 [inline] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 </TASK> Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/864297ee30727ae6233f80296b7fc91442620b05 - https://git.kernel.org/stable/c/7ee84d29f22de6f6c63fad6c54690517659862f1 - https://git.kernel.org/stable/c/08ff0e74fab517dbc44e11b8bc683dd4ecc65950 - https://git.kernel.org/stable/c/571d8e1d154ca18f08dcb72b69318d36e10010a0 - https://git.kernel.org/stable/c/41024a40
50 - https://git.kernel.org/stable/c/571d8e1d154ca18f08dcb72b69318d36e10010a0 - https://git.kernel.org/stable/c/41024a40f6c793abbb916a857f18fb009f07464c - https://git.kernel.org/stable/c/cd8aef1f30d1215648e4e6686cfb422004851429 - https://git.kernel.org/stable/c/1946014ca3b19be9e485e780e862c375c6f98bad
CVE ID: CVE-2022-49088 State: PUBLISHED Published: 2025-02-26T01:54:45.165Z Last Updated: 2025-05-04T08:29:28.243Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dpaa2-ptp: Fix refcount leak in dpaa2_ptp_probe This node pointer is returned by of_find_compatible_node() with refcount incremented. Calling of_node_put() to aovid the refcount leak. References: - https://git.kernel.org/stable/c/fbe5f4c0dd3475178f17ddd8b8d5044ebeae0be7 - https://git.kernel.org/stable/c/ebd1e3458dbf6643aa0272da398cb5b537d492b7 - https://git.kernel.org/stable/c/599874bbc4ed832ccb578d48ac0ae7344382ef43 - https://git.kernel.org/stable/c/46d120f7c163706d6c
://git.kernel.org/stable/c/599874bbc4ed832ccb578d48ac0ae7344382ef43 - https://git.kernel.org/stable/c/46d120f7c163706d6c31ee00baa0be64c4572b78 - https://git.kernel.org/stable/c/45fdd98b70142521739615ad1bfb760401863b73 - https://git.kernel.org/stable/c/2b04bd4f03bba021959ca339314f6739710f0954
CVE ID: CVE-2022-49089 State: PUBLISHED Published: 2025-02-26T01:54:45.743Z Last Updated: 2025-05-04T12:44:16.832Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition The documentation of the function rvt_error_qp says both r_lock and s_lock need to be held when calling that function. It also asserts using lockdep that both of those locks are held. However, the commit I referenced in Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race conditio
loopback no longer covered by r_lock. This results in the lockdep assertion failing and also possibly in a race condition. References: - https://git.kernel.org/stable/c/8a50937227c385a477177c9ffa122b4230e40666 - https://git.kernel.org/stable/c/43c2d7890ecabe527448a6c391fb2d9a5e6bbfe0 - https://git.kernel.org/stable/c/92f1947c0d26060e978b3a9f21f32ce7c8c9cca3 - https://git.kernel.org/stable/c/77ffb2495a41098f9d6a14f8aefde3188da75944 - https://git.kernel.org/stable/c/57800cc36e55db0547461c49acf5cd84c0f502b0 - https://git.kernel.org/stable/c/4d809f69695d4e7d1378b3a072fa9aef23123018
CVE ID: CVE-2022-49090 State: PUBLISHED Published: 2025-02-26T01:54:46.227Z Last Updated: 2025-05-04T08:29:30.905Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arch/arm64: Fix topology initialization for core scheduling Arm64 systems rely on store_cpu_topology() to call update_siblings_masks() to transfer the toplogy to the various cpu masks. This needs to be done before the call to notify_cpu_starting() which tells the scheduler about each cpu found, otherwise the core scheduling data structures are setup in a way that does not match the actual topology. With smt_mask not setup correctly we bail on `cpumask_weight(smt_mask)
n a way that does not match the actual topology. With smt_mask not setup correctly we bail on `cpumask_weight(smt_mask) == 1` for !leaders in: notify_cpu_starting() cpuhp_invoke_callback_range() sched_cpu_starting() sched_core_cpu_starting() which leads to rq->core not being correctly set for !leader-rq's. Without this change stress-ng (which enables core scheduling in its prctl tests in newer versions -- i.e. with PR_SCHED_CORE support) causes a warning and then a crash (trimmed for legibility): [ 1853.805168] ------------[ cut here ]------------ [ 1853.809784] task_rq(b)->core != rq->core [ 1853.809792] WARNING: CPU: 117 PID: 0 at kernel/sched/fair.c:11102 cfs_prio_less+0x1b4/0x1c4 ... [ 1
>core != rq->core [ 1853.809792] WARNING: CPU: 117 PID: 0 at kernel/sched/fair.c:11102 cfs_prio_less+0x1b4/0x1c4 ... [ 1854.015210] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... [ 1854.231256] Call trace: [ 1854.233689] pick_next_task+0x3dc/0x81c [ 1854.237512] __schedule+0x10c/0x4cc [ 1854.240988] schedule_idle+0x34/0x54 References: - https://git.kernel.org/stable/c/87f5d66daa5f457449bb95d6b8d18bb7596aa627 - https://git.kernel.org/stable/c/790c1567582bda8f1153015436e3330a7c6eb278 - https://git.kernel.org/stable/c/c78a1b2d0bff678570c8dc9f14035606f5e5257d - https://git.kernel.org/stable/c/5524cbb1bfcdff0cad0aaa9f94e6092002a07259
CVE ID: CVE-2022-49091 State: PUBLISHED Published: 2025-02-26T01:54:46.701Z Last Updated: 2025-05-04T08:29:31.995Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/imx: Fix memory leak in imx_pd_connector_get_modes Avoid leaking the display mode variable if of_get_drm_display_mode fails. Addresses-Coverity-ID: 1443943 ("Resource leak") References: - https://git.kernel.org/stable/c/d2c2758cfb0262637fd93350bdc8ad485fb1dd61 - https://git.kernel.org/stable/c/38bf605bd8c83d942c8dcffaef3633b7d8b37549 - https://git.kernel.org/stable/c/41624d7c0c3df71dee170c610744aaa5909327b8 - https://git.kernel.org/stable/c/c539a6a5896ed92bfb91494e
.kernel.org/stable/c/41624d7c0c3df71dee170c610744aaa5909327b8 - https://git.kernel.org/stable/c/c539a6a5896ed92bfb91494e46996d013f3d5967 - https://git.kernel.org/stable/c/f8b0ef0a5889890b50482b6593bd8de544736351 - https://git.kernel.org/stable/c/31e449302ed00c38d4068443cf0243279701ab28 - https://git.kernel.org/stable/c/bc23c327e1a23cc3555fa1e86288e13288515442 - https://git.kernel.org/stable/c/7526102d908ec5ae777aa77723d52fce12916093 - https://git.kernel.org/stable/c/bce81feb03a20fca7bbdd1c4af16b4e9d5c0e1d3
CVE ID: CVE-2022-49092 State: PUBLISHED Published: 2025-02-26T01:54:47.172Z Last Updated: 2025-05-04T08:29:38.189Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ipv4: fix route with nexthop object delete warning FRR folks have hit a kernel warning[1] while deleting routes[2] which is caused by trying to delete a route pointing to a nexthop id without specifying nhid but matching on an interface. That is, a route is found but we hit a warning while matching it. The warning is from fib_info_nh() in include/net/nexthop.h because we run it on a fib_info with nexthop object. The call chain is: inet_rtm_delroute -> fib_table_de
/net/nexthop.h because we run it on a fib_info with nexthop object. The call chain is: inet_rtm_delroute -> fib_table_delete -> fib_nh_match (called with a nexthop fib_info and also with fc_oif set thus calling fib_info_nh on the fib_info and triggering the warning). The fix is to not do any matching in that branch if the fi has a nexthop object because those are managed separately. I.e. we should match when deleting without nh spec and should fail when deleting a nexthop route with old-style nh spec because nexthop objects are managed separately, e.g.: $ ip r show 1.2.3.4/32 1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0 $ ip r del 1.2.3.4/32 $ ip r del 1.2.3.4/32 nhid 12 <both should work> $
32 1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0 $ ip r del 1.2.3.4/32 $ ip r del 1.2.3.4/32 nhid 12 <both should work> $ ip r del 1.2.3.4/32 dev dummy0 <should fail with ESRCH> [1] [ 523.462226] ------------[ cut here ]------------ [ 523.462230] WARNING: CPU: 14 PID: 22893 at include/net/nexthop.h:468 fib_nh_match+0x210/0x460 [ 523.462236] Modules linked in: dummy rpcsec_gss_krb5 xt_socket nf_socket_ipv4 nf_socket_ipv6 ip6table_raw iptable_raw bpf_preload xt_statistic ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs xt_mark nf_tables xt_nat veth nf_conntrack_netlink nfnetlink xt_addrtype br_netfilter overlay dm_crypt nfsv3 nfs fscache netfs vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM xt_MASQUERAD
rtype br_netfilter overlay dm_crypt nfsv3 nfs fscache netfs vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack 8021q garp mrp ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bridge stp llc rfcomm snd_seq_dummy snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core ip6table_filter xt_comment ip6_tables vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) qrtr bnep binfmt_misc xfs vfat fat squashfs loop nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(POE) nvidia(POE) intel_rapl_msr intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi btusb btrtl iwlm
rapl_msr intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi btusb btrtl iwlmvm uvcvideo btbcm snd_hda_intel edac_mce_amd [ 523.462274] videobuf2_vmalloc videobuf2_memops btintel snd_intel_dspcfg videobuf2_v4l2 snd_intel_sdw_acpi bluetooth snd_usb_audio snd_hda_codec mac80211 snd_usbmidi_lib joydev snd_hda_core videobuf2_common kvm_amd snd_rawmidi snd_hwdep snd_seq videodev ccp snd_seq_device libarc4 ecdh_generic mc snd_pcm kvm iwlwifi snd_timer drm_kms_helper snd cfg80211 cec soundcore irqbypass rapl wmi_bmof i2c_piix4 rfkill k10temp pcspkr acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc drm zram ip_tables crct10dif_pclmul crc32_pclmul crc
emp pcspkr acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc drm zram ip_tables crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel nvme sp5100_tco r8169 nvme_core wmi ipmi_devintf ipmi_msghandler fuse [ 523.462300] CPU: 14 PID: 22893 Comm: ip Tainted: P OE 5.16.18-200.fc35.x86_64 #1 [ 523.462302] Hardware name: Micro-Star International Co., Ltd. MS-7C37/MPG X570 GAMING EDGE WIFI (MS-7C37), BIOS 1.C0 10/29/2020 [ 523.462303] RIP: 0010:fib_nh_match+0x210/0x460 [ 523.462304] Code: 7c 24 20 48 8b b5 90 00 00 00 e8 bb ee f4 ff 48 8b 7c 24 20 41 89 c4 e8 ee eb f4 ff 45 85 e4 0f 85 2e fe ff ff e9 4c ff ff ff <0f> 0b e9 17 ff ff ff 3c 0a 0f 85 61 fe ff ff 48 8b b5 98 00 00 00 [ 52
f4 ff 45 85 e4 0f 85 2e fe ff ff e9 4c ff ff ff <0f> 0b e9 17 ff ff ff 3c 0a 0f 85 61 fe ff ff 48 8b b5 98 00 00 00 [ 523.462306] RSP: 0018:ffffaa53d4d87928 EFLAGS: 00010286 [ 523.462307] RAX: 0000000000000000 RBX: ffffaa53d4d87a90 RCX: ffffaa53d4d87bb0 [ 523.462308] RDX: ffff9e3d2ee6be80 RSI: ffffaa53d4d87a90 RDI: ffffffff920ed380 [ 523.462309] RBP: ffff9e3d2ee6be80 R08: 0000000000000064 R09: 0000000000000000 [ 523.462310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000031 [ 523.462310] R13: 0000000000000020 R14: 0000000000000000 R15: ffff9e3d331054e0 [ 523.462311] FS: 00007f2455 ---truncated--- References: - https://git.kernel.org/stable/c/f5064531c23ad646da7be8b938292b00a7e
462311] FS: 00007f2455 ---truncated--- References: - https://git.kernel.org/stable/c/f5064531c23ad646da7be8b938292b00a7e61438 - https://git.kernel.org/stable/c/63ea57478aaa3e06a597081a0f537318fc04e49f - https://git.kernel.org/stable/c/907c97986d6fa77318d17659dd76c94b65dd27c5 - https://git.kernel.org/stable/c/dcd689f9e2640c992f94eae9955b106f71c6825d - https://git.kernel.org/stable/c/f8db5743d09523c0bb35f16e13691e3b7eb5dba0 - https://git.kernel.org/stable/c/6bf92d70e690b7ff12b24f4bfff5e5434d019b82
CVE ID: CVE-2022-49093 State: PUBLISHED Published: 2025-02-26T01:54:47.669Z Last Updated: 2025-05-04T08:29:44.316Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: skbuff: fix coalescing for page_pool fragment recycling Fix a use-after-free when using page_pool with page fragments. We encountered this problem during normal RX in the hns3 driver: (1) Initially we have three descriptors in the RX queue. The first one allocates PAGE1 through page_pool, and the other two allocate one half of PAGE2 each. Page references look like this: RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 _________/ (2) Handle RX on the first descriptor. A
ces look like this: RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 _________/ (2) Handle RX on the first descriptor. Allocate SKB1, eventually added to the receive queue by tcp_queue_rcv(). (3) Handle RX on the second descriptor. Allocate SKB2 and pass it to netif_receive_skb(): netif_receive_skb(SKB2) ip_rcv(SKB2) SKB3 = skb_clone(SKB2) SKB2 and SKB3 share a reference to PAGE2 through skb_shinfo()->dataref. The other ref to PAGE2 is still held by RX_BD3: SKB2 ---+- PAGE2 SKB3 __/ / RX_BD3 _________/ (3b) Now while handling TCP, coalesce SKB3 with SKB1: tcp_v4_rcv(SKB3) tcp_try_coalesce(to=SKB1, from=SKB3) // succeeds kfree_skb_partial(SKB3) skb_release_data(SKB3) // drops one dataref SKB1
cp_try_coalesce(to=SKB1, from=SKB3) // succeeds kfree_skb_partial(SKB3) skb_release_data(SKB3) // drops one dataref SKB1 _____ PAGE1 \____ SKB2 _____ PAGE2 / RX_BD3 _________/ In skb_try_coalesce(), __skb_frag_ref() takes a page reference to PAGE2, where it should instead have increased the page_pool frag reference, pp_frag_count. Without coalescing, when releasing both SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now when releasing SKB1 and SKB2, two references to PAGE2 will be dropped, resulting in underflow. (3c) Drop SKB2: af_packet_rcv(SKB2) consume_skb(SKB2) skb_release_data(SKB2) // drops second dataref page_pool_return_skb_page(PAGE2) // drops one pp_frag_count SKB1 _
(SKB2) skb_release_data(SKB2) // drops second dataref page_pool_return_skb_page(PAGE2) // drops one pp_frag_count SKB1 _____ PAGE1 \____ PAGE2 / RX_BD3 _________/ (4) Userspace calls recvmsg() Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we release the SKB3 page as well: tcp_eat_recv_skb(SKB1) skb_release_data(SKB1) page_pool_return_skb_page(PAGE1) page_pool_return_skb_page(PAGE2) // drops second pp_frag_count (5) PAGE2 is freed, but the third RX descriptor was still using it! In our case this causes IOMMU faults, but it would silently corrupt memory if the IOMMU was disabled. Change the logic that checks whether pp_recycle SKBs can be coalesced. We still reject differing
the IOMMU was disabled. Change the logic that checks whether pp_recycle SKBs can be coalesced. We still reject differing pp_recycle between 'from' and 'to' SKBs, but in order to avoid the situation described above, we also reject coalescing when both 'from' and 'to' are pp_recycled and 'from' is cloned. The new logic allows coalescing a cloned pp_recycle SKB into a page refcounted one, because in this case the release (4) will drop the right reference, the one taken by skb_try_coalesce(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ba965e8605aee5387cecaa28fcf7ee9f61779a49 - https://git.kernel.org/stable/c/c4fa19615806a9a7e518c295b39175aa47
g/stable/c/ba965e8605aee5387cecaa28fcf7ee9f61779a49 - https://git.kernel.org/stable/c/c4fa19615806a9a7e518c295b39175aa47a685ac - https://git.kernel.org/stable/c/72bb856d16e883437023ff2ff77d0c498018728a - https://git.kernel.org/stable/c/1effe8ca4e34c34cdd9318436a4232dcb582ebf4