Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
appropriate unfreeze and rescan commands on hotplug events, and don't oops on hotplug if pci_bus_to_OF_node() returns NULL. [bhelgaas: tidy comments] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6e7b5f922901585b8f11e0d6cda12bda5c59fc8a - https://git.kernel.org/stable/c/2ec8ec57bb8ebde3e2a015eff80e5d66e6634fe3 - https://git.kernel.org/stable/c/473999ba937eac9776be791deed7c84a21d7880b - https://git.kernel.org/stable/c/6e7b24c71e530a6c1d656e73d8a30ee081656844 - https://git.kernel.org/stable/c/48c6935a34981bb56f35be0774ec1f30c6e386f8 - https://git.kernel.org/stable/c/1d2f63680c5719a5da92639e981c6c9a87fcee08 - https://git.kernel.org/stable/c/78d
6e386f8 - https://git.kernel.org/stable/c/1d2f63680c5719a5da92639e981c6c9a87fcee08 - https://git.kernel.org/stable/c/78d20b8c13075eae3d884c21db7a09a6bbdda5b2 - https://git.kernel.org/stable/c/a2a2a6fc2469524caa713036297c542746d148dc
CVE ID: CVE-2025-38624 State: PUBLISHED Published: 2025-08-22T16:00:32.924Z Last Updated: 2025-11-03T17:40:34.331Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: pnv_php: Clean up allocated IRQs on unplug When the root of a nested PCIe bridge configuration is unplugged, the pnv_php driver leaked the allocated IRQ resources for the child bridges' hotplug event notifications, resulting in a panic. Fix this by walking all child buses and deallocating all its IRQ resources before calling pci_hp_remove_devices(). Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so that it is only destroyed in pnv_php_free_sl
(). Also modify the lifetime of the workqueue at struct pnv_php_slot::wq so that it is only destroyed in pnv_php_free_slot(), instead of pnv_php_disable_irq(). This is required since pnv_php_disable_irq() will now be called by workers triggered by hot unplug interrupts, so the workqueue needs to stay allocated. The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_
liable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec [bhelgaas: tidy comments] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/8c1ad4af160691e157d688ad9619ced2df556aac - https://git.kernel.org/stable/c/912e200240b6f9758f0b126e64a61c9227f4ad37 - https://git.ke
91e157d688ad9619ced2df556aac - https://git.kernel.org/stable/c/912e200240b6f9758f0b126e64a61c9227f4ad37 - https://git.kernel.org/stable/c/398170b7fd0e0db2f8096df5206c75e5ff41415a - https://git.kernel.org/stable/c/32173edf3fe2d447e14e5e3b299387c6f9602a88 - https://git.kernel.org/stable/c/28aa3cfce12487614219e7667ec84424e1f43227 - https://git.kernel.org/stable/c/1773c19fa55e944cdd2634e2d9e552f87f2d38d5 - https://git.kernel.org/stable/c/bbd302c4b79df10197ffa7270ca3aa572eeca33c - https://git.kernel.org/stable/c/4668619092554e1b95c9a5ac2941ca47ba6d548a
CVE ID: CVE-2025-38625 State: PUBLISHED Published: 2025-08-22T16:00:33.860Z Last Updated: 2025-09-29T05:55:01.599Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vfio/pds: Fix missing detach_ioas op When CONFIG_IOMMUFD is enabled and a device is bound to the pds_vfio_pci driver, the following WARN_ON() trace is seen and probe fails: WARNING: CPU: 0 PID: 5040 at drivers/vfio/vfio_main.c:317 __vfio_register_dev+0x130/0x140 [vfio] <...> pds_vfio_pci 0000:08:00.1: probe with driver pds_vfio_pci failed with error -22 This is because the driver's vfio_device_ops.detach_ioas isn't set. Fix this by using the generic vfio_iommufd_physic
22 This is because the driver's vfio_device_ops.detach_ioas isn't set. Fix this by using the generic vfio_iommufd_physical_detach_ioas function. References: - https://git.kernel.org/stable/c/7dbfae90c5a33f6b694e7068bc9522cc2655373d - https://git.kernel.org/stable/c/1df8150ab4cc422bddfbd312d6758c50b688a971 - https://git.kernel.org/stable/c/b265dff9fcf047f660976a5c92c83e7c414a2d95 - https://git.kernel.org/stable/c/88b962fbd0ac30a65d2869c68d2f145be46ebe4d - https://git.kernel.org/stable/c/fe24d5bc635e103a517ec201c3cb571eeab8be2f
CVE ID: CVE-2025-38626 State: PUBLISHED Published: 2025-08-22T16:00:34.867Z Last Updated: 2025-09-29T05:55:03.699Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode w/ "mode=lfs" mount option, generic/299 will cause system panic as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: <TASK> f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sy
430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_bl
ly. In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks(). References: - https://git.kernel.org/stable/c/f289690f50a01c3e085d87853392d5b7436a4cee - https://git.kernel.org/stable/c/82765ce5c7a56f9309ee45328e763610eaf11253 - https://git.kernel.org/stable/c/264ede8a52f18647ed5bb5f2bd9bf54f556ad8f5 - https://git.kernel.org/stable/c/385e64a0744584397b4b52b27c96703516f39968 - https://git.kernel.org/stable/c/1005a3ca28e90c7a64fa43023f866b960a60f791
CVE ID: CVE-2025-38627 State: PUBLISHED Published: 2025-08-22T16:00:35.856Z Last Updated: 2025-09-29T05:55:05.007Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic The decompress_io_ctx may be released asynchronously after I/O completion. If this file is deleted immediately after read, and the kworker of processing post_read_wq has not been executed yet due to high workloads, It is possible that the inode(f2fs_inode_info) is evicted and freed before it is used f2fs_free_dic. The UAF case as below: Thread A Thread B - f2fs_decompress_end_io - f2fs_put_dic - queue_work add
is used f2fs_free_dic. The UAF case as below: Thread A Thread B - f2fs_decompress_end_io - f2fs_put_dic - queue_work add free_dic work to post_read_wq - do_unlink - iput - evict - call_rcu This file is deleted after read. Thread C kworker to process post_read_wq - rcu_do_batch - f2fs_free_inode - kmem_cache_free inode is freed by rcu - process_scheduled_works - f2fs_late_free_dic - f2fs_free_dic - f2fs_release_decomp_mem read (dic->inode)->i_compress_algorithm This patch store compress_algorithm and sbi in dic to avoid inode UAF. In addition, the previous solution is deprecated in [1] may cause system hang. [1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org Refer
ated in [1] may cause system hang. [1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org References: - https://git.kernel.org/stable/c/8fae5b6addd5f6895e03797b56e3c7b9f9cd15c9 - https://git.kernel.org/stable/c/39868685c2a94a70762bc6d77dc81d781d05bff5
CVE ID: CVE-2025-38628 State: PUBLISHED Published: 2025-08-22T16:00:36.841Z Last Updated: 2025-09-29T05:55:06.134Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix release of uninitialized resources on error path The commit in the fixes tag made sure that mlx5_vdpa_free() is the single entrypoint for removing the vdpa device resources added in mlx5_vdpa_dev_add(), even in the cleanup path of mlx5_vdpa_dev_add(). This means that all functions from mlx5_vdpa_free() should be able to handle uninitialized resources. This was not the case though: mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx() were not
ized resources. This was not the case though: mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx() were not able to do so. This caused the splat below when adding a vdpa device without a MAC address. This patch fixes these remaining issues: - Makes mlx5_vdpa_destroy_mr_resources() return early if called on uninitialized resources. - Moves mlx5_cmd_init_async_ctx() early on during device addition because it can't fail. This means that mlx5_cmd_cleanup_async_ctx() also can't fail. To mirror this, move the call site of mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free(). An additional comment was added in mlx5_vdpa_free() to document the expectations of functions called from this cont
e(). An additional comment was added in mlx5_vdpa_free() to document the expectations of functions called from this context. Splat: mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned? ------------[ cut here ]------------ WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0 [...] Call Trace: <TASK> ? __try_to_del_timer_sync+0x61/0x90 ? __timer_delete_sync+0x2b/0x40 mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa] mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa]
x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa] genl_family_rcv_msg_doit+0xd8/0x130 genl_family_rcv_msg+0x14b/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] genl_rcv_msg+0x47/0xa0 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x27b/0x3b0 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x1fa/0x210 ? ___pte_offset_map+0x17/0x160 ? next_uptodate_folio+0x85/0x2b0 ? percpu_counter_add_batch+0x51/0x90 ? filemap_map_pages+0x515/0x660 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x7b/0x2c0 ? do_read_fault+0x108/0x220 ? do_pte_missing+0x14a/0x3e0 ? __handle_mm_fault+0x321/0x730 ?
x30 do_syscall_64+0x7b/0x2c0 ? do_read_fault+0x108/0x220 ? do_pte_missing+0x14a/0x3e0 ? __handle_mm_fault+0x321/0x730 ? count_memcg_events+0x13f/0x180 ? handle_mm_fault+0x1fb/0x2d0 ? do_user_addr_fault+0x20c/0x700 ? syscall_exit_work+0x104/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0c25b0feca [...] ---[ end trace 0000000000000000 ]--- References: - https://git.kernel.org/stable/c/37f26b9013b46457b0a96633fc3a7dc977d8beb1 - https://git.kernel.org/stable/c/cf4fc23d0d3d5b89b36f0d79f2674510bb574d8e - https://git.kernel.org/stable/c/6de4ef950dd56a6a81daf92d8a1d864fc6a56971 - https://git.kernel.org/stable/c/cc51a66815999afb7e9cd845968de4fdf07567b7
CVE ID: CVE-2025-38629 State: PUBLISHED Published: 2025-08-22T16:00:37.747Z Last Updated: 2025-09-29T05:55:07.297Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: usb: scarlett2: Fix missing NULL check scarlett2_input_select_ctl_info() sets up the string arrays allocated via kasprintf(), but it misses NULL checks, which may lead to NULL dereference Oops. Let's add the proper NULL check. References: - https://git.kernel.org/stable/c/d558db85920b124bac36f8a7ddc5de0aa7491bdd - https://git.kernel.org/stable/c/2c735fcaee81ad8056960659dc9dc460891e76b0 - https://git.kernel.org/stable/c/df485a4b2b3ee5b35c80f990beb554e38a8a5fb1
CVE ID: CVE-2025-38630 State: PUBLISHED Published: 2025-08-22T16:00:38.678Z Last Updated: 2025-11-03T17:40:35.268Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref fb_add_videomode() can fail with -ENOMEM when its internal kmalloc() cannot allocate a struct fb_modelist. If that happens, the modelist stays empty but the driver continues to register. Add a check for its return value to prevent poteintial null-ptr-deref, which is similar to the commit 17186f1f90d3 ("fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var"). Additional Analyst
7186f1f90d3 ("fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var"). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/69373502c2b5d364842c702c941d1171e4f35a7c - https://git.kernel.org/stable/c/f00c29e6755ead56baf2a9c1d3c4c0bb40af3612 - https://git.kernel.org/stable/c/cca8f5a3991916729b39d797d01499c335137319 - https://git.kernel.org/stable/c/ac16154cccda8be10ee3ae188f10a06f3890bc5d - https://git.kernel.org/stable/c/4b5d36cc3014986e6fac12eaa8433fe56801d4ce - https://git.kernel.org/stable/c/40f0a51f6c54d46a94b9f1180339ede7ca7ee190 - https://git.kernel.org/stable/c/49377bac9e3bec1635065a033c9679214fe7593e - https://g
f6c54d46a94b9f1180339ede7ca7ee190 - https://git.kernel.org/stable/c/49377bac9e3bec1635065a033c9679214fe7593e - https://git.kernel.org/stable/c/f060441c153495750804133555cf0a211a856892 - https://git.kernel.org/stable/c/da11e6a30e0bb8e911288bdc443b3dc8f6a7cac7
CVE ID: CVE-2025-38631 State: PUBLISHED Published: 2025-08-22T16:00:39.582Z Last Updated: 2025-09-29T05:55:09.669Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: imx95-blk-ctl: Fix synchronous abort When enabling runtime PM for clock suppliers that also belong to a power domain, the following crash is thrown: error: synchronous external abort: 0000000096000010 [#1] PREEMPT SMP Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : clk_mux_get_parent+0x60/0x90 lr : clk_core_reparent_orphans_nolock+0x58/0xd8 Call trace: clk_mux_get_parent+0x60/0x90 clk_core_rep
t_parent+0x60/0x90 lr : clk_core_reparent_orphans_nolock+0x58/0xd8 Call trace: clk_mux_get_parent+0x60/0x90 clk_core_reparent_orphans_nolock+0x58/0xd8 of_clk_add_hw_provider.part.0+0x90/0x100 of_clk_add_hw_provider+0x1c/0x38 imx95_bc_probe+0x2e0/0x3f0 platform_probe+0x70/0xd8 Enabling runtime PM without explicitly resuming the device caused the power domain cut off after clk_register() is called. As a result, a crash happens when the clock hardware provider is added and attempts to access the BLK_CTL register. Fix this by using devm_pm_runtime_enable() instead of pm_runtime_enable() and getting rid of the pm_runtime_disable() in the cleanup path. References: - https://git.kernel.org/stable/c
_enable() and getting rid of the pm_runtime_disable() in the cleanup path. References: - https://git.kernel.org/stable/c/c1dead8bb303f86905ea6a09e5acda931165453b - https://git.kernel.org/stable/c/9f0ee0baf25b46bb82655c687718ebb0ae1def7b - https://git.kernel.org/stable/c/533dc3cb375cabd8a2beba293d63ef2acd3d0005 - https://git.kernel.org/stable/c/b08217a257215ed9130fce93d35feba66b49bf0a
CVE ID: CVE-2025-38632 State: PUBLISHED Published: 2025-08-22T16:00:40.423Z Last Updated: 2025-09-29T05:55:10.837Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pinmux: fix race causing mux_owner NULL with active mux_usecount commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer. The issue occurs due
ot completely fixed due to the way it was handled and it can still result in the same NULL pointer. The issue occurs due to the following interleaving: cpu0 (process A) cpu1 (process B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //becomes 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux) This sequence leads to a state where the pin appears to be in use (`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can cause NULL pointer on next pin_request on the same pin. Ensure that updates to mux_usecount and mux_owner
`), which can cause NULL pointer on next pin_request on the same pin. Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned. References: - https://git.kernel.org/stable/c/9b2a3e7189028aa7c4d53a84364f2ea9fb209787 - https://git.kernel.org/stable/c/9ea3f6b9a67be3476e331ce51cac316c2614a564 - https://git.kernel.org/stable/c/b7bd6e3971eb7f0e34d2fdce1b18b08094e0c804 - https://git.kernel.org/stable/c/22b585cbd67d14df3b91529d1b990661c300faa9 - https://git.kernel.org/stable/c/0b075c011032f88d1cfde3b45d6dcf08b44140eb
CVE ID: CVE-2025-38633 State: PUBLISHED Published: 2025-08-22T16:00:41.434Z Last Updated: 2025-09-29T05:55:11.972Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: spacemit: mark K1 pll1_d8 as critical The pll1_d8 clock is enabled by the boot loader, and is ultimately a parent for numerous clocks, including those used by APB and AXI buses. Guodong Xu discovered that this clock got disabled while responding to getting -EPROBE_DEFER when requesting a reset controller. The needed clock (CLK_DMA, along with its parents) had already been enabled. To respond to the probe deferral return, the CLK_DMA clock was disabled, and this le
parents) had already been enabled. To respond to the probe deferral return, the CLK_DMA clock was disabled, and this led to parent clocks also reducing their enable count. When the enable count for pll1_d8 was decremented it became 0, which caused it to be disabled. This led to a system hang. Marking that clock critical resolves this by preventing it from being disabled. Define a new macro CCU_FACTOR_GATE_DEFINE() to allow clock flags to be supplied for a CCU_FACTOR_GATE clock. References: - https://git.kernel.org/stable/c/10948c00e548e9ad2ce9d765baf26dce2d9b806b - https://git.kernel.org/stable/c/7554729de27daf6d54bcf8689d863bbe267828bf
CVE ID: CVE-2025-38634 State: PUBLISHED Published: 2025-08-22T16:00:42.376Z Last Updated: 2025-11-03T17:40:36.216Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: power: supply: cpcap-charger: Fix null check for power_supply_get_by_name In the cpcap_usb_detect() function, the power_supply_get_by_name() function may return `NULL` instead of an error pointer. To prevent potential null pointer dereferences, Added a null check. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/4ebbb9106aaa2fd58e0359bc3a2490953db2ef0c - https://git.kernel.org/stable/c/a2436263144980cc99a9860c7b43335847af
stable/c/4ebbb9106aaa2fd58e0359bc3a2490953db2ef0c - https://git.kernel.org/stable/c/a2436263144980cc99a9860c7b43335847afbe53 - https://git.kernel.org/stable/c/8e9bdb563916287ba1b4258812434e0585ac6d00 - https://git.kernel.org/stable/c/f642500aa7ed93d2606e4f929244cce9c7467b3a - https://git.kernel.org/stable/c/9784d832d7c103539cd9afb376534eaa35815d3d - https://git.kernel.org/stable/c/27001e4f146624c4b3389b029bdc0f8049819560 - https://git.kernel.org/stable/c/d9fa3aae08f99493e67fb79413c0e95d30fca5e9
CVE ID: CVE-2025-38635 State: PUBLISHED Published: 2025-08-22T16:00:43.181Z Last Updated: 2025-11-03T17:40:38.124Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: clk: davinci: Add NULL check in davinci_lpsc_clk_register() devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/77e9ad7a2d0e2a771c9e0be04b9d1639413b
alyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/77e9ad7a2d0e2a771c9e0be04b9d1639413b5f13 - https://git.kernel.org/stable/c/7843412e5927dafbb844782c56b6380564064109 - https://git.kernel.org/stable/c/2adc945b70c4d97e9491a6c0c9f3b217a9eecfba - https://git.kernel.org/stable/c/105e8115944a9f93e9412abe7bb07ed96725adf9 - https://git.kernel.org/stable/c/1d92608a29251278015f57f3572bc950db7519f0 - https://git.kernel.org/stable/c/7943ed1f05f5cb7372dca2aa227f848747a98791 - https://git.kernel.org/stable/c/6fb19cdcf040e1dec052a9032acb66cc2ad1d43f - https://git.kernel.org/stable/c/23f564326deaafacfd7adf6104755b15216d8320 - https://git.kernel.org/stable/c/13de464f445d4273
ps://git.kernel.org/stable/c/23f564326deaafacfd7adf6104755b15216d8320 - https://git.kernel.org/stable/c/13de464f445d42738fe18c9a28bab056ba3a290a
CVE ID: CVE-2025-38636 State: PUBLISHED Published: 2025-08-22T16:00:43.910Z Last Updated: 2025-09-29T05:55:15.703Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rv: Use strings in da monitors tracepoints Using DA monitors tracepoints with KASAN enabled triggers the following warning: BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Read of size 32 at addr ffffffffaada8980 by task ... Call Trace: <TASK> [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200 trace_event_sncid+0x163/0x200 [...] Th
o_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200 trace_event_sncid+0x163/0x200 [...] The buggy address belongs to the variable: automaton_snep+0x4e0/0x5e0 This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g. the next automaton's data in this case). The error is harmless as, while printing the string, we stop at the null terminator, but it should still be fixed. Use the __string facilities while defining the tracepoints to avoid reading out of bound memory. References: - https://git.kernel.org/stable/c/0ebc70d973c
defining the tracepoints to avoid reading out of bound memory. References: - https://git.kernel.org/stable/c/0ebc70d973ce7a81826b5c4f55f743e07f5864d9 - https://git.kernel.org/stable/c/7f904ff6e58d398c4336f3c19c42b338324451f7