Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
5c/0x230 [ 9.278531] snprintf+0x58/0x80 [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190 [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c ..snip.. The following line defines a pointer that point to a char buffer stored in read-only memory: char *pvs_name = "speedXX-pvsXX-vXX"; This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the XX values get overridden by the qcom_cpufreq_krait_name_version function. Since the template is actually stored in read-only memory, when the function executes the following call we get an oops: snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d", speed, pvs, pvs_ver); To fix this issue, we instead store the template name onto the
-pvsXX-vXX"), "speed%d-pvs%d-v%d", speed, pvs, pvs_ver); To fix this issue, we instead store the template name onto the stack by using the following syntax: char pvs_name_buffer[] = "speedXX-pvsXX-vXX"; Because the `pvs_name` needs to be able to be assigned to NULL, the template buffer is stored in the pvs_name_buffer and not under the pvs_name variable. References: - https://git.kernel.org/stable/c/794ded0bc461287a268bed21fea2eebb6e5d232c - https://git.kernel.org/stable/c/14d260f94ff89543597ffea13db8b277a810e08e - https://git.kernel.org/stable/c/b74ee4e301ca01e431e240c046173332966e2431 - https://git.kernel.org/stable/c/01039fb8e90c9cb684430414bff70cea9eb168c5
CVE ID: CVE-2022-50240 State: PUBLISHED Published: 2025-09-15T14:01:45.724Z Last Updated: 2025-10-10T15:53:38.644Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: android: binder: stop saving a pointer to the VMA Do not record a pointer to a VMA outside of the mmap_lock for later use. This is unsafe and there are a number of failure paths *after* the recorded VMA pointer may be freed during setup. There is no callback to the driver to clear the saved pointer from generic mm code. Furthermore, the VMA pointer may become stale if any number of VMA operations end up freeing the VMA so saving it was fragile to being with. Instead, c
y become stale if any number of VMA operations end up freeing the VMA so saving it was fragile to being with. Instead, change the binder_alloc struct to record the start address of the VMA and use vma_lookup() to get the vma when needed. Add lockdep mmap_lock checks on updates to the vma pointer to ensure the lock is held and depend on that lock for synchronization of readers and writers - which was already the case anyways, so the smp_wmb()/smp_rmb() was not necessary. [akpm@linux-foundation.org: fix drivers/android/binder_alloc_selftest.c] References: - https://git.kernel.org/stable/c/27a594bc7a7c8238d239e3cdbcf2edfa3bbe9a1b - https://git.kernel.org/stable/c/015ac18be7de25d17d6e5f1643cb3b6
.org/stable/c/27a594bc7a7c8238d239e3cdbcf2edfa3bbe9a1b - https://git.kernel.org/stable/c/015ac18be7de25d17d6e5f1643cb3b60bfbe859e - https://git.kernel.org/stable/c/622ef885a89ad04cfb76ee478fb44f051125d1f1 - https://git.kernel.org/stable/c/925e6b6f82c9c80ab3c17acbde8d16f349da7d26 - https://git.kernel.org/stable/c/1ec3f76a436d750fd5023caec5da0494fc2870d2 - https://git.kernel.org/stable/c/a43cfc87caaf46710c8027a8c23b8a55f1078f19
CVE ID: CVE-2022-50241 State: PUBLISHED Published: 2025-09-15T14:01:47.539Z Last Updated: 2025-09-15T14:01:47.539Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: NFSD: fix use-after-free on source server when doing inter-server copy Use-after-free occurred when the laundromat tried to free expired cpntf_state entry on the s2s_cp_stateids list after inter-server copy completed. The sc_cp_list that the expired copy state was inserted on was already freed. When COPY completes, the Linux client normally sends LOCKU(lock_state x), FREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server. The nfs4_put_stid call from nf
U(lock_state x), FREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server. The nfs4_put_stid call from nfsd4_free_stateid cleans up the copy state from the s2s_cp_stateids list before freeing the lock state's stid. However, sometimes the CLOSE was sent before the FREE_STATEID request. When this happens, the nfsd4_close_open_stateid call from nfsd4_close frees all lock states on its st_locks list without cleaning up the copy state on the sc_cp_list list. When the time the FREE_STATEID arrives the server returns BAD_STATEID since the lock state was freed. This causes the use-after-free error to occur when the laundromat tries to free the expired cpntf_state. This patch adds a ca
causes the use-after-free error to occur when the laundromat tries to free the expired cpntf_state. This patch adds a call to nfs4_free_cpntf_statelist in nfsd4_close_open_stateid to clean up the copy state before calling free_ol_stateid_reaplist to free the lock state's stid on the reaplist. References: - https://git.kernel.org/stable/c/bbacfcde5fff25ac22597e8373a065c647da6738 - https://git.kernel.org/stable/c/83b94969751a691347606dbe6b1865efcfa5a643 - https://git.kernel.org/stable/c/6ea71246b7a02af675d733e72d14bd0d591d5f4a - https://git.kernel.org/stable/c/35aa0fb8c3033a3d78603356e96fc18c5b9cceb2 - https://git.kernel.org/stable/c/019805fea91599b22dfa62ffb29c022f35abeb06
CVE ID: CVE-2022-50242 State: PUBLISHED Published: 2025-09-15T14:01:50.328Z Last Updated: 2025-09-15T14:01:50.328Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init() If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp needs to be freed. References: - https://git.kernel.org/stable/c/15770edc01edfce773269e8a443ca8e420f6f859 - https://git.kernel.org/stable/c/0aefadf23ee5e33b747df195ace42d3be2025e4e - https://git.kernel.org/stable/c/132c502919bb08e16e3054cb28bb7b149ec20cf5 - https://git.kernel.org/stable/c/a44490abaf00f5b0cc5c448a17eae331c6195d0a
e/c/132c502919bb08e16e3054cb28bb7b149ec20cf5 - https://git.kernel.org/stable/c/a44490abaf00f5b0cc5c448a17eae331c6195d0a - https://git.kernel.org/stable/c/14b349a15c297cf3e01b5deb4116f7cf297b6184 - https://git.kernel.org/stable/c/8399b9893548c03fdb18be277bf99d985dbde925 - https://git.kernel.org/stable/c/aa2d179544b6815b4a23c0c44543ba0971d49fce - https://git.kernel.org/stable/c/dcae92a249551d1a447804b4be1c9fab0e8c95e8 - https://git.kernel.org/stable/c/01de1123322e4fe1bbd0fcdf0982511b55519c03
CVE ID: CVE-2022-50243 State: PUBLISHED Published: 2025-09-15T14:01:52.101Z Last Updated: 2025-09-15T14:01:52.101Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sctp: handle the error returned from sctp_auth_asoc_init_active_key When it returns an error from sctp_auth_asoc_init_active_key(), the active_key is actually not updated. The old sh_key will be freeed while it's still used as active key in asoc. Then an use-after-free will be triggered when sending patckets, as found by syzbot: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/
x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 This patch is to fix it by not replacing the sh_key when it returns errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key(). For sctp_auth_set_active_key(), old active_key_id will be set back to asoc->active_key_id when the same thing happens. References: - https://git.kernel.org/stable/c/b8fa99a3a11bdd77fef6b4a97f1021eb30b5ba40 - https://git.kernel.org/stable/c/382ff44
es: - https://git.kernel.org/stable/c/b8fa99a3a11bdd77fef6b4a97f1021eb30b5ba40 - https://git.kernel.org/stable/c/382ff44716603a54f5fd238ddec6a2468e217612 - https://git.kernel.org/stable/c/f65955340e0044f5c41ac799a01698ac7dee8a4e - https://git.kernel.org/stable/c/19d636b663e0e92951bba5fced929ca7fd25c552 - https://git.kernel.org/stable/c/0f90099d18e3abdc01babf686f41f63fe04939c1 - https://git.kernel.org/stable/c/3b0fcf5e29c0940e1169ce9c44f73edd98bdf12d - https://git.kernel.org/stable/c/022152aaebe116a25c39818a07e175a8cd3c1e11
CVE ID: CVE-2022-50244 State: PUBLISHED Published: 2025-09-15T14:02:01.364Z Last Updated: 2025-09-15T14:02:01.364Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter() If device_register() fails in cxl_pci_afu|adapter(), the device is not added, device_unregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev w
the reference in the error path. So split device_unregister() into device_del() and put_device(), then goes to put dev when register fails. References: - https://git.kernel.org/stable/c/82e68432668ae75b4c814d160f6987ecb0681273 - https://git.kernel.org/stable/c/82e5481428faf11c79b9c094dd24a1849bbf64ac - https://git.kernel.org/stable/c/c4b2e35df919d99bbbed033c2fa0b607f9f463b5 - https://git.kernel.org/stable/c/361412dae1690d4b5df6f92fc943cdc773c95cbc - https://git.kernel.org/stable/c/0f63c0ddc2ea20d783d29243f4dbe0f9e95dfdec - https://git.kernel.org/stable/c/22511eefa61db26e12c97dd7ada3071dbdfcb004 - https://git.kernel.org/stable/c/139abd4c626a6f7ce02789ed5f73aa2256e0542b - https://git.kernel.or
97dd7ada3071dbdfcb004 - https://git.kernel.org/stable/c/139abd4c626a6f7ce02789ed5f73aa2256e0542b - https://git.kernel.org/stable/c/2f5fd31b2f24b9b8a80ab566fd8c4e1e94cb4339 - https://git.kernel.org/stable/c/02cd3032b154fa02fdf90e7467abaeed889330b2
CVE ID: CVE-2022-50245 State: PUBLISHED Published: 2025-09-15T14:02:03.353Z Last Updated: 2025-09-15T14:02:03.353Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rapidio: fix possible UAF when kfifo_alloc() fails If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free priv. But priv is still in the chdev->file_list, then list traversal may cause UAF. This fixes the following smatch warning: drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: '&priv->list' not removed from list References: - https://git.kernel.org/stable/c/2a6c75adf8192f07ddcdd4a1a13488c890a73919 - https://git.kernel.org/stable
t References: - https://git.kernel.org/stable/c/2a6c75adf8192f07ddcdd4a1a13488c890a73919 - https://git.kernel.org/stable/c/2dfd60724d271a6ab99f93f40f38f2ced1ddbb87 - https://git.kernel.org/stable/c/a253dde0403a153075ffb254f6f7b2635e49e97a - https://git.kernel.org/stable/c/311b488405ac45af46756b1c8f1d27007b68b07e - https://git.kernel.org/stable/c/5ee850645e42f541ce1ea8130c2b27cc495f965c - https://git.kernel.org/stable/c/2f5cc7fd73fd6253cc71214f0dd499cc62feb469 - https://git.kernel.org/stable/c/2ba06e57f933f0eac242e8b389433da1cc00d4d5 - https://git.kernel.org/stable/c/cb87af2c19c0993f6e21f75b963a5599c5a73e76 - https://git.kernel.org/stable/c/02d7d89f816951e0862147d751b1150d67aaebdd
CVE ID: CVE-2022-50246 State: PUBLISHED Published: 2025-09-15T14:02:04.841Z Last Updated: 2025-09-15T14:02:04.841Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpci: fix of node refcount leak in tcpci_register_port() I got the following report while doing device(mt6370-tcpc) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /i2c/pmic@34/tcpc/connector The 'fwnode' set in tcpci_parse_config() which is called in tcpci_register_port(), its node refcount is increase
nnector The 'fwnode' set in tcpci_parse_config() which is called in tcpci_register_port(), its node refcount is increased in device_get_named_child_node(). It needs be put while exiting, so call fwnode_handle_put() in the error path of tcpci_register_port() and in tcpci_unregister_port() to avoid leak. References: - https://git.kernel.org/stable/c/4f257e2eba419ab4cd880c822346450e4e7b2af3 - https://git.kernel.org/stable/c/d3b6c28a71f111a6c67ddc3238aab95910fd86cf - https://git.kernel.org/stable/c/ba75be6f0d9d028d20852564206565a4c03e3288 - https://git.kernel.org/stable/c/e75a324409715bd71348f79a49aa61b69dbeb676 - https://git.kernel.org/stable/c/5f125507d2270035dfcf83fbff6cff5a143e200c - https:/
24409715bd71348f79a49aa61b69dbeb676 - https://git.kernel.org/stable/c/5f125507d2270035dfcf83fbff6cff5a143e200c - https://git.kernel.org/stable/c/0384e87e3fec735e47f1c133c796f32ef7a72a9b
CVE ID: CVE-2022-50247 State: PUBLISHED Published: 2025-09-15T14:02:06.776Z Last Updated: 2025-09-15T14:02:06.776Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: xhci-mtk: fix leakage of shared hcd when fail to set wakeup irq Can not set the @shared_hcd to NULL before decrease the usage count by usb_put_hcd(), this will cause the shared hcd not released. References: - https://git.kernel.org/stable/c/ffb14aac2658873050671198543b9b8194149c14 - https://git.kernel.org/stable/c/05680a91ae60ddd0319e6618456f0883b5dd765d - https://git.kernel.org/stable/c/c8e7463844888dc8344bbb9cbad88cdce9cb8077 - https://git.kernel.org/stable/c/03
b5dd765d - https://git.kernel.org/stable/c/c8e7463844888dc8344bbb9cbad88cdce9cb8077 - https://git.kernel.org/stable/c/03a88b0bafbe3f548729d970d8366f48718c9b19
CVE ID: CVE-2022-50248 State: PUBLISHED Published: 2025-09-15T14:02:07.723Z Last Updated: 2025-09-15T14:02:07.723Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix double free on tx path. We see kernel crashes and lockups and KASAN errors related to ax210 firmware crashes. One of the KASAN dumps pointed at the tx path, and it appears there is indeed a way to double-free an skb. If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the method will be freed. But, in case where we build TSO skb buffer, the skb may also be freed in error case. So, return 0 in that particular error case and do cleanu
build TSO skb buffer, the skb may also be freed in error case. So, return 0 in that particular error case and do cleanup manually. BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000000 | tsf hi Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650 CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5 iwlwifi 0000:06:00.0: 0x00000000 | time gp1 Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019 Call Trace: <TASK> dump_stack_lvl+0x55/0x6d print_report.cold.12+0xf2/0x684 iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2 ? __list_del_entry_valid+0x12/0x90 kasan_report+0x8b/0x180 iwlwifi 0000:06:00.0: 0x00000001 | uCode revisio
8 | time gp2 ? __list_del_entry_valid+0x12/0x90 kasan_report+0x8b/0x180 iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type ? __list_del_entry_valid+0x12/0x90 __list_del_entry_valid+0x12/0x90 iwlwifi 0000:06:00.0: 0x00000048 | uCode version major tcp_update_skb_after_send+0x5d/0x170 __tcp_transmit_skb+0xb61/0x15c0 iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor ? __tcp_select_window+0x490/0x490 iwlwifi 0000:06:00.0: 0x00000420 | hw version ? trace_kmalloc_node+0x29/0xd0 ? __kmalloc_node_track_caller+0x12a/0x260 ? memset+0x1f/0x40 ? __build_skb_around+0x125/0x150 ? __alloc_skb+0x1d4/0x220 ? skb_zerocopy_clone+0x55/0x230 iwlwifi 0000:06:00.0: 0x00489002 | board version ? kmalloc_rese
__alloc_skb+0x1d4/0x220 ? skb_zerocopy_clone+0x55/0x230 iwlwifi 0000:06:00.0: 0x00489002 | board version ? kmalloc_reserve+0x80/0x80 ? rcu_read_lock_bh_held+0x60/0xb0 tcp_write_xmit+0x3f1/0x24d0 iwlwifi 0000:06:00.0: 0x034E001C | hcmd ? __check_object_size+0x180/0x350 iwlwifi 0000:06:00.0: 0x24020000 | isr0 tcp_sendmsg_locked+0x8a9/0x1520 iwlwifi 0000:06:00.0: 0x01400000 | isr1 ? tcp_sendpage+0x50/0x50 iwlwifi 0000:06:00.0: 0x48F0000A | isr2 ? lock_release+0xb9/0x400 ? tcp_sendmsg+0x14/0x40 iwlwifi 0000:06:00.0: 0x00C3080C | isr3 ? lock_downgrade+0x390/0x390 ? do_raw_spin_lock+0x114/0x1d0 iwlwifi 0000:06:00.0: 0x00200000 | isr4 ? rwlock_bug.part.2+0x50/0x50 iwlwifi 0000:06:00.0: 0x034A001C
lock+0x114/0x1d0 iwlwifi 0000:06:00.0: 0x00200000 | isr4 ? rwlock_bug.part.2+0x50/0x50 iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id ? rwlock_bug.part.2+0x50/0x50 ? lockdep_hardirqs_on_prepare+0xe/0x200 iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event ? __local_bh_enable_ip+0x87/0xe0 ? inet_send_prepare+0x220/0x220 iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control tcp_sendmsg+0x22/0x40 sock_sendmsg+0x5f/0x70 iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration __sys_sendto+0x19d/0x250 iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid ? __ia32_sys_getpeername+0x40/0x40 iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lo
.0: 0x00000000 | l2p_addr_match ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_sched_held+0x5a/0xd0 ? lock_release+0xb9/0x400 ? lock_downgrade+0x390/0x390 ? ktime_get+0x64/0x130 ? ktime_get+0x8d/0x130 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_held_common+0x12/0x50 ? rcu_read_lock_sched_held+0x5a/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? rcu_read_lock_bh_held+0xb0/0xb0 __x64_sys_sendto+0x6f/0x80 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f1d126e4531 Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8
0xb0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f1d126e4531 Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89 RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 000000000000ffdc RCX: 00007f1d126e4531 RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014 RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R ---truncated--- References: - https://git.kernel.org/stable/c/0e1e311fd929c6a8dcfddcb4748c47b07e39821f - https://g
246 R ---truncated--- References: - https://git.kernel.org/stable/c/0e1e311fd929c6a8dcfddcb4748c47b07e39821f - https://git.kernel.org/stable/c/ae966649f665bc3868b935157dd4a3c31810dcc0 - https://git.kernel.org/stable/c/d8e32f1bf1a9183a6aad560c6688500222d24299 - https://git.kernel.org/stable/c/8fabe41fba907e4fd826acbbdb42e09c681c515e - https://git.kernel.org/stable/c/3a2ecd1ec14075117ccb3e85f0fed224578ec228 - https://git.kernel.org/stable/c/0473cbae2137b963bd0eaa74336131cb1d3bc6c3
CVE ID: CVE-2022-50249 State: PUBLISHED Published: 2025-09-15T14:02:09.213Z Last Updated: 2025-09-15T14:02:09.213Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: memory: of: Fix refcount leak bug in of_get_ddr_timings() We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount. References: - https://git.kernel.org/stable/c/a4d0bd4388e1a39df47e8aaa044ef6a7ee626e48 - https://git.kernel.org/stable/c/a4f7eb83852a65b6f8dea7dcc42b7c76d4d9b0a3 - https://git.kernel.org/stable/c/68c9c4e6495b825be3a8946df1a0148399555fe4 - https://git.kernel.org/stable/c/85a40
9b0a3 - https://git.kernel.org/stable/c/68c9c4e6495b825be3a8946df1a0148399555fe4 - https://git.kernel.org/stable/c/85a40bfb8e7a170abcf9dae2c0898a1983e48daa - https://git.kernel.org/stable/c/daaec4b3fe2297b022c6b2d6bf48b6e5265a60b9 - https://git.kernel.org/stable/c/2680690f9ce4e6abbb4f559e97271c15b7eeda97 - https://git.kernel.org/stable/c/62ccab6e3376f8a22167c3b81468ae4f3e7d25f1 - https://git.kernel.org/stable/c/1c6cac6fa4d08aea161f83d38117d733b3c3a000 - https://git.kernel.org/stable/c/05215fb32010d4afb68fbdbb4d237df6e2d4567b
CVE ID: CVE-2022-50250 State: PUBLISHED Published: 2025-09-15T14:02:10.117Z Last Updated: 2025-09-15T14:02:10.117Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix use_count leakage when handling boot-on I found a use_count leakage towards supply regulator of rdev with boot-on option. ┌───────────────────┐ ┌───────────────────┐ │ regulator_dev A │ │ regulator_dev B │ │ (boot-on) │ │ (boot-on) │ │ use_count=0 │◀──supply──│ use_count=1 │ │ │ │ │ └───────────────────┘ └───────────────────┘ In case of rdev(A) configured with `regulator-boot-on', the use_count of supplying regulator(B) will increment inside regula
ase of rdev(A) configured with `regulator-boot-on', the use_count of supplying regulator(B) will increment inside regulator_enable(rdev->supply). Thus, B will acts like always-on, and further balanced regulator_enable/disable cannot actually disable it anymore. However, B was also configured with `regulator-boot-on', we wish it could be disabled afterwards. References: - https://git.kernel.org/stable/c/dc3391d49479bc2bf8a2b88dbf86fdd800882fee - https://git.kernel.org/stable/c/5bfc53df288e8ea54ca6866fb92034214940183f - https://git.kernel.org/stable/c/4b737246ff50f810d6ab4be13c1388a07f0c14b1 - https://git.kernel.org/stable/c/feb847e6591e8c7a09cc39721cc9ca74fd9a5d80 - https://git.kernel.org/sta
3c1388a07f0c14b1 - https://git.kernel.org/stable/c/feb847e6591e8c7a09cc39721cc9ca74fd9a5d80 - https://git.kernel.org/stable/c/4dd6e1cc9c7403f1ee1b7eee85bc31b797ae8347 - https://git.kernel.org/stable/c/bc6c381df5793ebcf32db88a3e65acf7870379fc - https://git.kernel.org/stable/c/0591b14ce0398125439c759f889647369aa616a0
CVE ID: CVE-2022-50251 State: PUBLISHED Published: 2025-09-15T14:02:12.331Z Last Updated: 2025-09-15T14:02:12.331Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix return value check of mmc_add_host() mmc_add_host() may return error, if we ignore its return value, the memory that allocated in mmc_alloc_host() will be leaked and it will lead a kernel crash because of deleting not added device in the remove path. So fix this by checking the return value and goto error path which will call mmc_free_host(), besides, the timer added before mmc_add_host() needs be del. And this patch fixes another missing call mmc_free
_host(), besides, the timer added before mmc_add_host() needs be del. And this patch fixes another missing call mmc_free_host() if usb_control_msg() fails. References: - https://git.kernel.org/stable/c/41ed46bdbd2878cd6567abe0974a445f8b1b8ec8 - https://git.kernel.org/stable/c/25f05d762ca5e1c685002a53dd44f68e78ca3feb - https://git.kernel.org/stable/c/a46e681151bbdacdf6b89ee8c4e5bad0555142bb - https://git.kernel.org/stable/c/3b29f8769d32016b2d89183db4d80c7a71b7e35e - https://git.kernel.org/stable/c/3049a3b927a40d89d4582ff1033cd7953be773c7 - https://git.kernel.org/stable/c/afc898019e7bf18c5eb7a0ac19852fcb1b341b3c - https://git.kernel.org/stable/c/c9e85979b59cb86f0a15defa8199d740e2b36b90 - https
898019e7bf18c5eb7a0ac19852fcb1b341b3c - https://git.kernel.org/stable/c/c9e85979b59cb86f0a15defa8199d740e2b36b90 - https://git.kernel.org/stable/c/2044b2ea77945f372ef161d1bbf814e471767ff2 - https://git.kernel.org/stable/c/0613ad2401f88bdeae5594c30afe318e93b14676