Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-40196 State: PUBLISHED Published: 2025-11-12T21:56:32.578Z Last Updated: 2025-11-12T21:56:32.578Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fs: quota: create dedicated workqueue for quota_release_work There is a kernel panic due to WARN_ONCE when panic_on_warn is set. This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writebac
_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors. This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work. ------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_w
8 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ... References: - https://git.kernel.org/stable/c/f846eacde280ecc3daedfe001580e3033565179e - https://git.kernel.org/stable/c/f12039df1515d5daf7d92e586ece5cefeb39561b - https://git.kernel.org/stable/c/8a09a62f0c8c6
https://git.kernel.org/stable/c/f12039df1515d5daf7d92e586ece5cefeb39561b - https://git.kernel.org/stable/c/8a09a62f0c8c6123c2f1864ed6d5f9eb144afaf0 - https://git.kernel.org/stable/c/72b7ceca857f38a8ca7c5629feffc63769638974
CVE ID: CVE-2025-40197 State: PUBLISHED Published: 2025-11-12T21:56:32.852Z Last Updated: 2025-11-12T21:56:32.852Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: mc: Clear minor number before put device The device minor should not be cleared after the device is released. References: - https://git.kernel.org/stable/c/dd156f44ea82cc249f46c519eed3b2f8983c8002 - https://git.kernel.org/stable/c/64dbc6f50ce92b7da203b1bcdd96a370bbc9b74d - https://git.kernel.org/stable/c/5d327391f9fafeb0938be4fc538dd0bd54a0b2ef - https://git.kernel.org/stable/c/8f52c7f38f0f2ee2afc331e6b873acba5e9490a8 - https://git.kernel.org/stable/c/7bd4e5367d
- https://git.kernel.org/stable/c/8f52c7f38f0f2ee2afc331e6b873acba5e9490a8 - https://git.kernel.org/stable/c/7bd4e5367d0940ccec4d7546bb6bd019ab2c71aa - https://git.kernel.org/stable/c/7db47e737128b3585ae679b709b85f3f44cd8750 - https://git.kernel.org/stable/c/ac01416d477c2dc6016782635ae022f8cc634a29 - https://git.kernel.org/stable/c/8cfc8cec1b4da88a47c243a11f384baefd092a50
CVE ID: CVE-2025-40198 State: PUBLISHED Published: 2025-11-12T21:56:33.220Z Last Updated: 2025-11-12T21:56:33.220Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: avoid potential buffer over-read in parse_apply_sb_mount_options() Unlike other strings in the ext4 superblock, we rely on tune2fs to make sure s_mount_opts is NUL terminated. Harden parse_apply_sb_mount_options() by treating s_mount_opts as a potential __nonstring. References: - https://git.kernel.org/stable/c/7bf46ff83a0ef11836e38ebd72cdc5107209342d - https://git.kernel.org/stable/c/b2bac84fde28fb6a88817b8b761abda17a1d300b - https://git.kernel.org/stable/c/e651
09342d - https://git.kernel.org/stable/c/b2bac84fde28fb6a88817b8b761abda17a1d300b - https://git.kernel.org/stable/c/e651294218d2684302ee5ed95ccf381646f3e5b4 - https://git.kernel.org/stable/c/01829af7656b56d83682b3491265d583d502e502 - https://git.kernel.org/stable/c/2a0cf438320cdb783e0378570744c0ef0d83e934 - https://git.kernel.org/stable/c/a6e94557cd05adc82fae0400f6e17745563e5412 - https://git.kernel.org/stable/c/8ecb790ea8c3fc69e77bace57f14cf0d7c177bd8
CVE ID: CVE-2025-40199 State: PUBLISHED Published: 2025-11-12T21:56:33.510Z Last Updated: 2025-11-12T21:56:33.510Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: page_pool: Fix PP_MAGIC_MASK to avoid crashing on some 32-bit arches Helge reported that the introduction of PP_MAGIC_MASK let to crashes on boot on his 32-bit parisc machine. The cause of this is the mask is set too wide, so the page_pool_page_is_pp() incurs false positives which crashes the machine. Just disabling the check in page_pool_is_pp() will lead to the page_pool code itself malfunctioning; so instead of doing this, this patch changes the define for PP_DMA_IN
lead to the page_pool code itself malfunctioning; so instead of doing this, this patch changes the define for PP_DMA_INDEX_BITS to avoid mistaking arbitrary kernel pointers for page_pool-tagged pages. The fix relies on the kernel pointers that alias with the pp_magic field always being above PAGE_OFFSET. With this assumption, we can use the lowest bit of the value of PAGE_OFFSET as the upper bound of the PP_DMA_INDEX_MASK, which should avoid the false positives. Because we cannot rely on PAGE_OFFSET always being a compile-time constant, nor on it always being >0, we fall back to disabling the dma_index storage when there are not enough bits available. This leaves us in the situation we were
ack to disabling the dma_index storage when there are not enough bits available. This leaves us in the situation we were in before the patch in the Fixes tag, but only on a subset of architecture configurations. This seems to be the best we can do until the transition to page types in complete for page_pool pages. v2: - Make sure there's at least 8 bits available and that the PAGE_OFFSET bit calculation doesn't wrap References: - https://git.kernel.org/stable/c/15b8a5b4cdc16e9a8bb2a548e12a0fd92997605a - https://git.kernel.org/stable/c/f62934cea32c8f7b11b747975d69bf5afe4264cf - https://git.kernel.org/stable/c/95920c2ed02bde551ab654e9749c2ca7bc3100e0
CVE ID: CVE-2025-40200 State: PUBLISHED Published: 2025-11-12T21:56:33.783Z Last Updated: 2025-11-12T21:56:33.783Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Squashfs: reject negative file sizes in squashfs_read_inode() Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs. This warning is ultimately caused because the underlying Squashfs file system returns a file with a negative file size. This commit checks for a negative file size and returns EINVAL. [phillip@squashfs.org.uk: only need to check 64 bit quantity] References: - https://git.kernel.org/stable/c/54170057a5fadd24a37b70de41e61d39284d9bd7 - https://git.
k 64 bit quantity] References: - https://git.kernel.org/stable/c/54170057a5fadd24a37b70de41e61d39284d9bd7 - https://git.kernel.org/stable/c/2871c74caa3f4f05b429e6bfefebac62dbf1b408 - https://git.kernel.org/stable/c/fbfc745db628de31f5c089147deeb87e95b89e66 - https://git.kernel.org/stable/c/8118f66124895829443d09c207e654adcb2f9321 - https://git.kernel.org/stable/c/8c7aad76751816207fee556d44aa88a710824810 - https://git.kernel.org/stable/c/875fb3f87ae0225b881319ba016a1a8c4ffd5812 - https://git.kernel.org/stable/c/f271155ff31aca8ef82c61c8df23ca97e9a77dd4 - https://git.kernel.org/stable/c/9f1c14c1de1bdde395f6cc893efa4f80a2ae3b2b
CVE ID: CVE-2025-40201 State: PUBLISHED Published: 2025-11-12T21:56:34.063Z Last Updated: 2025-11-12T21:56:34.063Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kernel/sys.c: fix the racy usage of task_lock(tsk->group_leader) in sys_prlimit64() paths The usage of task_lock(tsk->group_leader) in sys_prlimit64()->do_prlimit() path is very broken. sys_prlimit64() does get_task_struct(tsk) but this only protects task_struct itself. If tsk != current and tsk is not a leader, this process can exit/exec and task_lock(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exe
k(tsk->group_leader) may use the already freed task_struct. Another problem is that sys_prlimit64() can race with mt-exec which changes ->group_leader. In this case do_prlimit() may take the wrong lock, or (worse) ->group_leader may change between task_lock() and task_unlock(). Change sys_prlimit64() to take tasklist_lock when necessary. This is not nice, but I don't see a better fix for -stable. References: - https://git.kernel.org/stable/c/1bc0d9315ef5296abb2c9fd840336255850ded18 - https://git.kernel.org/stable/c/132f827e7bac7373e1522e89709d70b43cae5342 - https://git.kernel.org/stable/c/19b45c84bd9fd42fa97ff80c6350d604cb871c75 - https://git.kernel.org/stable/c/6796412decd2d8de8ec708213bbc9
el.org/stable/c/19b45c84bd9fd42fa97ff80c6350d604cb871c75 - https://git.kernel.org/stable/c/6796412decd2d8de8ec708213bbc958fab72f143 - https://git.kernel.org/stable/c/a15f37a40145c986cdf289a4b88390f35efdecc4
CVE ID: CVE-2025-40202 State: PUBLISHED Published: 2025-11-12T21:56:34.527Z Last Updated: 2025-11-12T21:56:34.527Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipmi: Rework user message limit handling The limit on the number of user messages had a number of issues, improper counting in some cases and a use after free. Restructure how this is all done to handle more in the receive message allocation routine, so all refcouting and user message limit counts are done in that routine. It's a lot cleaner and safer. References: - https://git.kernel.org/stable/c/f63723ca7d7623f9dae1990973cd158671f03c56 - https://git.kernel.org/stable
. References: - https://git.kernel.org/stable/c/f63723ca7d7623f9dae1990973cd158671f03c56 - https://git.kernel.org/stable/c/348121b29594d42d1635648fd3ed31dfa25351d5 - https://git.kernel.org/stable/c/53d6e403affbf6df2c859a0ea00ccfc1e72090ca - https://git.kernel.org/stable/c/0ed73be9a2547ffb9b5c1d879ad9bfab73d920b5 - https://git.kernel.org/stable/c/b52da4054ee0bf9ecb44996f2c83236ff50b3812
CVE ID: CVE-2025-40203 State: PUBLISHED Published: 2025-11-12T21:56:34.801Z Last Updated: 2025-11-12T21:56:34.801Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: listmount: don't call path_put() under namespace semaphore Massage listmount() and make sure we don't call path_put() under the namespace semaphore. If we put the last reference we're fscked. References: - https://git.kernel.org/stable/c/659874b7ee4976ad9ce476e07fd36bc67b3537f1 - https://git.kernel.org/stable/c/9c80da26fda2fdcaac7f92b5908875b3108830ff - https://git.kernel.org/stable/c/c1f86d0ac322c7e77f6f8dbd216c65d39358ffc0
CVE ID: CVE-2025-40204 State: PUBLISHED Published: 2025-11-12T21:56:35.110Z Last Updated: 2025-11-12T21:56:35.110Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sctp: Fix MAC comparison to be constant-time To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this. References: - https://git.kernel.org/stable/c/b93fa8dc521d00d2d44bf034fb90e0d79b036617 - https://git.kernel.org/stable/c/0e8b8c326c2a6de4d837b1bb034ea704f4690d77 - https://git.kernel.org/stable/c/1cd60e0d0fb8f0e62ec4499138afce6342dc9d4c - https://git.kernel.org/stable/c/9c05d44ec24126fc283835b68f82dba3ae985209
e/c/1cd60e0d0fb8f0e62ec4499138afce6342dc9d4c - https://git.kernel.org/stable/c/9c05d44ec24126fc283835b68f82dba3ae985209 - https://git.kernel.org/stable/c/ed3044b9c810c5c24eb2830053fbfe5fd134c5d4 - https://git.kernel.org/stable/c/8019b3699289fce3f10b63f98601db97b8d105b0 - https://git.kernel.org/stable/c/0b32ff285ff6f6f1ac1d9495787ccce8837d6405 - https://git.kernel.org/stable/c/dd91c79e4f58fbe2898dac84858033700e0e99fb
CVE ID: CVE-2025-40205 State: PUBLISHED Published: 2025-11-12T21:56:35.403Z Last Updated: 2025-11-12T21:56:35.403Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid potential out-of-bounds in btrfs_encode_fh() The function btrfs_encode_fh() does not properly account for the three cases it handles. Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes). However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10
xists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes). If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned. This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id. A previous attempt to fix this issue was made but was lost. https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/ Although this issue does not seem to be easily triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the
triggerable, it is a potential memory corruption bug that should be fixed. This patch resolves the issue by ensuring the function returns the appropriate size for all three cases and validates that *max_len is large enough before writing any data. References: - https://git.kernel.org/stable/c/60de2f55d2aca53e81b4ef2a67d7cc9e1eb677db - https://git.kernel.org/stable/c/742b44342204e5dfe3926433823623c1a0c581df - https://git.kernel.org/stable/c/d3a9a8e1275eb9b87f006b5562a287aea3f6885f - https://git.kernel.org/stable/c/d91f6626133698362bba08fbc04bd72c466806d3 - https://git.kernel.org/stable/c/0276c8582488022f057b4cec21975a5edf079f47 - https://git.kernel.org/stable/c/361d67276eb8ec6be8f27f4ad6c6090
.org/stable/c/0276c8582488022f057b4cec21975a5edf079f47 - https://git.kernel.org/stable/c/361d67276eb8ec6be8f27f4ad6c6090459438fee - https://git.kernel.org/stable/c/43143776b0a7604d873d1a6f3e552a00aa930224 - https://git.kernel.org/stable/c/dff4f9ff5d7f289e4545cc936362e01ed3252742
CVE ID: CVE-2025-40206 State: PUBLISHED Published: 2025-11-12T21:56:35.675Z Last Updated: 2025-11-12T21:56:35.675Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_objref: validate objref and objrefmap expressions Referencing a synproxy stateful object from OUTPUT hook causes kernel crash due to infinite recursive calls: BUG: TASK stack guard page was hit at 000000008bda5b8c (stack is 000000003ab1c4a5..00000000494d8b12) [...] Call Trace: __find_rr_leaf+0x99/0x230 fib6_table_lookup+0x13b/0x2d0 ip6_pol_route+0xa4/0x400 fib6_rule_lookup+0x156/0x240 ip6_route_output_flags+0xc6/0x150 __nf_ip6_route+0x23/0x50 synproxy_se
pol_route+0xa4/0x400 fib6_rule_lookup+0x156/0x240 ip6_route_output_flags+0xc6/0x150 __nf_ip6_route+0x23/0x50 synproxy_send_tcp_ipv6+0x106/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 nft_synproxy_do_eval+0x263/0x310 nft_do_chain+0x5a8/0x5f0 [nf_tables nft_do_chain_inet+0x98/0x110 nf_hook_slow+0x43/0xc0 __ip6_local_out+0xf0/0x170 ip6_local_out+0x17/0x70 synproxy_send_tcp_ipv6+0x1a2/0x200 synproxy_send_client_synack_ipv6+0x1aa/0x1f0 [...] Implement objref and objrefmap expression validate functions. Currently, only NFT_OBJECT_SYNPROXY object type requires validation. This will also handle a jump to a chain using a synproxy object from the OUTPUT hook. Now when trying to reference a synpr
is will also handle a jump to a chain using a synproxy object from the OUTPUT hook. Now when trying to reference a synproxy object in the OUTPUT hook, nft will produce the following error: synproxy_crash.nft: Error: Could not process rule: Operation not supported synproxy name mysynproxy ^^^^^^^^^^^^^^^^^^^^^^^^ References: - https://git.kernel.org/stable/c/0028e0134c64d9ed21728341a74fcfc59cd0f944 - https://git.kernel.org/stable/c/7ea55a44493a5a36c3b3293b88bbe4841f9dbaf0 - https://git.kernel.org/stable/c/4c1cf72ec10be5a9ad264650cadffa1fbce6fabd - https://git.kernel.org/stable/c/f359b809d54c6e3dd1d039b97e0b68390b0e53e4
CVE ID: CVE-2025-40207 State: PUBLISHED Published: 2025-11-12T21:56:35.988Z Last Updated: 2025-11-12T21:56:35.988Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try() v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try(). References: - https://git.kernel.org/stable/c/5b0057459cdc243ffb35617603142dcace09c711
to v4l2_subdev_call_state_try(). References: - https://git.kernel.org/stable/c/5b0057459cdc243ffb35617603142dcace09c711 - https://git.kernel.org/stable/c/ed30811fbed40751deb952bde534aa2632dc0bf7 - https://git.kernel.org/stable/c/94e6336dc1f06a06f5b4cd04d4a012bba34f2857 - https://git.kernel.org/stable/c/a553530b3314a0bdc98cf114cdbe204551a70a00 - https://git.kernel.org/stable/c/f37df9a0eb5e43fcfe02cbaef076123dc0d79c7e
CVE ID: CVE-2025-40208 State: PUBLISHED Published: 2025-11-12T21:56:36.261Z Last Updated: 2025-11-12T21:56:36.261Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: iris: fix module removal if firmware download failed Fix remove if firmware failed to load: qcom-iris aa00000.video-codec: Direct firmware load for qcom/vpu/vpu33_p4.mbn failed with error -2 qcom-iris aa00000.video-codec: firmware download failed qcom-iris aa00000.video-codec: core init failed then: $ echo aa00000.video-codec > /sys/bus/platform/drivers/qcom-iris/unbind Triggers: genpd genpd:1:aa00000.video-codec: Runtime PM usage count underflow! ------------[
m/drivers/qcom-iris/unbind Triggers: genpd genpd:1:aa00000.video-codec: Runtime PM usage count underflow! ------------[ cut here ]------------ video_cc_mvs0_clk already disabled WARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#1: sh/542 <snip> pc : clk_core_disable+0xa4/0xac lr : clk_core_disable+0xa4/0xac <snip> Call trace: clk_core_disable+0xa4/0xac (P) clk_disable+0x30/0x4c iris_disable_unprepare_clock+0x20/0x48 [qcom_iris] iris_vpu_power_off_hw+0x48/0x58 [qcom_iris] iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris] iris_vpu_power_off+0x34/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+
_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 <snip> ---[ end trace 0000000000000000 ]--- ------------[ cut here ]------------ video_cc_mvs0_clk already unprepared WARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#2: sh/542 <snip> pc : clk_core_unprepare+0xf0/0x110 lr : clk_core_unprepare+0xf0/0x110 <snip> Call trace: clk_core_unprepare+0xf0/0x110 (P) clk_unprepare+0x2c/0x44 iris_disable_unprepare_clock+0x28/0x48 [qcom_iris] iris_vpu_power_off_hw+0x48/0x58 [qcom_iris] iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris] iris_vpu_power_off+0x34/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [q
s_vpu33_power_off_hardware+0x44/0x230 [qcom_iris] iris_vpu_power_off+0x34/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 <snip> ---[ end trace 0000000000000000 ]--- genpd genpd:0:aa00000.video-codec: Runtime PM usage count underflow! ------------[ cut here ]------------ gcc_video_axi0_clk already disabled WARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#4: sh/542 <snip> pc : clk_core_disable+0xa4/0xac lr : clk_core_disable+0xa4/0xac <snip> Call trace: clk_core_disable+0xa4/0xac (P) clk_disable+0x30/0x4c iris_disable_unprepare_clock+0x20/0x48 [qcom_iris] iris_vpu33_power_off_controll
ble+0xa4/0xac (P) clk_disable+0x30/0x4c iris_disable_unprepare_clock+0x20/0x48 [qcom_iris] iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris] iris_vpu_power_off+0x48/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 <snip> ------------[ cut here ]------------ gcc_video_axi0_clk already unprepared WARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#4: sh/542 <snip> pc : clk_core_unprepare+0xf0/0x110 lr : clk_core_unprepare+0xf0/0x110 <snip> Call trace: clk_core_unprepare+0xf0/0x110 (P) clk_unprepare+0x2c/0x44 iris_disable_unprepare_clock+0x28/0x48 [qcom_iris] iris_vpu33_power_off_c
prepare+0xf0/0x110 (P) clk_unprepare+0x2c/0x44 iris_disable_unprepare_clock+0x28/0x48 [qcom_iris] iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris] iris_vpu_power_off+0x48/0x84 [qcom_iris] iris_core_deinit+0x44/0xc8 [qcom_iris] iris_remove+0x20/0x48 [qcom_iris] platform_remove+0x20/0x30 device_remove+0x4c/0x80 <snip> ---[ end trace 0000000000000000 ]--- Skip deinit if initialization never succeeded. References: - https://git.kernel.org/stable/c/7a0a77b936ff28f59c271172e81cefebf7b2b7a6 - https://git.kernel.org/stable/c/fde38008fc4f43db8c17869491870df24b501543
CVE ID: CVE-2025-40209 State: PUBLISHED Published: 2025-11-21T10:19:44.757Z Last Updated: 2025-11-21T10:19:44.757Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation When btrfs_add_qgroup_relation() is called with invalid qgroup levels (src >= dst), the function returns -EINVAL directly without freeing the preallocated qgroup_list structure passed by the caller. This causes a memory leak because the caller unconditionally sets the pointer to NULL after the call, preventing any cleanup. The issue occurs because the level validation check happens before the mutex is a
fter the call, preventing any cleanup. The issue occurs because the level validation check happens before the mutex is acquired and before any error handling path that would free the prealloc pointer. On this early return, the cleanup code at the 'out' label (which includes kfree(prealloc)) is never reached. In btrfs_ioctl_qgroup_assign(), the code pattern is: prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL); ret = btrfs_add_qgroup_relation(trans, sa->src, sa->dst, prealloc); prealloc = NULL; // Always set to NULL regardless of return value ... kfree(prealloc); // This becomes kfree(NULL), does nothing When the level check fails, 'prealloc' is never freed by either the callee or the caller,
omes kfree(NULL), does nothing When the level check fails, 'prealloc' is never freed by either the callee or the caller, resulting in a 64-byte memory leak per failed operation. This can be triggered repeatedly by an unprivileged user with access to a writable btrfs mount, potentially exhausting kernel memory. Fix this by freeing prealloc before the early return, ensuring prealloc is always freed on all error paths. References: - https://git.kernel.org/stable/c/3412d0e973e8f8381747d69033eda809a57a2581 - https://git.kernel.org/stable/c/a4d9ebe23bcb79d9d057e3c995db73b7b3aae414 - https://git.kernel.org/stable/c/f260c6aff0b8af236084012d14f9f1bf792ea883