Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-47666 State: PUBLISHED Published: 2024-10-09T14:13:58.849Z Last Updated: 2025-05-04T09:36:46.337Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Set phy->enable_completion only when we wait for it pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completio
completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7b1d779647afaea9185fa2f150b1721e7c1aae89 - https://git.kernel.org/stable/c/f14d3e1aa613311c744af32d75125e95fc8ffb84 - https://git.kernel.org/stable/c/e4f949ef1516c0d74745ee54a0f4882c1f6c7aea
CVE ID: CVE-2024-47667 State: PUBLISHED Published: 2024-10-09T14:13:59.522Z Last Updated: 2025-11-03T22:20:31.801Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0) Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload s
the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here. The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed. [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/cfb006e185f64edbbdf7869eac352442bc76b8f6 - https://git.kernel.org/stable/c/ebbdbbc580c1695dec283d0ba6448729dc993246 - https://git.kernel.org/stable/c/135843c351c08df72bdd4b4ebea53c8052a76881 - https://git.kernel.org/stable/c/af21
993246 - https://git.kernel.org/stable/c/135843c351c08df72bdd4b4ebea53c8052a76881 - https://git.kernel.org/stable/c/af218c803fe298ddf00abef331aa526b20d7ea61 - https://git.kernel.org/stable/c/576d0fb6f8d4bd4695e70eee173a1b9c7bae9572 - https://git.kernel.org/stable/c/dd47051c76c8acd8cb983f01b4d1265da29cb66a - https://git.kernel.org/stable/c/86f271f22bbb6391410a07e08d6ca3757fda01fa
CVE ID: CVE-2024-47668 State: PUBLISHED Published: 2024-10-09T14:14:00.189Z Last Updated: 2025-11-03T22:20:33.256Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later. If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path. Additional Analyst Notes: - CISA ADP V
oot instead of being zeroed - fix this by zeroing it in the cmpxchg failure path. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/0f27f4f445390cb7f73d4209cb2bf32834dc53da - https://git.kernel.org/stable/c/99418ec776a39609f50934720419e0b464ca2283 - https://git.kernel.org/stable/c/ad5ee9feebc2eb8cfc76ed74a2d6e55343b0e169 - https://git.kernel.org/stable/c/ebeff038744c498a036e7a92eb8e433ae0a386d7 - https://git.kernel.org/stable/c/d942e855324a60107025c116245095632476613e - https://git.kernel.org/stable/c/0f078f8ca93b28a34e20bd050f12cd4efeee7c0f - https://git.kernel.org/stable/c/b2f11c6f3e1fc60742673b8675c95b78447f3dae
CVE ID: CVE-2024-47669 State: PUBLISHED Published: 2024-10-09T14:14:01.139Z Last Updated: 2025-11-03T22:20:34.709Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix state management in error path of log writing function After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling. First, if nilfs_segctor_begin_construction() fails while creating the seco
flaws were introduced in its error handling. First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang. Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does
sult, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping. Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Pro
des() to ensure that the NILFS_I_COLLECTED flag is cleared. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/40a2757de2c376ef8a08d9ee9c81e77f3c750adf - https://git.kernel.org/stable/c/036441e8438b29111fa75008f0ce305fb4e83c0a - https://git.kernel.org/stable/c/efdde00d4a1ef10bb71e09ebc67823a3d3ad725b - https://git.kernel.org/stable/c/3e349d7191f0688fc9808ef24fd4e4b4ef5ca876 - https://git.kernel.org/stable/c/30562eff4a6dd35c4b5be9699ef61ad9f5f20a06 - https://git.kernel.org/stable/c/0a1a961bde4351dc047ffdeb2f1311ca16a700cc - https://git.kernel.org/stable/c/74866c16ea2183f52925fa5d76061a1fe7f7737b - https://git.kernel.org/st
b2f1311ca16a700cc - https://git.kernel.org/stable/c/74866c16ea2183f52925fa5d76061a1fe7f7737b - https://git.kernel.org/stable/c/6576dd6695f2afca3f4954029ac4a64f82ba60ab
CVE ID: CVE-2024-47670 State: PUBLISHED Published: 2024-10-09T14:49:11.938Z Last Updated: 2025-11-03T22:20:36.160Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ocfs2: add bounds checking to ocfs2_xattr_find_entry() Add a paranoia check to make sure it doesn't stray beyond valid memory region containing ocfs2 xattr entries when scanning for a match. It will prevent out-of-bound access in case of crafted images. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b49a786beb11ff740cb9e0c20b999c2a0e1729c2 - https://git.kernel.org/stable/c/60c0d36189bad58b1a8e69
it.kernel.org/stable/c/b49a786beb11ff740cb9e0c20b999c2a0e1729c2 - https://git.kernel.org/stable/c/60c0d36189bad58b1a8e69af8781d90009559ea1 - https://git.kernel.org/stable/c/34759b7e4493d7337cbc414c132cef378c492a2c - https://git.kernel.org/stable/c/5bbe51eaf01a5dd6fb3f0dea81791e5dbc6dc6dd - https://git.kernel.org/stable/c/9b32539590a8e6400ac2f6e7cf9cbb8e08711a2f - https://git.kernel.org/stable/c/1f6e167d6753fe3ea493cdc7f7de8d03147a4d39 - https://git.kernel.org/stable/c/8e7bef408261746c160853fc27df3139659f5f77 - https://git.kernel.org/stable/c/9e3041fecdc8f78a5900c3aa51d3d756e73264d6
CVE ID: CVE-2024-47671 State: PUBLISHED Published: 2024-10-09T14:49:12.703Z Last Updated: 2025-11-03T22:20:37.607Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/fa652318887da530f2f9dbd9b0ea4a087d05ee12 - https://git.kernel.org/stable/c/16e0ab9ed3ae7d19ca8ee718ba4e09d5c0f909ca - https://git.kernel.org/stable/c/0c927dfc0b9bd177f7ab6ee59ef0c4ea06c110a7 - http
e0ab9ed3ae7d19ca8ee718ba4e09d5c0f909ca - https://git.kernel.org/stable/c/0c927dfc0b9bd177f7ab6ee59ef0c4ea06c110a7 - https://git.kernel.org/stable/c/ba6269e187aa1b1f20faf3c458831a0d6350304b - https://git.kernel.org/stable/c/51297ef7ad7824ad577337f273cd092e81a9fa08 - https://git.kernel.org/stable/c/e872738e670ddd63e19f22d0d784f0bdf26ecba5 - https://git.kernel.org/stable/c/6c7fc36da021b13c34c572a26ba336cd102418f8 - https://git.kernel.org/stable/c/625fa77151f00c1bd00d34d60d6f2e710b3f9aad
CVE ID: CVE-2024-47672 State: PUBLISHED Published: 2024-10-09T14:49:13.646Z Last Updated: 2025-11-03T22:20:39.080Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead. Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some main
tx_queues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running. [edit commit message] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ad2fcc2daa203a6ad491f00e9ae3b7867e8fe0f3 - https://git.kernel.org/stable/c/16c1e5d5228f26f120e12e6ca55c59c3a5e6dece - https://git.kernel.org/stable/c/de46b1d24f5f752b3bd8b46673c2ea4239661244 - https://git.kernel.org/stable/c/1afed66cb271b3e65fe9df1c9fba2bf4b1f55669 - https://git.kernel.org/stable/c/1b0cd832c
4 - https://git.kernel.org/stable/c/1afed66cb271b3e65fe9df1c9fba2bf4b1f55669 - https://git.kernel.org/stable/c/1b0cd832c9607f41f84053b818e0b7908510a3b9 - https://git.kernel.org/stable/c/4d0a900ec470d392476c428875dbf053f8a0ae5e - https://git.kernel.org/stable/c/7188b7a72320367554b76d8f298417b070b05dd3 - https://git.kernel.org/stable/c/3a84454f5204718ca5b4ad2c1f0bf2031e2403d1
CVE ID: CVE-2024-47673 State: PUBLISHED Published: 2024-10-09T14:49:14.315Z Last Updated: 2025-11-03T22:20:40.607Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: pause TCM when the firmware is stopped Not doing so will make us send a host command to the transport while the firmware is not alive, which will trigger a WARNING. bad state = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] Call Trace: <TASK> iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_m
cb/0x1e0 [iwlwifi] Call Trace: <TASK> iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a15df5f37fa3a8b7a8ec7a339d1e897bc524e28f - https://git.kernel.org/stable/c/5948a191906b54e10f02f6b7a7670243a39f99f4 - https://git.kernel.org/stable/c/2c61b561baf92a2860c76c2302a62169e22c21cc - https://git.kernel.org/stable/c/55
a39f99f4 - https://git.kernel.org/stable/c/2c61b561baf92a2860c76c2302a62169e22c21cc - https://git.kernel.org/stable/c/55086c97a55d781b04a2667401c75ffde190135c - https://git.kernel.org/stable/c/0668ebc8c2282ca1e7eb96092a347baefffb5fe7
CVE ID: CVE-2024-47674 State: PUBLISHED Published: 2024-10-15T10:48:33.481Z Last Updated: 2025-11-03T22:20:42.071Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, bu
to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3213fdcab961026203dd587a4
CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3213fdcab961026203dd587a4533600c70b3336b - https://git.kernel.org/stable/c/35770ca6180caa24a2b258c99a87bd437a1ee10f - https://git.kernel.org/stable/c/5b2c8b34f6d76bfbd1dd4936eb8a0fbfb9af3959 - https://git.kernel.org/stable/c/65d0db500d7c07f0f76fc24a4d837791c4862cd2 - https://git.kernel.org/stable/c/a95a24fcaee1b892e47d5e6dcc403f713874ee80 - https://git.kernel.org/stable/c/954fd4c81f22c4b6ba65379a81fd252971bf4ef3 - https://git.kernel.org/stable/c/79a61cc3fc0466ad2b7b89618a6157785f0293b3 - https://project-zero.issues.chromium.org/issues/366053091
CVE ID: CVE-2024-47675 State: PUBLISHED Published: 2024-10-21T11:53:19.762Z Last Updated: 2025-05-04T09:36:59.205Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/790c630ab0e7d7aba6d186581d46
ional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/790c630ab0e7d7aba6d186581d4627c09fce60f3 - https://git.kernel.org/stable/c/7c1d782e5afbf7c50ba74ecc4ddc18a05d63e5ee - https://git.kernel.org/stable/c/cdf27834c3dd5d9abf7eb8e4ee87ee9e307eb25c - https://git.kernel.org/stable/c/5fe6e308abaea082c20fbf2aa5df8e14495622cf
CVE ID: CVE-2024-47676 State: PUBLISHED Published: 2024-10-21T11:53:20.482Z Last Updated: 2025-05-04T09:37:01.233Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read(). Additional Analyst Notes: - CISA ADP Vulnrichment: Re
re, and then release it ourselves after hugetlb_vma_unlock_read(). Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e897d184a8dd4a4e1f39c8c495598e4d9472776c - https://git.kernel.org/stable/c/d59ebc99dee0a2687a26df94b901eb8216dbf876 - https://git.kernel.org/stable/c/98b74bb4d7e96b4da5ef3126511febe55b76b807
CVE ID: CVE-2024-47677 State: PUBLISHED Published: 2024-10-21T11:53:21.138Z Last Updated: 2025-05-04T09:37:02.575Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c
Report&x=1406c201980000 Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f9835aec49670c46ebe2973032caaa1043b3d4da - https://git.kernel.org/stable/c/331ed2c739ce656a67865f6b3ee0a478349d78cb - https://git.kernel.org/stable/c/c290fe508eee36df1640c3cb35dc8f89e073c8a8
CVE ID: CVE-2024-47678 State: PUBLISHED Published: 2024-10-21T11:53:21.814Z Last Updated: 2025-11-03T22:20:43.545Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is
wing change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/997ba8889611891f91e8ad83583466aeab6239a3 - https://git.kernel.org/stable/c/662ec52260cc
https://git.kernel.org/stable/c/997ba8889611891f91e8ad83583466aeab6239a3 - https://git.kernel.org/stable/c/662ec52260cc07b9ae53ecd3925183c29d34288b - https://git.kernel.org/stable/c/a7722921adb046e3836eb84372241f32584bdb07 - https://git.kernel.org/stable/c/483397b4ba280813e4a9c161a0a85172ddb43d19 - https://git.kernel.org/stable/c/8c2bd38b95f75f3d2a08c93e35303e26d480d24e
CVE ID: CVE-2024-47679 State: PUBLISHED Published: 2024-10-21T11:53:22.469Z Last Updated: 2025-11-03T22:20:46.317Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reaso
ode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->
// schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@goog
misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6cc13a80a26e6b48f78c725c01b91987d61563ef - https://git.kernel.org/stable/c/489faddb1ae75b0e1a741fe5ca2542a2b5e794a5 - https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195 - https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b - https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f
rg/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b - https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1 - https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb - https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1 - https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11 - https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687
CVE ID: CVE-2024-47680 State: PUBLISHED Published: 2024-10-21T11:53:23.128Z Last Updated: 2025-05-04T09:37:07.516Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential w