Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-21654 State: PUBLISHED Published: 2025-01-19T10:18:11.104Z Last Updated: 2025-05-04T07:18:19.475Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ovl: support encoding fid from inode with no alias Dmitry Safonov reported that a WARN_ON() assertion can be trigered by userspace when calling inotify_show_fdinfo() for an overlayfs watched inode, whose dentry aliases were discarded with drop_caches. The WARN_ON() assertion in inotify_show_fdinfo() was removed, because it is possible for encoding file handle to fail for other reason, but the impact of failing to encode an overlayfs file handle goes beyond this asserti
e handle to fail for other reason, but the impact of failing to encode an overlayfs file handle goes beyond this assertion. As shown in the LTP test case mentioned in the link below, failure to encode an overlayfs file handle from a non-aliased inode also leads to failure to report an fid with FAN_DELETE_SELF fanotify events. As Dmitry notes in his analyzis of the problem, ovl_encode_fh() fails if it cannot find an alias for the inode, but this failure can be fixed. ovl_encode_fh() seldom uses the alias and in the case of non-decodable file handles, as is often the case with fanotify fid info, ovl_encode_fh() never needs to use the alias to encode a file handle. Defer finding an alias until
h fanotify fid info, ovl_encode_fh() never needs to use the alias to encode a file handle. Defer finding an alias until it is actually needed so ovl_encode_fh() will not fail in the common case of FAN_DELETE_SELF fanotify events. References: - https://git.kernel.org/stable/c/f0c0ac84de17c37e6e84da65fb920f91dada55ad - https://git.kernel.org/stable/c/3c7c90274ae339e1ad443c9be1c67a20b80b9c76 - https://git.kernel.org/stable/c/c45beebfde34aa71afbc48b2c54cdda623515037
CVE ID: CVE-2025-21655 State: PUBLISHED Published: 2025-01-20T13:48:40.544Z Last Updated: 2025-11-03T20:58:34.729Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period io_eventfd_do_signal() is invoked from an RCU callback, but when dropping the reference to the io_ev_fd, it calls io_eventfd_free() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the io_ev_fd should be deferred another RCU grace period. Just call io_eventfd_put() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace
call io_eventfd_put() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6b63308c28987c6010b1180c72a6db4df6c68033 - https://git.kernel.org/stable/c/8efff2aa2d95dc437ab67c5b4a9f1d3f367baa10 - https://git.kernel.org/stable/c/a7085c3ae43b86d4b3d1b8275e6a67f14257e3b7 - https://git.kernel.org/stable/c/c9a40292a44e78f71258b8522655bffaf5753bdb - https://project-zero.issues.chromium.org/issues/388499293
CVE ID: CVE-2025-21656 State: PUBLISHED Published: 2025-01-21T12:18:13.222Z Last Updated: 2025-05-04T07:18:21.781Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur scsi_execute_cmd() function can return both negative (linux codes) and positive (scsi_cmnd result field) error codes. Currently the driver just passes error codes of scsi_execute_cmd() to hwmon core, which is incorrect because hwmon only checks for negative error codes. This leads to hwmon reporting uninitialized data to userspace in case of SCSI errors (for example if the disk drive was discon
eads to hwmon reporting uninitialized data to userspace in case of SCSI errors (for example if the disk drive was disconnected). This patch checks scsi_execute_cmd() output and returns -EIO if it's error code is positive. [groeck: Avoid inline variable declaration for portability] References: - https://git.kernel.org/stable/c/53e25b10a28edaf8c2a1d3916fd8929501a50dfc - https://git.kernel.org/stable/c/42268d885e44af875a6474f7bba519cc6cea6a9d - https://git.kernel.org/stable/c/82163d63ae7a4c36142cd252388737205bb7e4b9
CVE ID: CVE-2025-21657 State: PUBLISHED Published: 2025-01-21T12:18:13.893Z Last Updated: 2025-05-04T07:18:22.917Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched_ext: Replace rq_lock() to raw_spin_rq_lock() in scx_ops_bypass() scx_ops_bypass() iterates all CPUs to re-enqueue all the scx tasks. For each CPU, it acquires a lock using rq_lock() regardless of whether a CPU is offline or the CPU is currently running a task in a higher scheduler class (e.g., deadline). The rq_lock() is supposed to be used for online CPUs, and the use of rq_lock() may trigger an unnecessary warning in rq_pin_lock(). Therefore, replace rq_lock()
online CPUs, and the use of rq_lock() may trigger an unnecessary warning in rq_pin_lock(). Therefore, replace rq_lock() to raw_spin_rq_lock() in scx_ops_bypass(). Without this change, we observe the following warning: ===== START ===== [ 6.615205] rq->balance_callback && rq->balance_callback != &balance_push_callback [ 6.615208] WARNING: CPU: 2 PID: 0 at kernel/sched/sched.h:1730 __schedule+0x1130/0x1c90 ===== END ===== References: - https://git.kernel.org/stable/c/d9e446dd63cee7161717a6a8414ba9c6435af764 - https://git.kernel.org/stable/c/6268d5bc10354fc2ab8d44a0cd3b042d49a0417e
CVE ID: CVE-2025-21658 State: PUBLISHED Published: 2025-01-21T12:18:14.578Z Last Updated: 2025-10-01T19:57:13.496Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid NULL pointer dereference if no valid extent tree [BUG] Syzbot reported a crash with the following call trace: BTRFS info (device loop0): scrub: started on devid 1 BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G
PUD 107143067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G O 6.13.0-rc4-custom+ #206 Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs] Call Trace: <TASK> scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs] scrub_simple_mirror+0x175/0x260 [btrfs] scrub_stripe+0x5d4/0x6c0 [btrfs] scrub_chunk+0xbb/0x170 [btrfs] scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs] btrfs_scrub_dev+0x240/0x600 [btrfs] btrfs_ioctl+0x1dc8/0x2fa0 [btrfs] ? do_sys_openat2+0xa5/0xf0 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x
fs] ? do_sys_openat2+0xa5/0xf0 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> [CAUSE] The reproducer is using a corrupted image where extent tree root is corrupted, thus forcing to use "rescue=all,ro" mount option to mount the image. Then it triggered a scrub, but since scrub relies on extent tree to find where the data/metadata extents are, scrub_find_fill_first_stripe() relies on an non-empty extent root. But unfortunately scrub_find_fill_first_stripe() doesn't really expect an NULL pointer for extent root, it use extent_root to grab fs_info and triggered a NULL pointer dereference. [FIX] Add an extra check for a valid extent root at the
t_root to grab fs_info and triggered a NULL pointer dereference. [FIX] Add an extra check for a valid extent root at the beginning of scrub_find_fill_first_stripe(). The new error path is introduced by 42437a6386ff ("btrfs: introduce mount option rescue=ignorebadroots"), but that's pretty old, and later commit b979547513ff ("btrfs: scrub: introduce helper to find and fill sector info for a scrub_stripe") changed how we do scrub. So for kernels older than 6.6, the fix will need manual backport. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/24b85a8b0310e0144da9ab30be42e87e6476638a - https://git.kernel.org/stable/c/aee5f69f3e6cd82bfefaca1b70b40
el.org/stable/c/24b85a8b0310e0144da9ab30be42e87e6476638a - https://git.kernel.org/stable/c/aee5f69f3e6cd82bfefaca1b70b40b6cd8f3f784 - https://git.kernel.org/stable/c/6aecd91a5c5b68939cf4169e32bc49f3cd2dd329
CVE ID: CVE-2025-21659 State: PUBLISHED Published: 2025-01-21T12:18:15.407Z Last Updated: 2025-05-04T07:18:25.265Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netdev: prevent accessing NAPI instances from another namespace The NAPI IDs were not fully exposed to user space prior to the netlink API, so they were never namespaced. The netlink API must ensure that at the very least NAPI instance belongs to the same netns as the owner of the genl sock. napi_by_id() can become static now, but it needs to move because of dev_get_by_napi_id(). References: - https://git.kernel.org/stable/c/b683ba0df11ff563cc237eb1b74d6adfa77226bf - h
ause of dev_get_by_napi_id(). References: - https://git.kernel.org/stable/c/b683ba0df11ff563cc237eb1b74d6adfa77226bf - https://git.kernel.org/stable/c/d1cacd74776895f6435941f86a1130e58f6dd226
CVE ID: CVE-2025-21660 State: PUBLISHED Published: 2025-01-21T12:18:16.062Z Last Updated: 2025-11-03T20:58:36.129Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix unexpectedly changed path in ksmbd_vfs_kern_path_locked When `ksmbd_vfs_kern_path_locked` met an error and it is not the last entry, it will exit without restoring changed path buffer. But later this buffer may be used as the filename for creation. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/13e41c58c74baa71f34c0830eaa3c29d53a6e964 - https://git.kernel.org/stable/c/65b31b9d992c0fb0685c51a0cf09993832734fc4
e/c/13e41c58c74baa71f34c0830eaa3c29d53a6e964 - https://git.kernel.org/stable/c/65b31b9d992c0fb0685c51a0cf09993832734fc4 - https://git.kernel.org/stable/c/51669f4af5f7959565b48e55691ba92fabf5c587 - https://git.kernel.org/stable/c/2ac538e40278a2c0c051cca81bcaafc547d61372
CVE ID: CVE-2025-21661 State: PUBLISHED Published: 2025-01-21T12:18:16.902Z Last Updated: 2025-10-01T19:57:13.331Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gpio: virtuser: fix missing lookup table cleanups When a virtuser device is created via configfs and the probe fails due to an incorrect lookup table, the table is not removed. This prevents subsequent probe attempts from succeeding, even if the issue is corrected, unless the device is released. Additionally, cleanup is also needed in the less likely case of platform_device_register_full() failure. Besides, a consistent memory leak in lookup_table->dev_id was spotted u
case of platform_device_register_full() failure. Besides, a consistent memory leak in lookup_table->dev_id was spotted using kmemleak by toggling the live state between 0 and 1 with a correct lookup table. Introduce gpio_virtuser_remove_lookup_table() as the counterpart to the existing gpio_virtuser_make_lookup_table() and call it from all necessary points to ensure proper cleanup. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d72d0126b1f6981f6ce8b4247305f359958c11b5 - https://git.kernel.org/stable/c/a619cba8c69c434258ff4101d463322cd63e1bdc
CVE ID: CVE-2025-21662 State: PUBLISHED Published: 2025-01-21T12:18:17.674Z Last Updated: 2025-11-03T20:58:37.583Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix variable not being completed when function returns When cmd_alloc_index(), fails cmd_work_handler() needs to complete ent->slotted before returning early. Otherwise the task which issued the command may hang: mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry INFO: task kworker/13:2:4055883 blocked for more than 120 seconds. Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeo
ed for more than 120 seconds. Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/13:2 D 0 4055883 2 0x00000228 Workqueue: events mlx5e_tx_dim_work [mlx5_core] Call trace: __switch_to+0xe8/0x150 __schedule+0x2a8/0x9b8 schedule+0x2c/0x88 schedule_timeout+0x204/0x478 wait_for_common+0x154/0x250 wait_for_completion+0x28/0x38 cmd_exec+0x7a0/0xa00 [mlx5_core] mlx5_cmd_exec+0x54/0x80 [mlx5_core] mlx5_core_modify_cq+0x6c/0x80 [mlx5_core] mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core] mlx5e_tx_dim_work+0x54/0x68 [mlx5_core] process_one_work+0x1b0/0x448 worker_thread+0x54/0x468 kthread+0x134/0x138 ret_from_fork+0x10/0
ork+0x54/0x68 [mlx5_core] process_one_work+0x1b0/0x448 worker_thread+0x54/0x468 kthread+0x134/0x138 ret_from_fork+0x10/0x18 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f0a2808767ac39f64b1d9a0ff865c255073cf3d4 - https://git.kernel.org/stable/c/229cc10284373fbe754e623b7033dca7e7470ec8 - https://git.kernel.org/stable/c/36124081f6ffd9dfaad48830bdf106bb82a9457d - https://git.kernel.org/stable/c/0e2909c6bec9048f49d0c8e16887c63b50b14647
CVE ID: CVE-2025-21663 State: PUBLISHED Published: 2025-01-21T12:18:18.347Z Last Updated: 2025-05-04T07:18:29.588Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: stmmac: dwmac-tegra: Read iommu stream id from device tree Nvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be written to the MGBE_WRAP_AXI_ASID0_CTRL register. The current driver is hard coded to use MGBE0's SID for all controllers. This causes softirq time outs and kernel panics when using controllers other than MGBE0. Example dmesg errors when an ethernet cable is connected to MGBE1: [ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is
mple dmesg errors when an ethernet cable is connected to MGBE1: [ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms [ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter. [ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171) [ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features [ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported [ 121.908399] tegra-mgbe
res [ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported [ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock [ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode [ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337 [ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8) [ 181.921878] Sending NMI from CPU 4 to CPUs 7: [ 181.921886] NMI backtrace for cpu 7 [ 181.922131] CPU: 7 UID:
ncpus=8) [ 181.921878] Sending NMI from CPU 4 to CPUs 7: [ 181.921886] NMI backtrace for cpu 7 [ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6 [ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024 [ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 181.922847] pc : handle_softirqs+0x98/0x368 [ 181.922978] lr : __do_softirq+0x18/0x20 [ 181.923095] sp : ffff80008003bf50 [ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000 [ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0 [ 181.924486] x23: 0000000060400009 x22: ffffce78e999
x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0 [ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70 [ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000 [ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000 [ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d [ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160 [ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74 [ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1 [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe
bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1 [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000 [ 181.967591] Call trace: [ 181.970043] handle_softirqs+0x98/0x368 (P) [ 181.974240] __do_softirq+0x18/0x20 [ 181.977743] ____do_softirq+0x14/0x28 [ 181.981415] call_on_irq_stack+0x24/0x30 [ 181.985180] do_softirq_own_stack+0x20/0x30 [ 181.989379] __irq_exit_rcu+0x114/0x140 [ 181.993142] irq_exit_rcu+0x14/0x28 [ 181.996816] el1_interrupt+0x44/0xb8 [ 182.000316] el1h_64_irq_handler+0x14/0x20 [ 182.004343] el1h_64_irq+0x80/0x88 [ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P) [ 182.012305] cpuidle_enter+0x3c/0x58 [ 182.015980] cpuidle_idle_call+0x128/0x1c0 [ 182.020005
nter_state+0xc4/0x4a8 (P) [ 182.012305] cpuidle_enter+0x3c/0x58 [ 182.015980] cpuidle_idle_call+0x128/0x1c0 [ 182.020005] do_idle+0xe0/0xf0 [ 182.023155] cpu_startup_entry+0x3c/0x48 [ 182.026917] secondary_start_kernel+0xdc/0x120 [ 182.031379] __secondary_switched+0x74/0x78 [ 212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/. [ 212.985935] rcu: blocking rcu_node structures (internal RCU debug): [ 212.992758] Sending NMI from CPU 0 to CPUs 7: [ 212.998539] NMI backtrace for cpu 7 [ 213.004304] CPU: 7 UID: 0 PI ---truncated--- References: - https://git.kernel.org/stable/c/235419f0956e8c60e597aa1619ded8bda7460bb4 - https://git
PI ---truncated--- References: - https://git.kernel.org/stable/c/235419f0956e8c60e597aa1619ded8bda7460bb4 - https://git.kernel.org/stable/c/b04d33cdbc958a3fd57f3544d4f78b99d9d11909 - https://git.kernel.org/stable/c/426046e2d62dd19533808661e912b8e8a9eaec16
CVE ID: CVE-2025-21664 State: PUBLISHED Published: 2025-01-21T12:18:19.015Z Last Updated: 2025-11-03T20:58:40.356Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm thin: make get_first_thin use rcu-safe list first function The documentation in rculist.h explains the absence of list_empty_rcu() and cautions programmers against relying on a list_empty() -> list_first() sequence in RCU safe code. This is because each of these functions performs its own READ_ONCE() of the list head. This can lead to a situation where the list_empty() sees a valid list entry, but the subsequent list_first() sees a different view of list head state
here the list_empty() sees a valid list entry, but the subsequent list_first() sees a different view of list head state after a modification. In the case of dm-thin, this author had a production box crash from a GP fault in the process_deferred_bios path. This function saw a valid list head in get_first_thin() but when it subsequently dereferenced that and turned it into a thin_c, it got the inside of the struct pool, since the list was now empty and referring to itself. The kernel on which this occurred printed both a warning about a refcount_t being saturated, and a UBSAN error for an out-of-bounds cpuid access in the queued spinlock, prior to the fault itself. When the resulting kdump was
error for an out-of-bounds cpuid access in the queued spinlock, prior to the fault itself. When the resulting kdump was examined, it was possible to see another thread patiently waiting in thin_dtr's synchronize_rcu. The thin_dtr call managed to pull the thin_c out of the active thins list (and have it be the last entry in the active_thins list) at just the wrong moment which lead to this crash. Fortunately, the fix here is straight forward. Switch get_first_thin() function to use list_first_or_null_rcu() which performs just a single READ_ONCE() and returns NULL if the list is already empty. This was run against the devicemapper test suite's thin-provisioning suites for delete and suspend a
t is already empty. This was run against the devicemapper test suite's thin-provisioning suites for delete and suspend and no regressions were observed. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ec037fe8c0d0f6140e3d8a49c7b29cb5582160b8 - https://git.kernel.org/stable/c/cd30a3960433ec2db94b3689752fa3c5df44d649 - https://git.kernel.org/stable/c/802666a40c71a23542c43a3f87e3a2d0f4e8fe45 - https://git.kernel.org/stable/c/12771050b6d059eea096993bf2001da9da9fddff - https://git.kernel.org/stable/c/6b305e98de0d225ccebfb225730a9f560d28ecb0 - https://git.kernel.org/stable/c/cbd0d5ecfa390ac29c5380200147d09c381b2ac6 - https://git.kernel.org/stable/c/
560d28ecb0 - https://git.kernel.org/stable/c/cbd0d5ecfa390ac29c5380200147d09c381b2ac6 - https://git.kernel.org/stable/c/80f130bfad1dab93b95683fc39b87235682b8f72
CVE ID: CVE-2025-21665 State: PUBLISHED Published: 2025-01-31T11:25:30.468Z Last Updated: 2025-11-03T20:58:41.781Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: filemap: avoid truncating 64-bit offset to 32 bits On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a 64-bit value to 32 bits, leading to a possible infinite loop when writing to an xfs filesystem. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/64e5fd96330df2ad278d1c4edcca581f26e5f76e - https://git.kernel.org/stable/c/80fc836f3ebe2f2d2d2c80c698b7667974285a04 - https://git.k
df2ad278d1c4edcca581f26e5f76e - https://git.kernel.org/stable/c/80fc836f3ebe2f2d2d2c80c698b7667974285a04 - https://git.kernel.org/stable/c/09528bb1a4123e2a234eac2bc45a0e51e78dab43 - https://git.kernel.org/stable/c/280f1fb89afc01e7376f59ae611d54ca69e9f967 - https://git.kernel.org/stable/c/f505e6c91e7a22d10316665a86d79f84d9f0ba76
CVE ID: CVE-2025-21666 State: PUBLISHED Published: 2025-01-31T11:25:31.138Z Last Updated: 2025-11-03T20:58:44.611Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vsock: prevent null-ptr-deref in vsock_*[has_data|has_space] Recent reports have shown how we sometimes call vsock_*_has_data() when a vsock socket has been de-assigned from a transport (see attached links), but we shouldn't. Previous commits should have solved the real problems, but we may have more in the future, so to avoid null-ptr-deref, we can return 0 (no space, no data available) but with a warning. This way the code should continue to run in a nearly consisten
eturn 0 (no space, no data available) but with a warning. This way the code should continue to run in a nearly consistent state and have a warning that allows us to debug future problems. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/daeac89cdb03d30028186f5ff7dc26ec8fa843e7 - https://git.kernel.org/stable/c/9e5fed46ccd2c34c5fa5a9c8825ce4823fdc853e - https://git.kernel.org/stable/c/b52e50dd4fabd12944172bd486a4f4853b7f74dd - https://git.kernel.org/stable/c/bc9c49341f9728c31fe248c5fbba32d2e81a092b - https://git.kernel.org/stable/c/c23d1d4f8efefb72258e9cedce29de10d057f8ca - https://git.kernel.org/stable/c/91751e248256efc
tps://git.kernel.org/stable/c/c23d1d4f8efefb72258e9cedce29de10d057f8ca - https://git.kernel.org/stable/c/91751e248256efc111e52e15115840c35d85abaf