Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
6859c1fb76db0f8 - https://git.kernel.org/stable/c/b0b83d3f3ffa96e8395c56b83d6197e184902a34 - https://git.kernel.org/stable/c/5777432ebaaf797e24f059979b42df3139967163 - https://git.kernel.org/stable/c/0462fec709d51762ba486245bc344f44cc6cfa97 - https://git.kernel.org/stable/c/799881db3e03b5e98fe6a900d9d7de8c7d61e7ee - https://git.kernel.org/stable/c/404ec60438add1afadaffaed34bb5fe4ddcadd40
CVE ID: CVE-2022-50412 State: PUBLISHED Published: 2025-09-18T16:03:56.159Z Last Updated: 2025-09-18T16:03:56.159Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm: bridge: adv7511: unregister cec i2c device after cec adapter cec_unregister_adapter() assumes that the underlying adapter ops are callable. For example, if the CEC adapter currently has a valid physical address, then the unregistration procedure will invalidate the physical address by setting it to f.f.f.f. Whence the following kernel oops observed after removing the adv7511 module: Unable to handle kernel execution of user memory at virtual address 00000000000000
ed after removing the adv7511 module: Unable to handle kernel execution of user memory at virtual address 0000000000000000 Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP Call trace: 0x0 adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511] cec_adap_unconfigure+0x44/0x90 [cec] __cec_s_phys_addr.part.0+0x68/0x230 [cec] __cec_s_phys_addr+0x40/0x50 [cec] cec_unregister_adapter+0xb4/0x118 [cec] adv7511_remove+0x60/0x90 [adv7511] i2c_device_remove+0x34/0xe0 device_release_driver_internal+0x114/0x1f0 driver_detach+0x54/0xe0 bus_remove_driver+0x60/0xd8 driver_unregister+0x34/0x60 i2c_del_driver+0x2c/0x68 adv7511_exit+0x1c/0x67c [adv7511] __arm64_sys_delete_module+0x154/0x288 invoke_syscall+0x48/0x100
_del_driver+0x2c/0x68 adv7511_exit+0x1c/0x67c [adv7511] __arm64_sys_delete_module+0x154/0x288 invoke_syscall+0x48/0x100 el0_svc_common.constprop.0+0x48/0xe8 do_el0_svc+0x28/0x88 el0_svc+0x1c/0x50 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x15c/0x160 Code: bad PC value ---[ end trace 0000000000000000 ]--- Protect against this scenario by unregistering i2c_cec after unregistering the CEC adapter. Duly disable the CEC clock afterwards too. References: - https://git.kernel.org/stable/c/3747465c5da7a11957a34bbb9485d9fc253b91cc - https://git.kernel.org/stable/c/f369fb4deed7ab997cfa703dc85ec08b3adc1af8 - https://git.kernel.org/stable/c/4d4d5bc659206b187263190ad9a03513f625659d - https://git.kernel
7cfa703dc85ec08b3adc1af8 - https://git.kernel.org/stable/c/4d4d5bc659206b187263190ad9a03513f625659d - https://git.kernel.org/stable/c/86ae5170786aea3e1751123ca55700fb9b37b623 - https://git.kernel.org/stable/c/40cdb02cb9f965732eb543d47f15bef8d10f0f5f
CVE ID: CVE-2022-50413 State: PUBLISHED Published: 2025-09-18T16:03:56.853Z Last Updated: 2025-09-18T16:03:56.853Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix use-after-free We've already freed the assoc_data at this point, so need to use another copy of the AP (MLD) address instead. References: - https://git.kernel.org/stable/c/aebef10affe16228462af680b88751bf137e2856 - https://git.kernel.org/stable/c/40fb87129049ec5876dabf4a4d4aed6642b31f1a
CVE ID: CVE-2022-50414 State: PUBLISHED Published: 2025-09-18T16:03:58.156Z Last Updated: 2025-09-18T16:03:58.156Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: fcoe: Fix transport not deattached when fcoe_if_init() fails fcoe_init() calls fcoe_transport_attach(&fcoe_sw_transport), but when fcoe_if_init() fails, &fcoe_sw_transport is not detached and leaves freed &fcoe_sw_transport on fcoe_transports list. This causes panic when reinserting module. BUG: unable to handle page fault for address: fffffbfff82e2213 RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe] Call Trace: <TASK> do_one_initcall+0xd0/0x4e0 load_module+0
82e2213 RIP: 0010:fcoe_transport_attach+0xe1/0x230 [libfcoe] Call Trace: <TASK> do_one_initcall+0xd0/0x4e0 load_module+0x5eee/0x7210 ... References: - https://git.kernel.org/stable/c/d581303d6f8d4139513105d73dd65f26c6707160 - https://git.kernel.org/stable/c/b5cc59470df64f26ad397dbb71cbf130cf489edf - https://git.kernel.org/stable/c/cf74d1197c0e3d2f353faa333e9e2847c73713f1 - https://git.kernel.org/stable/c/be5f1a82ad6056db22c86005dc4cac22a20deeef - https://git.kernel.org/stable/c/22e8c7a56bb1cd2ed0beaaccb34282ac9cbbe27e - https://git.kernel.org/stable/c/09a60f908d8b6497f618113b7c3c31267dc90911 - https://git.kernel.org/stable/c/1dc499c615aa87dc46a3f2d1f91d2d358e55f3e3 - https://git.kernel.org/s
3b7c3c31267dc90911 - https://git.kernel.org/stable/c/1dc499c615aa87dc46a3f2d1f91d2d358e55f3e3 - https://git.kernel.org/stable/c/aef82d16be5a353d913163f26fc4385e296be2b8 - https://git.kernel.org/stable/c/4155658cee394b22b24c6d64e49247bf26d95b92
CVE ID: CVE-2022-50415 State: PUBLISHED Published: 2025-09-18T16:03:58.836Z Last Updated: 2025-09-18T16:03:58.836Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: parisc: led: Fix potential null-ptr-deref in start_task() start_task() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: start_task() create_singlethread_workqueue() # failed, led_wq is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. Refere
continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. References: - https://git.kernel.org/stable/c/c6db0c32f39684c89c97bc1ba1c9c4249ca09e48 - https://git.kernel.org/stable/c/fc6d0f65f22040c6cc8a5ce032bf90252629de50 - https://git.kernel.org/stable/c/fc307b2905a3dd75c50a53b4d87ac9c912fb7c4e - https://git.kernel.org/stable/c/5e4500454d75dd249be4695d83afa3ba0724c37e - https://git.kernel.org/stable/c/3505c187b86136250b39e62c72a3a70435277af6 - https://git.kernel.org/stable/c/ac838c663ba1fd6bff35a817fd89a47ab55e88e0 - https://git.kernel.org/stable/c/77f8b628affaec692d83ad8bfa3520db8a0cc493 - https://git.kernel.org/stable/c/67c98fec87ed76b
tps://git.kernel.org/stable/c/77f8b628affaec692d83ad8bfa3520db8a0cc493 - https://git.kernel.org/stable/c/67c98fec87ed76b1feb2ae810051afd88dfa9df6 - https://git.kernel.org/stable/c/41f563ab3c33698bdfc3403c7c2e6c94e73681e4
CVE ID: CVE-2022-50416 State: PUBLISHED Published: 2025-09-18T16:03:59.541Z Last Updated: 2025-09-18T16:03:59.541Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: irqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init() If of_iomap() failed, 'aic' should be freed before return. Otherwise there is a memory leak. References: - https://git.kernel.org/stable/c/740efb64ca5e8f2b30ac843bc4ab07950479fed4 - https://git.kernel.org/stable/c/bcbcb396e1a8bd4dcaabfb0d5b98abae70880470 - https://git.kernel.org/stable/c/773c9d7f127f7a599d42ceed831de69f5aa22f03 - https://git.kernel.org/stable/c/4208d4faf36573a507b5e5de17abe342e9276759
CVE ID: CVE-2022-50417 State: PUBLISHED Published: 2025-09-18T16:04:00.512Z Last Updated: 2025-09-18T16:04:00.512Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Fix GEM handle creation ref-counting panfrost_gem_create_with_handle() previously returned a BO but with the only reference being from the handle, which user space could in theory guess and release, causing a use-after-free. Additionally if the call to panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then a(nother) reference on the BO was dropped. The _create_with_handle() is a problematic pattern, so ditch it and instead create the handle
ce on the BO was dropped. The _create_with_handle() is a problematic pattern, so ditch it and instead create the handle in panfrost_ioctl_create_bo(). If the call to panfrost_gem_mapping_get() fails then this means that user space has indeed gone behind our back and freed the handle. In which case just return an error code. References: - https://git.kernel.org/stable/c/0b70f6ea4d4f2b4d4b291d86ab76b4d07394932c - https://git.kernel.org/stable/c/4f1105ee72d8c7c35d90e3491b31b2d9d6b7e33a - https://git.kernel.org/stable/c/3f9feffa8a5ab08b4e298a27b1aa7204a7d42ca2 - https://git.kernel.org/stable/c/ba3d2c2380e7129b525a787489c0b7e819a3b898 - https://git.kernel.org/stable/c/4217c6ac817451d5116687f3cc62
nel.org/stable/c/ba3d2c2380e7129b525a787489c0b7e819a3b898 - https://git.kernel.org/stable/c/4217c6ac817451d5116687f3cc6286220dc43d49
CVE ID: CVE-2022-50418 State: PUBLISHED Published: 2025-09-18T16:04:01.436Z Last Updated: 2025-09-19T15:21:29.853Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register() mhi_alloc_controller() allocates a memory space for mhi_ctrl. When gets some error, mhi_ctrl should be freed with mhi_free_controller(). But when ath11k_mhi_read_addr_from_dt() fails, the function returns without calling mhi_free_controller(), which will lead to a memory leak. We can fix it by calling mhi_free_controller() when ath11k_mhi_read_addr_from_dt() fails. References: - https://git.kernel.or
n fix it by calling mhi_free_controller() when ath11k_mhi_read_addr_from_dt() fails. References: - https://git.kernel.org/stable/c/72ef896e80b6ec7cdc1dd42577045f8e7c9c32b3 - https://git.kernel.org/stable/c/015ced9eb63b8b19cb725a1d592d150b60494ced - https://git.kernel.org/stable/c/43e7c3505ec70db3d3c6458824d5fa40f62e3e7b
CVE ID: CVE-2022-50419 State: PUBLISHED Published: 2025-09-18T16:04:02.152Z Last Updated: 2025-10-29T10:50:20.282Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times device_add shall not be called multiple times as stated in its documentation: 'Do not call this routine or device_register() more than once for any device structure' Syzkaller reports a bug as follows [1]: ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:33! invalid opcode: 0000 [#1] PREEMPT SMP KASAN [...] Call Trace: <TASK> __list_add include/linux/list.h:69 [inline] list_add_ta
lid opcode: 0000 [#1] PREEMPT SMP KASAN [...] Call Trace: <TASK> __list_add include/linux/list.h:69 [inline] list_add_tail include/linux/list.h:102 [inline] kobj_kset_join lib/kobject.c:164 [inline] kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214 kobject_add_varg lib/kobject.c:358 [inline] kobject_add+0x150/0x1c0 lib/kobject.c:410 device_add+0x368/0x1e90 drivers/base/core.c:3452 hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53 hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799 hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110 hci_event_func net/bluetooth/hci_event.c:7440 [inline] hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495 hci_rx_work
ent_func net/bluetooth/hci_event.c:7440 [inline] hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495 hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> References: - https://git.kernel.org/stable/c/4bcefec3636208b4c97536b26014d5935d5c10a0 - https://git.kernel.org/stable/c/6144423712d570247b8ca26e50a277c30dd13702 - https://git.kernel.org/stable/c/671fee73e08ff415d36a7c16bdf238927df83884 - https://git.kernel.org/stable/c/6e85d2ad958c6f034b1b158d904019869dbb3c81 - https://git.ke
f415d36a7c16bdf238927df83884 - https://git.kernel.org/stable/c/6e85d2ad958c6f034b1b158d904019869dbb3c81 - https://git.kernel.org/stable/c/7b674dce4162bb46d396586e30e4653427023875 - https://git.kernel.org/stable/c/3423a50fa018e88aed4c900d59c3c8334d8ad583 - https://git.kernel.org/stable/c/ef055094df4c10b73cfe67c8d43f9de1fb608a8b - https://git.kernel.org/stable/c/1b6c89571f453101251201f0fad1c26f7256e937 - https://git.kernel.org/stable/c/448a496f760664d3e2e79466aa1787e6abc922b5
CVE ID: CVE-2022-50420 State: PUBLISHED Published: 2025-10-01T11:41:53.287Z Last Updated: 2025-10-02T07:04:14.879Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/hpre - fix resource leak in remove process In hpre_remove(), when the disable operation of qm sriov failed, the following logic should continue to be executed to release the remaining resources that have been allocated, instead of returning directly, otherwise there will be resource leakage. References: - https://git.kernel.org/stable/c/2b3e3ecdb402ff1053ee25b598ff21b9ddf4384f - https://git.kernel.org/stable/c/4e0de941d252d4e7c985981e78480c8d6f020b64
e/c/2b3e3ecdb402ff1053ee25b598ff21b9ddf4384f - https://git.kernel.org/stable/c/4e0de941d252d4e7c985981e78480c8d6f020b64 - https://git.kernel.org/stable/c/cb873c93a7ad27681920bf062ef052fca1e8d5b1 - https://git.kernel.org/stable/c/45e6319bd5f2154d8b8c9f1eaa4ac030ba0d330c
CVE ID: CVE-2022-50421 State: PUBLISHED Published: 2025-10-01T11:41:54.351Z Last Updated: 2025-10-01T11:41:54.351Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rpmsg: char: Avoid double destroy of default endpoint The rpmsg_dev_remove() in rpmsg_core is the place for releasing this default endpoint. So need to avoid destroying the default endpoint in rpmsg_chrdev_eptdev_destroy(), this should be the same as rpmsg_eptdev_release(). Otherwise there will be double destroy issue that ept->refcount report warning: refcount_t: underflow; use-after-free. Call trace: refcount_warn_saturate+0xf8/0x150 virtio_rpmsg_destroy_ept+0xd4/0xe
: refcount_t: underflow; use-after-free. Call trace: refcount_warn_saturate+0xf8/0x150 virtio_rpmsg_destroy_ept+0xd4/0xec rpmsg_dev_remove+0x60/0x70 The issue can be reproduced by stopping remoteproc before closing the /dev/rpmsgX. References: - https://git.kernel.org/stable/c/ef828a39d6a7028836eaf37df3ad568c8c2dd6f9 - https://git.kernel.org/stable/c/3f20ef7a845c2c8d7ec82ecffa20d95cab5ecfeb - https://git.kernel.org/stable/c/467233a4ac29b215d492843d067a9f091e6bf0c5
CVE ID: CVE-2022-50422 State: PUBLISHED Published: 2025-10-01T11:41:55.147Z Last Updated: 2025-10-01T11:41:55.147Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: libsas: Fix use-after-free bug in smp_execute_task_sg() When executing SMP task failed, the smp_execute_task_sg() calls del_timer() to delete "slow_task->timer". However, if the timer handler sas_task_internal_timedout() is running, the del_timer() in smp_execute_task_sg() will not stop it and a UAF will happen. The process is shown below: (thread 1) | (thread 2) smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ... sas_free_task(task
ad 1) | (thread 2) smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ... sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure the timer handler have finished before the "task->slow_task" is deallocated. References: - https://git.kernel.org/stable/c/117331a2a5227fb4369c2a1f321d3e3e2e2ef8fe - https://git.kernel.org/stable/c/a9e5176ead6de64f572ad5c87a72825d9d3c82ae - https://git.kernel.org/stable/c/e45a1516d2933703a4823d9db71e17c3abeba24f - https://git.kernel.org/stable/c/f7a785177611ffc97d645fcbc196e6de6ad2421d - https://git.kernel.org/stable/c/2e12ce270f0d926085
://git.kernel.org/stable/c/f7a785177611ffc97d645fcbc196e6de6ad2421d - https://git.kernel.org/stable/c/2e12ce270f0d926085c1209cc90397e307deef97 - https://git.kernel.org/stable/c/46ba53c30666717cb06c2b3c5d896301cd00d0c0
CVE ID: CVE-2022-50423 State: PUBLISHED Published: 2025-10-01T11:41:56.083Z Last Updated: 2025-10-01T11:41:56.083Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage() There is an use-after-free reported by KASAN: BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82 Read of size 1 at addr ffff888112afc460 by task modprobe/2111 CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), Call Trace: <TASK> kasan_report+0xae/0xe0 acpi_ut_remove_reference+0x3b/0x82 acpi_ut_copy_iobject_to_iobject+0x3be/0x3d
Call Trace: <TASK> kasan_report+0xae/0xe0 acpi_ut_remove_reference+0x3b/0x82 acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5 acpi_ds_store_object_to_local+0x15d/0x3a0 acpi_ex_store+0x78d/0x7fd acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b acpi_ps_parse_aml+0x217/0x8d5 ... </TASK> The root cause of the problem is that the acpi_operand_object is freed when acpi_ut_walk_package_tree() fails in acpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in acpi_ut_copy_iobject_to_iobject(). The problem was introduced by "8aa5e56eeb61" commit, this commit is to fix memory leak in acpi_ut_copy_iobject_to_iobject(), repeatedly adding remove operation, lead to "acpi_operand_object" used after free. Fix it by r
opy_iobject_to_iobject(), repeatedly adding remove operation, lead to "acpi_operand_object" used after free. Fix it by removing acpi_ut_remove_reference() in acpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage() is called to copy an internal package object into another internal package object, when it fails, the memory of acpi_operand_object should be freed by the caller. References: - https://git.kernel.org/stable/c/133462d35dae95edb944af86b986d4c9dec59bd1 - https://git.kernel.org/stable/c/02f237423c9c6a18e062de2d474f85d5659e4eb9 - https://git.kernel.org/stable/c/c9125b643fc51b8e662f2f614096ceb45a0adbc3 - https://git.kernel.org/stable/c/dfdde4d5138bc023897033a5ac653a84e94
/stable/c/c9125b643fc51b8e662f2f614096ceb45a0adbc3 - https://git.kernel.org/stable/c/dfdde4d5138bc023897033a5ac653a84e94805be - https://git.kernel.org/stable/c/02617006b5a46f2ea55ac61f5693c7afd7bf9276 - https://git.kernel.org/stable/c/6fde666278f91b85d71545a0ebbf41d8d7af8074 - https://git.kernel.org/stable/c/f51b2235e4f320edc839c3e5cb0d1f8a6e8657c6 - https://git.kernel.org/stable/c/01f2c2052ea50fb9a8ce12e4e83aed0267934ef0 - https://git.kernel.org/stable/c/470188b09e92d83c5a997f25f0e8fb8cd2bc3469
CVE ID: CVE-2022-50424 State: PUBLISHED Published: 2025-10-01T11:42:03.912Z Last Updated: 2025-10-01T11:42:03.912Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: resource leaks at mt7921_check_offload_capability() Fixed coverity issue with resource leaks at variable "fw" going out of scope leaks the storage it points to mt7921_check_offload_capability(). Addresses-Coverity-ID: 1527806 ("Resource leaks") References: - https://git.kernel.org/stable/c/ead3cffd7510dc635d84cd4ea9dd1974fcb69a35 - https://git.kernel.org/stable/c/47180ecf4541146836c5307c1d5526f8ac6a5a6d
CVE ID: CVE-2022-50425 State: PUBLISHED Published: 2025-10-01T11:42:04.776Z Last Updated: 2025-10-01T11:42:04.776Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly When an extended state component is not present in fpstate, but in init state, the function copies from init_fpstate via copy_feature(). But, dynamic states are not present in init_fpstate because of all-zeros init states. Then retrieving them from init_fpstate will explode like this: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:memcpy_erms+0x6/0x10 ? __copy_xstate_to_uabi
G: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:memcpy_erms+0x6/0x10 ? __copy_xstate_to_uabi_buf+0x381/0x870 fpu_copy_guest_fpstate_to_uabi+0x28/0x80 kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm] ? __this_cpu_preempt_check+0x13/0x20 ? vmx_vcpu_put+0x2e/0x260 [kvm_intel] kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm] ? __fget_light+0xd4/0x130 __x64_sys_ioctl+0xe3/0x910 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x27/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Adjust the 'mask' to zero out the userspace buffer for the features that are not available both from fpstate and from init_fpstate. The dynamic fe
out the userspace buffer for the features that are not available both from fpstate and from init_fpstate. The dynamic features depend on the compacted XSAVE format. Ensure it is enabled before reading XCOMP_BV in init_fpstate. References: - https://git.kernel.org/stable/c/6ff29642fd28965a8f8d6d326ac91bf6075f3113 - https://git.kernel.org/stable/c/471f0aa7fa64e23766a1473b32d9ec3f0718895a
CVE ID: CVE-2022-50426 State: PUBLISHED Published: 2025-10-01T11:42:05.613Z Last Updated: 2025-10-01T11:42:05.613Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_dsp_rproc: Add mutex protection for workqueue The workqueue may execute late even after remoteproc is stopped or stopping, some resources (rpmsg device and endpoint) have been released in rproc_stop_subdevices(), then rproc_vq_interrupt() accessing these resources will cause kennel dump. Call trace: virtqueue_add_split+0x1ac/0x560 virtqueue_add_inbuf+0x4c/0x60 rpmsg_recv_done+0x15c/0x294 vring_interrupt+0x6c/0xa4 rproc_vq_interrupt+0x30/0x50 imx_dsp_rpr
queue_add_inbuf+0x4c/0x60 rpmsg_recv_done+0x15c/0x294 vring_interrupt+0x6c/0xa4 rproc_vq_interrupt+0x30/0x50 imx_dsp_rproc_vq_work+0x24/0x40 [imx_dsp_rproc] process_one_work+0x1d0/0x354 worker_thread+0x13c/0x470 kthread+0x154/0x160 ret_from_fork+0x10/0x20 Add mutex protection in imx_dsp_rproc_vq_work(), if the state is not running, then just skip calling rproc_vq_interrupt(). Also the flush workqueue operation can't be added in rproc stop for the same reason. The call sequence is rproc_shutdown -> rproc_stop ->rproc_stop_subdevices ->rproc->ops->stop() ->imx_dsp_rproc_stop ->flush_work -> rproc_vq_interrupt The resource needed by rproc_vq_interrupt has been released in rproc_stop_subdevices,
->flush_work -> rproc_vq_interrupt The resource needed by rproc_vq_interrupt has been released in rproc_stop_subdevices, so flush_work is not safe to be called in imx_dsp_rproc_stop. References: - https://git.kernel.org/stable/c/4a3e1fa7a77838617bdbcd95127ce93a959fad44 - https://git.kernel.org/stable/c/b9693304b7133b81741add5bfb56f022596df012 - https://git.kernel.org/stable/c/47e6ab07018edebf94ce873cf50a05ec76ff2dde
CVE ID: CVE-2022-50427 State: PUBLISHED Published: 2025-10-01T11:42:06.365Z Last Updated: 2025-10-01T11:42:06.365Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: ac97: fix possible memory leak in snd_ac97_dev_register() If device_register() fails in snd_ac97_dev_register(), it should call put_device() to give up reference, or the name allocated in dev_set_name() is leaked. References: - https://git.kernel.org/stable/c/a602ec9d88f177dba78bc97fb1adecc7a71ff279 - https://git.kernel.org/stable/c/0f8e9a15c8ecf95057061d370a2dddaf1cee4aeb - https://git.kernel.org/stable/c/ee8bf0946f62ef00e5db4b613a9f664ac567259a - https://git.ke
f95057061d370a2dddaf1cee4aeb - https://git.kernel.org/stable/c/ee8bf0946f62ef00e5db4b613a9f664ac567259a - https://git.kernel.org/stable/c/758dbcc6fbf2286eff02743b093c70a18a407d66 - https://git.kernel.org/stable/c/bfce73088682ef0770da951f51156c36a89be490 - https://git.kernel.org/stable/c/4fdf6f978c6b605ca0d67bf0e982b7a8fc0f4aab - https://git.kernel.org/stable/c/c68b2e9ef246117f696e360bbdd2f5736b3a7127 - https://git.kernel.org/stable/c/4881bda5ea05c8c240fc8afeaa928e2bc43f61fa