Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-50468 State: PUBLISHED Published: 2025-10-01T11:45:38.881Z Last Updated: 2025-10-01T11:45:38.881Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init() The following WARNING message was given when rmmod cros_usbpd_notify: Unexpected driver unregister! WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0 Modules linked in: cros_usbpd_notify(-) CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24 ... Call Trace: <TASK> cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify] __x64_sys_delete_module+0x3c7/0x570 ?
3 #24 ... Call Trace: <TASK> cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify] __x64_sys_delete_module+0x3c7/0x570 ? __ia32_sys_delete_module+0x570/0x570 ? lock_is_held_type+0xe3/0x140 ? syscall_enter_from_user_mode+0x17/0x50 ? rcu_read_lock_sched_held+0xa0/0xd0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f333fe9b1b7 The reason is that the cros_usbpd_notify_init() does not check the return value of platform_driver_register(), and the cros_usbpd_notify can install successfully even if platform_driver_register() failed. Fix by checking the return value of platform_driver_register() and unregister cros_usbpd_notify_pl
er_register() failed. Fix by checking the return value of platform_driver_register() and unregister cros_usbpd_notify_plat_driver when it failed. References: - https://git.kernel.org/stable/c/5c0cacdd354987f8f5348d16908716f154047890 - https://git.kernel.org/stable/c/cab345f9d51943898e406275f9607c145adb1877 - https://git.kernel.org/stable/c/7b6ee54995739202b4a0cc01b7e9269f761c573d - https://git.kernel.org/stable/c/751f12696d797e785d2611099fe9f0569d47556e - https://git.kernel.org/stable/c/5a2d96623670155d94aca72c320c0ac27bdc6bd2
CVE ID: CVE-2022-50469 State: PUBLISHED Published: 2025-10-01T11:45:39.811Z Last Updated: 2025-10-02T07:04:18.862Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix potential memory leak in rtw_init_drv_sw() In rtw_init_drv_sw(), there are various init functions are called to populate the padapter structure and some checks for their return value. However, except for the first one error path, the other five error paths do not properly release the previous allocated resources, which leads to various memory leaks. This patch fixes them and keeps the success and error separate. Note that these changes keep the
various memory leaks. This patch fixes them and keeps the success and error separate. Note that these changes keep the form of `rtw_init_drv_sw()` in "drivers/staging/r8188eu/os_dep/os_intfs.c". As there is no proper device to test with, no runtime testing was performed. References: - https://git.kernel.org/stable/c/b4573a2bad3c3e2643ef3939079eb7035a30e6ee - https://git.kernel.org/stable/c/6b2052b365f8035ab7f09ac24b5b499002b298cb - https://git.kernel.org/stable/c/d95d1526d9f06978c1a7186810a5490d72c62742 - https://git.kernel.org/stable/c/5a5aa9cce621e2c0e25a1e5d72d6be1749167cc0
CVE ID: CVE-2022-50470 State: PUBLISHED Published: 2025-10-04T15:16:32.764Z Last Updated: 2025-10-04T15:16:32.764Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xhci: Remove device endpoints from bandwidth list when freeing the device Endpoints are normally deleted from the bandwidth list when they are dropped, before the virt device is freed. If xHC host is dying or being removed then the endpoints aren't dropped cleanly due to functions returning early to avoid interacting with a non-accessible host controller. So check and delete endpoints that are still on the bandwidth list when freeing the virt device. Solves a list_del
ler. So check and delete endpoints that are still on the bandwidth list when freeing the virt device. Solves a list_del corruption kernel crash when unbinding xhci-pci, caused by xhci_mem_cleanup() when it later tried to delete already freed endpoints from the bandwidth list. This only affects hosts that use software bandwidth checking, which currenty is only the xHC in intel Panther Point PCH (Ivy Bridge) References: - https://git.kernel.org/stable/c/5e4ce28ad907aa54f13b21d5f1dc490525957b0c - https://git.kernel.org/stable/c/f0de39474078adef6ece7a183e34c15ce2c1d8d1 - https://git.kernel.org/stable/c/cebbc8d335d6bcc1316584f779c08f80287c6af8 - https://git.kernel.org/stable/c/8f1cd9633d1f21efc13
//git.kernel.org/stable/c/cebbc8d335d6bcc1316584f779c08f80287c6af8 - https://git.kernel.org/stable/c/8f1cd9633d1f21efc13e8fc75be8f2b6bb85e38c - https://git.kernel.org/stable/c/678d2cc2041cc6ce05030852dce9ad42719abcfc - https://git.kernel.org/stable/c/c892a81c7424b4f6a660cb9c249d354ccf3afeca - https://git.kernel.org/stable/c/3bf860a41e0f2fcea0ac3aae8f7ef887a7994b70 - https://git.kernel.org/stable/c/5aed5b7c2430ce318a8e62f752f181e66f0d1053
CVE ID: CVE-2022-50471 State: PUBLISHED Published: 2025-10-04T15:16:33.489Z Last Updated: 2025-10-04T15:16:33.489Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xen/gntdev: Accommodate VMA splitting Prior to this commit, the gntdev driver code did not handle the following scenario correctly with paravirtualized (PV) Xen domains: * User process sets up a gntdev mapping composed of two grant mappings (i.e., two pages shared by another Xen domain). * User process munmap()s one of the pages. * User process munmap()s the remaining page. * User process exits. In the scenario above, the user process would cause the kernel to log the
()s the remaining page. * User process exits. In the scenario above, the user process would cause the kernel to log the following messages in dmesg for the first munmap(), and the second munmap() call would result in similar log messages: BUG: Bad page map in process doublemap.test pte:... pmd:... page:0000000057c97bff refcount:1 mapcount:-1 \ mapping:0000000000000000 index:0x0 pfn:... ... page dumped because: bad pte ... file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0 ... Call Trace: <TASK> dump_stack_lvl+0x46/0x5e print_bad_pte.cold+0x66/0xb6 unmap_page_range+0x7e5/0xdc0 unmap_vmas+0x78/0xf0 unmap_region+0xa8/0x110 __do_munmap+0x1ea/0x4e0 __vm_munmap+0x75/0x120 __x64_sys_m
ange+0x7e5/0xdc0 unmap_vmas+0x78/0xf0 unmap_region+0xa8/0x110 __do_munmap+0x1ea/0x4e0 __vm_munmap+0x75/0x120 __x64_sys_munmap+0x28/0x40 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb ... For each munmap() call, the Xen hypervisor (if built with CONFIG_DEBUG) would print out the following and trigger a general protection fault in the affected Xen PV domain: (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ... (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ... As of this writing, gntdev_grant_map structure's vma field (referred to as map->vma below) is mainly used for checking the start and end addresses of mappings. However, with split VMAs, these may change,
below) is mainly used for checking the start and end addresses of mappings. However, with split VMAs, these may change, and there could be more than one VMA associated with a gntdev mapping. Hence, remove the use of map->vma and rely on map->pages_vm_start for the original start address and on (map->count << PAGE_SHIFT) for the original mapping size. Let the invalidate() and find_special_page() hooks use these. Also, given that there can be multiple VMAs associated with a gntdev mapping, move the "mmu_interval_notifier_remove(&map->notifier)" call to the end of gntdev_put_map, so that the MMU notifier is only removed after the closing of the last remaining VMA. Finally, use an atomic to pre
map, so that the MMU notifier is only removed after the closing of the last remaining VMA. Finally, use an atomic to prevent inadvertent gntdev mapping re-use, instead of using the map->live_grants atomic counter and/or the map->vma pointer (the latter of which is now removed). This prevents the userspace from mmap()'ing (with MAP_FIXED) a gntdev mapping over the same address range as a previously set up gntdev mapping. This scenario can be summarized with the following call-trace, which was valid prior to this commit: mmap gntdev_mmap mmap (repeat mmap with MAP_FIXED over the same address range) gntdev_invalidate unmap_grant_pages (sets 'being_removed' entries to true) gnttab_unmap_refs_asy
the same address range) gntdev_invalidate unmap_grant_pages (sets 'being_removed' entries to true) gnttab_unmap_refs_async unmap_single_vma gntdev_mmap (maps the shared pages again) munmap gntdev_invalidate unmap_grant_pages (no-op because 'being_removed' entries are true) unmap_single_vma (For PV domains, Xen reports that a granted page is being unmapped and triggers a general protection fault in the affected domain, if Xen was built with CONFIG_DEBUG) The fix for this last scenario could be worth its own commit, but we opted for a single commit, because removing the gntdev_grant_map structure's vma field requires guarding the entry to gntdev_mmap(), and the live_grants atomic counter is no
v_grant_map structure's vma field requires guarding the entry to gntdev_mmap(), and the live_grants atomic counter is not sufficient on its own to prevent the mmap() over a pre-existing mapping. References: - https://git.kernel.org/stable/c/3c6a888e352283a14f37b9b433cd598a1a3a7dd0 - https://git.kernel.org/stable/c/7c16d0a4e6a436b4e7c92bead3fab55aaa4c1141 - https://git.kernel.org/stable/c/4fb4053d90caa9985b87ec0e0c32c66a55bdfa3a - https://git.kernel.org/stable/c/cdafa219ace013c594e2491158ad1b51f9923dde - https://git.kernel.org/stable/c/5c13a4a0291b30191eff9ead8d010e1ca43a4d0c
CVE ID: CVE-2022-50472 State: PUBLISHED Published: 2025-10-04T15:16:34.180Z Last Updated: 2025-10-04T15:16:34.180Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: IB/mad: Don't call to function that might sleep while in atomic context Tracepoints are not allowed to sleep, as such the following splat is generated due to call to ib_query_pkey() in atomic context. WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220 CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2
--------- - - 4.18.0-305.3.1.el8.x86_64 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:rb_commit+0xc1/0x220 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246 R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 00000000800
FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0 Call Trace: ring_buffer_unlock_commit+0x1d/0xa0 trace_buffer_unlock_commit_regs+0x3b/0x1b0 trace_event_buffer_commit+0x67/0x1d0 trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core] ib_mad_recv_done+0x48b/0xc10 [ib_core] ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core] __ib_process_cq+0x91/0x1c0 [ib_core] ib_cq_poll_work+0x26/0x80 [ib_core] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_w
0 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 78ba8509d3830a16 ]--- References: - https://git.kernel.org/stable/c/47e31b86edff36f2d26cbc88ce695d98ff804178 - https://git.kernel.org/stable/c/cea70a572c0cb9728d728cfebe7d5bd485e97513 - https://git.kernel.org/stable/c/fa8a2f3be78e4585996bcf4c15e4504441a4c7a0 - https://git.kernel.org/stable/c/5c20311d76cbaeb7ed2ecf9c8b8322f8fc4a7ae3
CVE ID: CVE-2022-50473 State: PUBLISHED Published: 2025-10-04T15:16:34.859Z Last Updated: 2025-10-04T15:16:34.859Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq: Init completion before kobject_init_and_add() In cpufreq_policy_alloc(), it will call uninitialed completion in cpufreq_sysfs_release() when kobject_init_and_add() fails. And that will cause a crash such as the following page fault in complete: BUG: unable to handle page fault for address: fffffffffffffff8 [..] RIP: 0010:complete+0x98/0x1f0 [..] Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_regi
..] Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_register+0x3f5/0x4e0 cpufreq_register_driver+0x3b7/0x670 acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq] do_one_initcall+0x13d/0x780 do_init_module+0x1c3/0x630 load_module+0x6e67/0x73b0 __do_sys_finit_module+0x181/0x240 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/3cdd91a9163248935720927531066b74f57aa43b - https://git.kernel.org/stable/c/e379b88a8f8cffc99b318e028705ed9e3da0e1e0 - https://git.kernel.org/stable/c/8fb4c98f20dfca1237de2e3dfdbe78d156784fd3 - https://git.kernel.org/stable/c/d88540acfc7a17079021d866de9141
l.org/stable/c/8fb4c98f20dfca1237de2e3dfdbe78d156784fd3 - https://git.kernel.org/stable/c/d88540acfc7a17079021d866de914112c396edb1 - https://git.kernel.org/stable/c/e7c0c943ed675b66d4bbb16c51c6a3bb58da047e - https://git.kernel.org/stable/c/5c51054896bcce1d33d39fead2af73fec24f40b6
CVE ID: CVE-2022-50474 State: PUBLISHED Published: 2025-10-04T15:16:35.537Z Last Updated: 2025-10-04T15:16:35.537Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: macintosh: fix possible memory leak in macio_add_one_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically. It needs to be freed when of_device_register() fails. Call put_device() to give up the reference that's taken in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hits 0. macio device is freed in macio_release_dev(), so the kfree() can be rem
d in kobject_cleanup() when the refcount hits 0. macio device is freed in macio_release_dev(), so the kfree() can be removed. References: - https://git.kernel.org/stable/c/3a866ff6fc2232c8e393cdb55ffb8ce947349e03 - https://git.kernel.org/stable/c/aa9054267366ff0a382d403d17728e21951ddbb9 - https://git.kernel.org/stable/c/35858b87a943917fa30172aa4bf01ce7adbcb42c - https://git.kernel.org/stable/c/b29a2f1dd33ae9b94821ab2f4d398b9081786748 - https://git.kernel.org/stable/c/2ac0a7059b7bcbed35bfffa34a82c9a9e99638ef - https://git.kernel.org/stable/c/19ded60b40e86b0903c8d5bd0161437ed5107a8b - https://git.kernel.org/stable/c/ca765257feb89dacf604ced9cd233db5f865dee0 - https://git.kernel.org/stable/c/768
5107a8b - https://git.kernel.org/stable/c/ca765257feb89dacf604ced9cd233db5f865dee0 - https://git.kernel.org/stable/c/76837e7f6b30da72ad59f56291e22804a219e015 - https://git.kernel.org/stable/c/5ca86eae55a2f006e6c1edd2029b2cacb6979515
CVE ID: CVE-2022-50475 State: PUBLISHED Published: 2025-10-04T15:16:36.235Z Last Updated: 2025-10-04T15:16:36.235Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Make sure "ib_port" is valid when access sysfs node The "ib_port" structure must be set before adding the sysfs kobject, and reset after removing it, otherwise it may crash when accessing the sysfs node: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x96000006 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR
BT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5 [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000 Internal error: Oops: 96000006 [#2] PREEMPT SMP Modules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O)
pmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci] Process grep (pid: 3372, stack limit = 0x0000000022055c92) CPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022 pstate: 40000005 (nZcv daif -PAN -UAO) pc : hw_stat_port_show+0x4
Field SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022 pstate: 40000005 (nZcv daif -PAN -UAO) pc : hw_stat_port_show+0x4c/0x80 [ib_core] lr : port_attr_show+0x40/0x58 [ib_core] sp : ffff000029f43b50 x29: ffff000029f43b50 x28: 0000000019375000 x27: ffff8007b821a540 x26: ffff000029f43e30 x25: 0000000000008000 x24: ffff000000eaa958 x23: 0000000000001000 x22: ffff8007a4ce3000 x21: ffff8007baff8000 x20: ffff8007b9066ac0 x19: ffff8007bae97578 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff8007a4ce4000 x7 : 000000000000
00000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff8007a4ce4000 x7 : 0000000000000000 x6 : 000000000000003f x5 : ffff000000e6a280 x4 : ffff8007a4ce3000 x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab x1 : ffff8007b9066a10 x0 : ffff8007baff8000 Call trace: hw_stat_port_show+0x4c/0x80 [ib_core] port_attr_show+0x40/0x58 [ib_core] sysfs_kf_seq_show+0x8c/0x150 kernfs_seq_show+0x44/0x50 seq_read+0x1b4/0x45c kernfs_fop_read+0x148/0x1d8 __vfs_read+0x58/0x180 vfs_read+0x94/0x154 ksys_read+0x68/0xd8 __arm64_sys_read+0x28/0x34 el0_svc_common+0x88/0x18c el0_svc_handler+0x78/0x94 el0_svc+0x8/0xe8 Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861) References: - https:/
8c el0_svc_handler+0x78/0x94 el0_svc+0x8/0xe8 Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861) References: - https://git.kernel.org/stable/c/f981c697b2f9bd5dd2f060e47ff8b5e0a2cd0c06 - https://git.kernel.org/stable/c/ac7a7d7079124f46180714b2d41a1703d37101bb - https://git.kernel.org/stable/c/cd06d32a71fbb198b2d43dddf794badd80ffd25d - https://git.kernel.org/stable/c/5e15ff29b156bbbdeadae230c8ecd5ecd8ca2477
CVE ID: CVE-2022-50476 State: PUBLISHED Published: 2025-10-04T15:16:36.895Z Last Updated: 2025-10-04T15:16:36.895Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ntb_netdev: Use dev_kfree_skb_any() in interrupt context TX/RX callback handlers (ntb_netdev_tx_handler(), ntb_netdev_rx_handler()) can be called in interrupt context via the DMA framework when the respective DMA operations have completed. As such, any calls by these routines to free skb's, should use the interrupt context safe dev_kfree_skb_any() function. Previously, these callback handlers would call the interrupt unsafe version of dev_kfree_skb(). This has not pres
ction. Previously, these callback handlers would call the interrupt unsafe version of dev_kfree_skb(). This has not presented an issue on Intel IOAT DMA engines as that driver utilizes tasklets rather than a hard interrupt handler, like the AMD PTDMA DMA driver. On AMD systems, a kernel WARNING message is encountered, which is being issued from skb_release_head_state() due to in_hardirq() being true. Besides the user visible WARNING from the kernel, the other symptom of this bug was that TCP/IP performance across the ntb_netdev interface was very poor, i.e. approximately an order of magnitude below what was expected. With the repair to use dev_kfree_skb_any(), kernel WARNINGs from skb_releas
order of magnitude below what was expected. With the repair to use dev_kfree_skb_any(), kernel WARNINGs from skb_release_head_state() ceased and TCP/IP performance, as measured by iperf, was on par with expected results, approximately 20 Gb/s on AMD Milan based server. Note that this performance is comparable with Intel based servers. References: - https://git.kernel.org/stable/c/d4460c82177899751975180c268f352893302221 - https://git.kernel.org/stable/c/dd860b39aa7c7b82e6c99b6fdb99d4610ce49d67 - https://git.kernel.org/stable/c/8b78493968ed3cef0326183ed059c55e42f24d5b - https://git.kernel.org/stable/c/a6b9e09403102bdf8402dae734800e4916c7ea58 - https://git.kernel.org/stable/c/13286ad1c7c49c60
ps://git.kernel.org/stable/c/a6b9e09403102bdf8402dae734800e4916c7ea58 - https://git.kernel.org/stable/c/13286ad1c7c49c606fdcba4cf66f953a1a16c1ca - https://git.kernel.org/stable/c/21296a52caa6a6bad6debdfe40ad81d4f1a27e69 - https://git.kernel.org/stable/c/14d245da57a11e80277ab455aa9b6dcc5ed38a19 - https://git.kernel.org/stable/c/07e28a8f450217db679802ebd4de0915556ce846 - https://git.kernel.org/stable/c/5f7d78b2b12a9d561f48fa00bab29b40f4616dad
CVE ID: CVE-2022-50477 State: PUBLISHED Published: 2025-10-04T15:16:37.654Z Last Updated: 2025-10-04T15:16:37.654Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rtc: class: Fix potential memleak in devm_rtc_allocate_device() devm_rtc_allocate_device() will alloc a rtc_device first, and then run dev_set_name(). If dev_set_name() failed, the rtc_device will memleak. Move devm_add_action_or_reset() in front of dev_set_name() to prevent memleak. unreferenced object 0xffff888110a53000 (size 2048): comm "python3", pid 470, jiffies 4296078308 (age 58.882s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff ...
pid 470, jiffies 4296078308 (age 58.882s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 30 a5 10 81 88 ff ff .........0...... 08 30 a5 10 81 88 ff ff 00 00 00 00 00 00 00 00 .0.............. backtrace: [<000000004aac0364>] kmalloc_trace+0x21/0x110 [<000000000ff02202>] devm_rtc_allocate_device+0xd4/0x400 [<000000001bdf5639>] devm_rtc_device_register+0x1a/0x80 [<00000000351bf81c>] rx4581_probe+0xdd/0x110 [rtc_rx4581] [<00000000f0eba0ae>] spi_probe+0xde/0x130 [<00000000bff89ee8>] really_probe+0x175/0x3f0 [<00000000128e8d84>] __driver_probe_device+0xe6/0x170 [<00000000ee5bf913>] device_driver_attach+0x32/0x80 [<00000000f3f28f92>] bind_store+0x10b/0x1a0 [<000000009ff812d8>] drv_attr_store
e5bf913>] device_driver_attach+0x32/0x80 [<00000000f3f28f92>] bind_store+0x10b/0x1a0 [<000000009ff812d8>] drv_attr_store+0x49/0x70 [<000000008139c323>] sysfs_kf_write+0x8d/0xb0 [<00000000b6146e01>] kernfs_fop_write_iter+0x214/0x2d0 [<00000000ecbe3895>] vfs_write+0x61a/0x7d0 [<00000000aa2196ea>] ksys_write+0xc8/0x190 [<0000000046a600f5>] do_syscall_64+0x37/0x90 [<00000000541a336f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd References: - https://git.kernel.org/stable/c/0bcfc8fd3e596994f527b46730579428b3a4fa5f - https://git.kernel.org/stable/c/59457a0f079eae19aaf322b3cc1c8ba66f55c5f3 - https://git.kernel.org/stable/c/60da73808298ff2cfa9f165d55eb3d7aa7078601