Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration") lead to the introduction of this bug. So fix it appropriately. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/bc40ded92af55760d12bec8222d4108de725dbe4 - https://git.kernel.org/stable/c/4b12ff5edd141926d49c9ace4791adf3a4902fe7 - https://git.kernel.org/stable/c/e5b5948c769aa1ebf962dddfb972f87d8f166f95 - https://git.kernel.org/stable/c/520f79c110ff712b391b3d87fcacf03c74bc56ee - https://git.kernel.org/stable/c/bfa344afbe472a9be08f78551fa2190c1a07d7d3 - https://git.kernel.org/stable/c/95915ba4b987cf2b222b0f251280228a1ff977ac
CVE ID: CVE-2024-35786 State: PUBLISHED Published: 2024-05-17T12:24:31.510Z Last Updated: 2025-05-04T09:05:22.094Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf If VM_BIND is enabled on the client the legacy submission ioctl can't be used, however if a client tries to do so regardless it will return an error. In this case the clients mutex remained unlocked leading to a deadlock inside nouveau_drm_postclose or any other nouveau ioctl call. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c28
ional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c288a61a48ddb77ec097e11ab81b81027cd4e197 - https://git.kernel.org/stable/c/b466416bdd6ecbde15ce987226ea633a0268fbb1 - https://git.kernel.org/stable/c/daf8739c3322a762ce84f240f50e0c39181a41ab
CVE ID: CVE-2024-35787 State: PUBLISHED Published: 2024-05-17T12:24:35.137Z Last Updated: 2025-05-04T09:05:23.509Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix incorrect usage for sb_index Commit d7038f951828 ("md-bitmap: don't use ->index for pages backing the bitmap file") removed page->index from bitmap code, but left wrong code logic for clustered-md. current code never set slot offset for cluster nodes, will sometimes cause crash in clustered env. Call trace (partly): md_bitmap_file_set_bit+0x110/0x1d8 [md_mod] md_bitmap_startwrite+0x13c/0x240 [md_mod] raid1_make_request+0x6b0/0x1c08 [raid1] md_handle_r
t_bit+0x110/0x1d8 [md_mod] md_bitmap_startwrite+0x13c/0x240 [md_mod] raid1_make_request+0x6b0/0x1c08 [raid1] md_handle_request+0x1dc/0x368 [md_mod] md_submit_bio+0x80/0xf8 [md_mod] __submit_bio+0x178/0x300 submit_bio_noacct_nocheck+0x11c/0x338 submit_bio_noacct+0x134/0x614 submit_bio+0x28/0xdc submit_bh_wbc+0x130/0x1cc submit_bh+0x1c/0x28 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/736ad6c577a367834118f57417038d45bb5e0a31 - https://git.kernel.org/stable/c/55e55eb65fd5e09faf5a0e49ffcdd37905aaf4da - https://git.kernel.org/stable/c/5a95815b17428ce2f56ec18da5e0d1b2a1a15240 - https://git.kernel.org/stable/c/ecbd8ebb51bf
https://git.kernel.org/stable/c/5a95815b17428ce2f56ec18da5e0d1b2a1a15240 - https://git.kernel.org/stable/c/ecbd8ebb51bf7e4939d83b9e6022a55cac44ef06
CVE ID: CVE-2024-35788 State: REJECTED Published: 2024-05-17T12:24:38.671Z Last Updated: 2025-06-19T12:42:56.991Z Description: No description available.
CVE ID: CVE-2024-35789 State: PUBLISHED Published: 2024-05-17T12:24:42.323Z Last Updated: 2025-05-21T09:12:34.451Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes When moving a station out of a VLAN and deleting the VLAN afterwards, the fast_rx entry still holds a pointer to the VLAN's netdev, which can cause use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx after the VLAN change. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ea9a0cfc07a7d3601cc680718d9cff0d6927
ulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ea9a0cfc07a7d3601cc680718d9cff0d6927a921 - https://git.kernel.org/stable/c/be1dd9254fc115321d6fbee042026d42afc8d931 - https://git.kernel.org/stable/c/e8b067c4058c0121ac8ca71559df8e2e08ff1a7e - https://git.kernel.org/stable/c/c8bddbd91bc8e42c961a5e2cec20ab879f21100f - https://git.kernel.org/stable/c/7eeabcea79b67cc29563e6a9a5c81f9e2c664d5b - https://git.kernel.org/stable/c/6b948b54c8bd620725e0c906e44b10c0b13087a7 - https://git.kernel.org/stable/c/2884a50f52313a7a911de3afcad065ddbb3d78fc - https://git.kernel.org/stable/c/e8678551c0243f799b4859448781cbec1bd6f1cb - https://git.kernel.org/stable/c/4f2bdb3c5e318929
ps://git.kernel.org/stable/c/e8678551c0243f799b4859448781cbec1bd6f1cb - https://git.kernel.org/stable/c/4f2bdb3c5e3189297e156b3ff84b140423d64685
CVE ID: CVE-2024-35790 State: PUBLISHED Published: 2024-05-17T12:24:45.918Z Last Updated: 2025-11-03T19:29:55.320Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group The DisplayPort driver's sysfs nodes may be present to the userspace before typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns NULL in those cases. Remove manual sysfs node creation in favor of adding attrib
ment_show, as dev_get_drvdata() returns NULL in those cases. Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6b989ea1c479533ab8dbfbeb1704c94b1d3320da - https://git.kernel.org/stable/c/9794ffd9d0c39ee070fbd733f862bbe89b28ba33 - https://git.kernel.org/stable/c/f1c5ddaef506e3517dce338c08a60663b1521920 - https://git.kernel.org/stable/c/4a22aeac24d0d5f26ba741408e8b5a4be6dc5dc0 - https://git.ker
3517dce338c08a60663b1521920 - https://git.kernel.org/stable/c/4a22aeac24d0d5f26ba741408e8b5a4be6dc5dc0 - https://git.kernel.org/stable/c/0ad011776c057ce881b7fd6d8c79ecd459c087e9 - https://git.kernel.org/stable/c/165376f6b23e9a779850e750fb2eb06622e5a531
CVE ID: CVE-2024-35791 State: PUBLISHED Published: 2024-05-17T12:24:49.520Z Last Updated: 2025-05-04T12:55:45.574Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region() Do the cache flush of converted pages in svm_register_enc_region() before dropping kvm->lock to fix use-after-free issues where region and/or its array of pages could be freed by a different task, e.g. if userspace has __unregister_enc_region_locked() already queued up for the region. Note, the "obvious" alternative of using local variables doesn't fully resolve the bug, as region->pages is a
he region. Note, the "obvious" alternative of using local variables doesn't fully resolve the bug, as region->pages is also dynamically allocated. I.e. the region structure itself would be fine, but region->pages could be freed. Flushing multiple pages under kvm->lock is unfortunate, but the entire flow is a rare slow path, and the manual flush is only needed on CPUs that lack coherency for encrypted memory. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2d13b79640b147bd77c34a5998533b2021a4122d - https://git.kernel.org/stable/c/e126b508ed2e616d679d85fca2fbe77bb48bbdd7 - https://git.kernel.org/stable/c/4868c0ecdb6cfde7
ps://git.kernel.org/stable/c/e126b508ed2e616d679d85fca2fbe77bb48bbdd7 - https://git.kernel.org/stable/c/4868c0ecdb6cfde7c70cf478c46e06bb9c7e5865 - https://git.kernel.org/stable/c/12f8e32a5a389a5d58afc67728c76e61beee1ad4 - https://git.kernel.org/stable/c/f6d53d8a2617dd58c89171a6b9610c470ebda38a - https://git.kernel.org/stable/c/5ef1d8c1ddbf696e47b226e11888eaf8d9e8e807
CVE ID: CVE-2024-35792 State: PUBLISHED Published: 2024-05-17T12:24:53.112Z Last Updated: 2025-05-04T09:05:30.807Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: rk3288 - Fix use after free in unprepare The unprepare call must be carried out before the finalize call as the latter can free the request. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/48dd260fdb728eda4a246f635d1325e82f0d3555 - https://git.kernel.org/stable/c/eb2a41a8ae8c8c4f68aef3bd94665c0cf23e04be - https://git.kernel.org/stable/c/c0afb6b88fbbc177fa322a835f874be217bffe45
CVE ID: CVE-2024-35793 State: PUBLISHED Published: 2024-05-17T12:24:56.630Z Last Updated: 2025-05-04T09:05:32.438Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: debugfs: fix wait/cancellation handling during remove Ben Greear further reports deadlocks during concurrent debugfs remove while files are being accessed, even though the code in question now uses debugfs cancellations. Turns out that despite all the review on the locking, we missed completely that the logic is wrong: if the refcount hits zero we can finish (and need not wait for the completion), but if it doesn't we have to trigger all the cancellations. As written,
finish (and need not wait for the completion), but if it doesn't we have to trigger all the cancellations. As written, we can _never_ get into the loop triggering the cancellations. Fix this, and explain it better while at it. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e88b5ae01901c4a655a53158397746334778a57b - https://git.kernel.org/stable/c/3d08cca5fd0aabb62b7015067ab40913b33da906 - https://git.kernel.org/stable/c/952c3fce297f12c7ff59380adb66b564e2bc9b64
CVE ID: CVE-2024-35794 State: PUBLISHED Published: 2024-05-17T12:25:00.111Z Last Updated: 2025-05-04T09:05:33.895Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm-raid: really frozen sync_thread during suspend 1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes(). 2) The flag MD_RECOVERY_FROZEN doesn
ly used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes(). 2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen, it only prevent new sync_thread to start, and it can't stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used. 3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn't look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend(). 4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared w
tsuspend(). 4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend. Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), the test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(), and with previous fixes, the test won't hang there anymore, however, the test will still fail and complain that ext4 is corrupted. And with this patch, the test won't hang due to stop_sync_thread() or fail due to ext4 is corrupted anymore. However, there is still a deadlock related t
't hang due to stop_sync_thread() or fail due to ext4 is corrupted anymore. However, there is still a deadlock related to dm-raid456 that will be fixed in following patches. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/af916cb66a80597f3523bc85812e790bcdcfd62b - https://git.kernel.org/stable/c/eaa8fc9b092837cf2c754bde1a15d784ce9a85ab - https://git.kernel.org/stable/c/16c4770c75b1223998adbeb7286f9a15c65fba73
CVE ID: CVE-2024-35795 State: PUBLISHED Published: 2024-05-17T13:23:06.900Z Last Updated: 2025-05-04T09:05:35.403Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix deadlock while reading mqd from debugfs An errant disk backup on my desktop got into debugfs and triggered the following deadlock scenario in the amdgpu debugfs files. The machine also hard-resets immediately after those lines are printed (although I wasn't able to reproduce that part when reading by hand): [ 1318.016074][ T1082] ====================================================== [ 1318.016607][ T1082] WARNING: possible circular locking dependency d
================================================= [ 1318.016607][ T1082] WARNING: possible circular locking dependency detected [ 1318.017107][ T1082] 6.8.0-rc7-00015-ge0c8221b72c0 #17 Not tainted [ 1318.017598][ T1082] ------------------------------------------------------ [ 1318.018096][ T1082] tar/1082 is trying to acquire lock: [ 1318.018585][ T1082] ffff98c44175d6a0 (&mm->mmap_lock){++++}-{3:3}, at: __might_fault+0x40/0x80 [ 1318.019084][ T1082] [ 1318.019084][ T1082] but task is already holding lock: [ 1318.020052][ T1082] ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.020607][ T1082] [ 1318.020607][ T1082] which lock a
{+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.020607][ T1082] [ 1318.020607][ T1082] which lock already depends on the new lock. [ 1318.020607][ T1082] [ 1318.022081][ T1082] [ 1318.022081][ T1082] the existing dependency chain (in reverse order) is: [ 1318.023083][ T1082] [ 1318.023083][ T1082] -> #2 (reservation_ww_class_mutex){+.+.}-{3:3}: [ 1318.024114][ T1082] __ww_mutex_lock.constprop.0+0xe0/0x12f0 [ 1318.024639][ T1082] ww_mutex_lock+0x32/0x90 [ 1318.025161][ T1082] dma_resv_lockdep+0x18a/0x330 [ 1318.025683][ T1082] do_one_initcall+0x6a/0x350 [ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.026728][ T1082] kernel_init+0x15/0x1a0 [ 1318.027242][ T1
[ 1318.026210][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.026728][ T1082] kernel_init+0x15/0x1a0 [ 1318.027242][ T1082] ret_from_fork+0x2c/0x40 [ 1318.027759][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.028281][ T1082] [ 1318.028281][ T1082] -> #1 (reservation_ww_class_acquire){+.+.}-{0:0}: [ 1318.029297][ T1082] dma_resv_lockdep+0x16c/0x330 [ 1318.029790][ T1082] do_one_initcall+0x6a/0x350 [ 1318.030263][ T1082] kernel_init_freeable+0x1a3/0x310 [ 1318.030722][ T1082] kernel_init+0x15/0x1a0 [ 1318.031168][ T1082] ret_from_fork+0x2c/0x40 [ 1318.031598][ T1082] ret_from_fork_asm+0x11/0x20 [ 1318.032011][ T1082] [ 1318.032011][ T1082] -> #0 (&mm->mmap_lock){++++}-{3:3}: [ 1318.032778][ T108
ork_asm+0x11/0x20 [ 1318.032011][ T1082] [ 1318.032011][ T1082] -> #0 (&mm->mmap_lock){++++}-{3:3}: [ 1318.032778][ T1082] __lock_acquire+0x14bf/0x2680 [ 1318.033141][ T1082] lock_acquire+0xcd/0x2c0 [ 1318.033487][ T1082] __might_fault+0x58/0x80 [ 1318.033814][ T1082] amdgpu_debugfs_mqd_read+0x103/0x250 [amdgpu] [ 1318.034181][ T1082] full_proxy_read+0x55/0x80 [ 1318.034487][ T1082] vfs_read+0xa7/0x360 [ 1318.034788][ T1082] ksys_read+0x70/0xf0 [ 1318.035085][ T1082] do_syscall_64+0x94/0x180 [ 1318.035375][ T1082] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 1318.035664][ T1082] [ 1318.035664][ T1082] other info that might help us debug this: [ 1318.035664][ T1082] [ 1318.036487][ T1082] Chain
82] [ 1318.035664][ T1082] other info that might help us debug this: [ 1318.035664][ T1082] [ 1318.036487][ T1082] Chain exists of: [ 1318.036487][ T1082] &mm->mmap_lock --> reservation_ww_class_acquire --> reservation_ww_class_mutex [ 1318.036487][ T1082] [ 1318.037310][ T1082] Possible unsafe locking scenario: [ 1318.037310][ T1082] [ 1318.037838][ T1082] CPU0 CPU1 [ 1318.038101][ T1082] ---- ---- [ 1318.038350][ T1082] lock(reservation_ww_class_mutex); [ 1318.038590][ T1082] lock(reservation_ww_class_acquire); [ 1318.038839][ T1082] lock(reservation_ww_class_mutex); [ 1318.039083][ T1082] rlock(&mm->mmap_lock); [ 1318.039328][ T1082] [ 1318.039328][ T1082] *** DEADLOCK *** [ 1318.039328][
18.039083][ T1082] rlock(&mm->mmap_lock); [ 1318.039328][ T1082] [ 1318.039328][ T1082] *** DEADLOCK *** [ 1318.039328][ T1082] [ 1318.040029][ T1082] 1 lock held by tar/1082: [ 1318.040259][ T1082] #0: ffff98c4c13f55f8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: amdgpu_debugfs_mqd_read+0x6a/0x250 [amdgpu] [ 1318.040560][ T1082] [ 1318.040560][ T1082] stack backtrace: [ ---truncated--- Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/197f6d6987c55860f6eea1c93e4f800c59078874 - https://git.kernel.org/stable/c/8b03556da6e576c62664b6cd01809e4a09d53b5b - https://git.kernel.org/stable/c/4687e3c6ee877ee25e57b984eca00be53b9a8
table/c/8b03556da6e576c62664b6cd01809e4a09d53b5b - https://git.kernel.org/stable/c/4687e3c6ee877ee25e57b984eca00be53b9a8db5 - https://git.kernel.org/stable/c/8678b1060ae2b75feb60b87e5b75e17374e3c1c5
CVE ID: CVE-2024-35796 State: PUBLISHED Published: 2024-05-17T13:23:07.558Z Last Updated: 2025-05-04T12:55:46.667Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: ll_temac: platform_get_resource replaced by wrong function The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name. This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp. if (type == resource_type(r) && !strcmp(r->name, name)) It should have been replaced with devm_platform_ioremap_resource. Additional Analyst Notes: - CISA ADP Vulnrichmen
ame)) It should have been replaced with devm_platform_ioremap_resource. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6d9395ba7f85bdb7af0b93272e537484ecbeff48 - https://git.kernel.org/stable/c/553d294db94b5f139378022df480a9fb6c3ae39e - https://git.kernel.org/stable/c/46efbdbc95a30951c2579caf97b6df2ee2b3bef3 - https://git.kernel.org/stable/c/476eed5f1c22034774902a980aa48dc4662cb39a - https://git.kernel.org/stable/c/7e9edb569fd9f688d887e36db8170f6e22bafbc8 - https://git.kernel.org/stable/c/92c0c29f667870f17c0b764544bdf22ce0e886a1 - https://git.kernel.org/stable/c/3a38a829c8bc27d78552c28e582eb1d885d07d11
CVE ID: CVE-2024-35797 State: PUBLISHED Published: 2024-05-17T13:23:08.204Z Last Updated: 2025-05-04T09:05:37.831Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix two shmem bugs When cachestat on shmem races with swapping and invalidation, there are two possible bugs: 1) A swapin error can have resulted in a poisoned swap entry in the shmem inode's xarray. Calling get_shadow_from_swap_cache() on it will result in an out-of-bounds access to swapper_spaces[]. Validate the entry with non_swap_entry() before going further. 2) When we find a valid swap entry in the shmem's inode, the shadow entry in the swapcache m
try() before going further. 2) When we find a valid swap entry in the shmem's inode, the shadow entry in the swapcache might not exist yet: swap IO is still in progress and we're before __remove_mapping; swapin, invalidation, or swapoff have removed the shadow from swapcache after we saw the shmem swap entry. This will send a NULL to workingset_test_recent(). The latter purely operates on pointer bits, so it won't crash - node 0, memcg ID 0, eviction timestamp 0, etc. are all valid inputs - but it's a bogus test. In theory that could result in a false "recently evicted" count. Such a false positive wouldn't be the end of the world. But for code clarity and (future) robustness, be explicit ab
nt. Such a false positive wouldn't be the end of the world. But for code clarity and (future) robustness, be explicit about this case. Bail on get_shadow_from_swap_cache() returning NULL. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b79f9e1ff27c994a4c452235ba09e672ec698e23 - https://git.kernel.org/stable/c/d962f6c583458037dc7e529659b2b02b9dd3d94b - https://git.kernel.org/stable/c/24a0e73d544439bb9329fbbafac44299e548a677 - https://git.kernel.org/stable/c/d5d39c707a4cf0bcc84680178677b97aa2cb2627
CVE ID: CVE-2024-35798 State: PUBLISHED Published: 2024-05-17T13:23:08.868Z Last Updated: 2025-05-04T09:05:39.197Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race in read_extent_buffer_pages() There are reports from tree-checker that detects corrupted nodes, without any obvious pattern so possibly an overwrite in memory. After some debugging it turns out there's a race when reading an extent buffer the uptodate status can be missed. To prevent concurrent reads for the same extent buffer, read_extent_buffer_pages() performs these checks: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2)
tent_buffer_pages() performs these checks: /* (1) */ if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags)) return 0; /* (2) */ if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags)) goto done; At this point, it seems safe to start the actual read operation. Once that completes, end_bbio_meta_read() does /* (3) */ set_extent_buffer_uptodate(eb); /* (4) */ clear_bit(EXTENT_BUFFER_READING, &eb->bflags); Normally, this is enough to ensure only one read happens, and all other callers wait for it to finish before returning. Unfortunately, there is a racey interleaving: Thread A | Thread B | Thread C ---------+----------+--------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) When this ha
Thread B | Thread C ---------+----------+--------- (1) | | | (1) | (2) | | (3) | | (4) | | | (2) | | | (1) When this happens, thread B kicks of an unnecessary read. Worse, thread C will see UPTODATE set and return immediately, while the read from thread B is still in progress. This race could result in tree-checker errors like this as the extent buffer is concurrently modified: BTRFS critical (device dm-0): corrupted node, root=256 block=8550954455682405139 owner mismatch, have 11858205567642294356 expect [256, 18446744073709551360] Fix it by testing UPTODATE again after setting the READING bit, and if it's been set, skip the unnecessary read. [ minor update of changelog ] Additional Analys
etting the READING bit, and if it's been set, skip the unnecessary read. [ minor update of changelog ] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/0427c8ef8bbb7f304de42ef51d69c960e165e052 - https://git.kernel.org/stable/c/3a25878a3378adce5d846300c9570f15aa7f7a80 - https://git.kernel.org/stable/c/2885d54af2c2e1d910e20d5c8045bae40e02fbc1 - https://git.kernel.org/stable/c/ef1e68236b9153c27cb7cf29ead0c532870d4215