Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE) However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY) As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which reta
This breaks the WB_SYNC_ALL ordering requirement. Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation. References: - https://git.kernel.org/stable/c/3d61136945a7008fc90d013c3c67007ce0c96131 - https://git.kernel.org/stable/c/bce7a5c77a1e7a759e227b7713dde18c52da4759 - https://git.kernel.org/stable/c/b1511360c8ac882b0c52caa263620538e8d73220
CVE ID: CVE-2025-39780 State: PUBLISHED Published: 2025-09-11T16:56:31.142Z Last Updated: 2025-09-29T05:59:15.616Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sched/ext: Fix invalid task state transitions on class switch When enabling a sched_ext scheduler, we may trigger invalid task state transitions, resulting in warnings like the following (which can be easily reproduced by running the hotplug selftest in a loop): sched_ext: Invalid task state transition 0 -> 3 for fish[770] WARNING: CPU: 18 PID: 787 at kernel/sched/ext.c:3862 scx_set_task_state+0x7c/0xc0 ... RIP: 0010:scx_set_task_state+0x7c/0xc0 ... Call Trace: <TASK>
kernel/sched/ext.c:3862 scx_set_task_state+0x7c/0xc0 ... RIP: 0010:scx_set_task_state+0x7c/0xc0 ... Call Trace: <TASK> scx_enable_task+0x11f/0x2e0 switching_to_scx+0x24/0x110 scx_enable.isra.0+0xd14/0x13d0 bpf_struct_ops_link_create+0x136/0x1a0 __sys_bpf+0x1edd/0x2c30 __x64_sys_bpf+0x21/0x30 do_syscall_64+0xbb/0x370 entry_SYSCALL_64_after_hwframe+0x77/0x7f This happens because we skip initialization for tasks that are already dead (with their usage counter set to zero), but we don't exclude them during the scheduling class transition phase. Fix this by also skipping dead tasks during class swiching, preventing invalid task state transitions. References: - https://git.kernel.org/stable/c/786
asks during class swiching, preventing invalid task state transitions. References: - https://git.kernel.org/stable/c/786f6314604b34c3e7de5f733f4e08e35c448a50 - https://git.kernel.org/stable/c/6a32cbe95029ebe21cc08349fd7ef2a3d32d2043 - https://git.kernel.org/stable/c/ddf7233fcab6c247379d0928d46cc316ee122229
CVE ID: CVE-2025-39781 State: PUBLISHED Published: 2025-09-11T16:56:31.909Z Last Updated: 2025-09-29T05:59:16.894Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: parisc: Drop WARN_ON_ONCE() from flush_cache_vmap I have observed warning to occassionally trigger. References: - https://git.kernel.org/stable/c/69cf90e5aa50fe3cb0c1a63cabc4761db44b0035 - https://git.kernel.org/stable/c/8f8a07ad04da5b3c90fab61c33d4a8256a680591 - https://git.kernel.org/stable/c/4afb1352b85d7deb777694fba16d13c30c08776f - https://git.kernel.org/stable/c/4eab1c27ce1f0e89ab67b01bf1e4e4c75215708a
CVE ID: CVE-2025-39782 State: PUBLISHED Published: 2025-09-11T16:56:32.616Z Last Updated: 2025-11-03T17:43:17.511Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jbd2: prevent softlockup in jbd2_log_do_checkpoint() Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list() periodically release j_list_lock after processing a batch of buffers to avoid long hold times on the j_list_lock. However, since both functions contend for j_list_lock, the combined time spent waiting and processing can be significant. jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softl
ficant. jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() when need_resched() is true to avoid softlockups during prolonged operations. But jbd2_log_do_checkpoint() only exits its loop when need_resched() is true, relying on potentially sleeping functions like __flush_batch() or wait_on_buffer() to trigger rescheduling. If those functions do not sleep, the kernel may hit a softlockup. watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373] CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10 Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UA
han 2280 /BC11SPCD, BIOS 1.27 06/13/2017 Workqueue: writeback wb_workfn (flush-7:2) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : native_queued_spin_lock_slowpath+0x358/0x418 lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inode
[ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20 So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoid softlockup. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/f683d611518d30334813eecf9a8c687453e2800e - https://git.kernel.org/stable/c/f7ee8fd689e6d534f9fd2494b9266f7998082e65 - https://git.kernel.org/stable/c/84ff98c1ea19acd3f9389e4bb6061364
org/stable/c/f7ee8fd689e6d534f9fd2494b9266f7998082e65 - https://git.kernel.org/stable/c/84ff98c1ea19acd3f9389e4bb6061364e943f85e - https://git.kernel.org/stable/c/26cb9aad94cb1811d8fae115594cc71fa3d91ab0 - https://git.kernel.org/stable/c/41f40038de62e8306897cf6840791b268996432a - https://git.kernel.org/stable/c/429d50cbaff45090d52a1ea850d5de8c14881ee7 - https://git.kernel.org/stable/c/3faac5e1d14c63260fd1bf789d96bde3ab3d9e54 - https://git.kernel.org/stable/c/9d98cf4632258720f18265a058e62fde120c0151
CVE ID: CVE-2025-39783 State: PUBLISHED Published: 2025-09-11T16:56:33.376Z Last Updated: 2025-11-03T17:43:19.404Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix configfs group list head handling Doing a list_del() on the epf_group field of struct pci_epf_driver in pci_epf_remove_cfs() is not correct as this field is a list head, not a list entry. This list_del() call triggers a KASAN warning when an endpoint function driver which has a configfs attribute group is torn down: ================================================================== BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198 Wri
================================================== BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198 Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319 CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONE Hardware name: Radxa ROCK 5B (DT) Call trace: show_stack+0x2c/0x84 (C) dump_stack_lvl+0x70/0x98 print_report+0x17c/0x538 kasan_report+0xb8/0x190 __asan_report_store8_noabort+0x20/0x2c pci_epf_remove_cfs+0x17c/0x198 pci_epf_unregister_driver+0x18/0x30 nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf] __arm64_sys_delete_module+0x264/0x424 invoke_syscall+0x70/0x260 el0_svc_common.constprop.0+0xac/0x230 do_el0_svc+0x40/0x58 el0_svc+0x48/0xdc el0t_64_syn
0x424 invoke_syscall+0x70/0x260 el0_svc_common.constprop.0+0xac/0x230 do_el0_svc+0x40/0x58 el0_svc+0x48/0xdc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ... Remove this incorrect list_del() call from pci_epf_remove_cfs(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/80ea6e6904fb2ba4ccb5d909579988466ec65358 - https://git.kernel.org/stable/c/d5aecddc3452371d9da82cdbb0c715812524b54b - https://git.kernel.org/stable/c/dc4ffbd571716ff3b171418fb03abe80e720a7b1 - https://git.kernel.org/stable/c/409af8b9f7b4f23cd0464e71c6cd6fe13c076ae2 - https://git.kernel.org/stable/c/0758862386f114d9ab1e23181461bd1e2e9ec4c6 - https://git.kernel.org/s
71c6cd6fe13c076ae2 - https://git.kernel.org/stable/c/0758862386f114d9ab1e23181461bd1e2e9ec4c6 - https://git.kernel.org/stable/c/6cf65505523224cab1449d726d2ce8180c2941ee - https://git.kernel.org/stable/c/a302bd89db35d8b7e279de4d2b41c16c7f191069 - https://git.kernel.org/stable/c/d79123d79a8154b4318529b7b2ff7e15806f480b
CVE ID: CVE-2025-39784 State: PUBLISHED Published: 2025-09-11T16:56:34.097Z Last Updated: 2025-09-29T05:59:20.668Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: Fix link speed calculation on retrain failure When pcie_failed_link_retrain() fails to retrain, it tries to revert to the previous link speed. However it calculates that speed from the Link Control 2 register without masking out non-speed bits first. PCIE_LNKCTL2_TLS2SPEED() converts such incorrect values to PCI_SPEED_UNKNOWN (0xff), which in turn causes a WARN splat in pcie_set_target_speed(): pci 0000:00:01.1: [1022:14ed] type 01 class 0x060400 PCIe Root Port pc
n causes a WARN splat in pcie_set_target_speed(): pci 0000:00:01.1: [1022:14ed] type 01 class 0x060400 PCIe Root Port pci 0000:00:01.1: broken device, retraining non-functional downstream link at 2.5GT/s pci 0000:00:01.1: retraining failed WARNING: CPU: 1 PID: 1 at drivers/pci/pcie/bwctrl.c:168 pcie_set_target_speed RDX: 0000000000000001 RSI: 00000000000000ff RDI: ffff9acd82efa000 pcie_failed_link_retrain pci_device_add pci_scan_single_device Mask out the non-speed bits in PCIE_LNKCTL2_TLS2SPEED() and PCIE_LNKCAP_SLS2SPEED() so they don't incorrectly return PCI_SPEED_UNKNOWN. [bhelgaas: commit log, add details from https://lore.kernel.org/r/1c92ef6bcb314ee6977839b46b393282e4f52e74.1750684771
N. [bhelgaas: commit log, add details from https://lore.kernel.org/r/1c92ef6bcb314ee6977839b46b393282e4f52e74.1750684771.git.lukas@wunner.de] References: - https://git.kernel.org/stable/c/16557320f378262b5c605b15edebd3642406992a - https://git.kernel.org/stable/c/9989e0ca7462c62f93dbc62f684448aa2efb9226
CVE ID: CVE-2025-39785 State: PUBLISHED Published: 2025-09-11T16:56:34.955Z Last Updated: 2025-09-29T05:59:21.919Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/hisilicon/hibmc: fix irq_request()'s irq name variable is local The local variable is passed in request_irq (), and there will be use after free problem, which will make request_irq failed. Using the global irq name instead of it to fix. References: - https://git.kernel.org/stable/c/06d261a085a11600f5b577bb56a65fb2c3e57d0a - https://git.kernel.org/stable/c/8bed4ec42a4e0dc8113172696ff076d1eb6d8bcb
CVE ID: CVE-2025-39786 State: PUBLISHED Published: 2025-09-11T16:56:35.706Z Last Updated: 2025-09-29T05:59:23.280Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7173: fix channels index for syscalib_mode Fix the index used to look up the channel when accessing the syscalib_mode attribute. The address field is a 0-based index (same as scan_index) that it used to access the channel in the ad7173_channels array throughout the driver. The channels field, on the other hand, may not match the address field depending on the channel configuration specified in the device tree and could result in an out-of-bounds access. Ref
eld depending on the channel configuration specified in the device tree and could result in an out-of-bounds access. References: - https://git.kernel.org/stable/c/2def1a8691eb43654da0ae0d2fdb3722e20262a5 - https://git.kernel.org/stable/c/0eb8d7b25397330beab8ee62c681975b79f37223
CVE ID: CVE-2025-39787 State: PUBLISHED Published: 2025-09-11T16:56:36.426Z Last Updated: 2025-11-03T17:43:21.316Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: soc: qcom: mdt_loader: Ensure we don't read past the ELF header When the MDT loader is used in remoteproc, the ELF header is sanitized beforehand, but that's not necessary the case for other clients. Validate the size of the firmware buffer to ensure that we don't read past the end as we iterate over the header. e_phentsize and e_shentsize are validated as well, to ensure that the assumptions about step size in the traversal are valid. Additional Analyst Notes: - CVE P
ed as well, to ensure that the assumptions about step size in the traversal are valid. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/1096eb63ecfc8df90b70cd068e6de0c2ff204dfd - https://git.kernel.org/stable/c/e1720eb32acf411c328af6a8c8f556c94535808e - https://git.kernel.org/stable/c/0d59ce2bfc3bb13abe6240335a1bf7b96536d022 - https://git.kernel.org/stable/c/43d26997d88c4056fce0324e72f62556bc7e8e8d - https://git.kernel.org/stable/c/981c845f29838e468a9bfa87f784307193a31297 - https://git.kernel.org/stable/c/87bfabb3b2f46827639173f143aa43f7cfc0a7e6 - https://git.kernel.org/stable/c/81278be4eb5f08ba2c68c3055893e61cc03727fe - https://git.kernel.org/
3f143aa43f7cfc0a7e6 - https://git.kernel.org/stable/c/81278be4eb5f08ba2c68c3055893e61cc03727fe - https://git.kernel.org/stable/c/9f9967fed9d066ed3dae9372b45ffa4f6fccfeef
CVE ID: CVE-2025-39788 State: PUBLISHED Published: 2025-09-11T16:56:37.173Z Last Updated: 2025-11-03T17:43:23.201Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPE On Google gs101, the number of UTP transfer request slots (nutrs) is 32, and in this case the driver ends up programming the UTRL_NEXUS_TYPE incorrectly as 0. This is because the left hand side of the shift is 1, which is of type int, i.e. 31 bits wide. Shifting by more than that width results in undefined behaviour. Fix this by switching to the BIT() macro, which applies correct type casting as required. This e
in undefined behaviour. Fix this by switching to the BIT() macro, which applies correct type casting as required. This ensures the correct value is written to UTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shift warning: UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21 shift exponent 32 is too large for 32-bit type 'int' For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPE write. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/01510a9e8222f11cce064410f3c2fcf0756c0a08 - https://git.kernel.org/stable/c/098b2c8ee208c77126839047b9e6e1925bb35baa - https://git.kernel.org/stable/c/c1f025da8f370a
ttps://git.kernel.org/stable/c/098b2c8ee208c77126839047b9e6e1925bb35baa - https://git.kernel.org/stable/c/c1f025da8f370a015e412b55cbcc583f91de8316 - https://git.kernel.org/stable/c/6d53b2a134da77eb7fe65c5c7c7a3c193539a78a - https://git.kernel.org/stable/c/dc8fb963742f1a38d284946638f9358bdaa0ddee - https://git.kernel.org/stable/c/5b9f1ef293428ea9c0871d96fcec2a87c4445832 - https://git.kernel.org/stable/c/01aad16c2257ab8ff33b152b972c9f2e1af47912
CVE ID: CVE-2025-39789 State: PUBLISHED Published: 2025-09-11T16:56:37.912Z Last Updated: 2025-09-29T05:59:27.248Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: x86/aegis - Add missing error checks The skcipher_walk functions can allocate memory and can fail, so checking for errors is necessary. References: - https://git.kernel.org/stable/c/475104178f4d30e749ee4f5473c87f692b93bebb - https://git.kernel.org/stable/c/3d9eb180fbe8828cce43bce4c370124685b205c3
CVE ID: CVE-2025-39790 State: PUBLISHED Published: 2025-09-11T16:56:38.643Z Last Updated: 2025-11-03T17:43:24.145Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Detect events pointing to unexpected TREs When a remote device sends a completion event to the host, it contains a pointer to the consumed TRE. The host uses this pointer to process all of the TREs between it and the host's local copy of the ring's read pointer. This works when processing completion for chained transactions, but can lead to nasty results if the device sends an event for a single-element transaction with a read pointer that is multiple e
ad to nasty results if the device sends an event for a single-element transaction with a read pointer that is multiple elements ahead of the host's read pointer. For instance, if the host accesses an event ring while the device is updating it, the pointer inside of the event might still point to an old TRE. If the host uses the channel's xfer_cb() to directly free the buffer pointed to by the TRE, the buffer will be double-freed. This behavior was observed on an ep that used upstream EP stack without 'commit 6f18d174b73d ("bus: mhi: ep: Update read pointer only after buffer is written")'. Where the device updated the events ring pointer before updating the event contents, so it left a window
is written")'. Where the device updated the events ring pointer before updating the event contents, so it left a window where the host was able to access the stale data the event pointed to, before the device had the chance to update them. The usual pattern was that the host received an event pointing to a TRE that is not immediately after the last processed one, so it got treated as if it was a chained transaction, processing all of the TREs in between the two read pointers. This commit aims to harden the host by ensuring transactions where the event points to a TRE that isn't local_rp + 1 are chained. [mani: added stable tag and reworded commit message] Additional Analyst Notes: - CVE Pro
isn't local_rp + 1 are chained. [mani: added stable tag and reworded commit message] Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7b3f0e3b60c27f4fcb69927d84987e5fd6240530 - https://git.kernel.org/stable/c/4079c6c59705b96285219b9efc63cab870d757b7 - https://git.kernel.org/stable/c/5e17429679a8545afe438ce7a82a13a54e8ceabb - https://git.kernel.org/stable/c/2ec99b922f4661521927eeada76f431eebfbabc4 - https://git.kernel.org/stable/c/44e1a079e18f78d6594a715b0c6d7e18c656f7b9 - https://git.kernel.org/stable/c/5bd398e20f0833ae8a1267d4f343591a2dd20185
CVE ID: CVE-2025-39791 State: PUBLISHED Published: 2025-09-11T16:56:39.397Z Last Updated: 2025-09-29T05:59:29.884Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm: dm-crypt: Do not partially accept write BIOs with zoned targets Read and write operations issued to a dm-crypt target may be split according to the dm-crypt internal limits defined by the max_read_size and max_write_size module parameters (default is 128 KB). The intent is to improve processing time of large BIOs by splitting them into smaller operations that can be parallelized on different CPUs. For zoned dm-crypt targets, this BIO splitting is still done but wit
rations that can be parallelized on different CPUs. For zoned dm-crypt targets, this BIO splitting is still done but without the parallel execution to ensure that the issuing order of write operations to the underlying devices remains sequential. However, the splitting itself causes other problems: 1) Since dm-crypt relies on the block layer zone write plugging to handle zone append emulation using regular write operations, the reminder of a split write BIO will always be plugged into the target zone write plugged. Once the on-going write BIO finishes, this reminder BIO is unplugged and issued from the zone write plug work. If this reminder BIO itself needs to be split, the reminder will be
unplugged and issued from the zone write plug work. If this reminder BIO itself needs to be split, the reminder will be re-issued and plugged again, but that causes a call to a blk_queue_enter(), which may block if a queue freeze operation was initiated. This results in a deadlock as DM submission still holds BIOs that the queue freeze side is waiting for. 2) dm-crypt relies on the emulation done by the block layer using regular write operations for processing zone append operations. This still requires to properly return the written sector as the BIO sector of the original BIO. However, this can be done correctly only and only if there is a single clone BIO used for processing the original
BIO. However, this can be done correctly only and only if there is a single clone BIO used for processing the original zone append operation issued by the user. If the size of a zone append operation is larger than dm-crypt max_write_size, then the orginal BIO will be split and processed as a chain of regular write operations. Such chaining result in an incorrect written sector being returned to the zone append issuer using the original BIO sector. This in turn results in file system data corruptions using xfs or btrfs. Fix this by modifying get_max_request_size() to always return the size of the BIO to avoid it being split with dm_accpet_partial_bio() in crypt_map(). get_max_request_size()
s return the size of the BIO to avoid it being split with dm_accpet_partial_bio() in crypt_map(). get_max_request_size() is renamed to get_max_request_sectors() to clarify the unit of the value returned and its interface is changed to take a struct dm_target pointer and a pointer to the struct bio being processed. In addition to this change, to ensure that crypt_alloc_buffer() works correctly, set the dm-crypt device max_hw_sectors limit to be at most BIO_MAX_VECS << PAGE_SECTORS_SHIFT (1 MB with a 4KB page architecture). This forces DM core to split write BIOs before passing them to crypt_map(), and thus guaranteeing that dm-crypt can always accept an entire write BIO without needing to spl
ng them to crypt_map(), and thus guaranteeing that dm-crypt can always accept an entire write BIO without needing to split it. This change does not have any effect on the read path of dm-crypt. Read operations can still be split and the BIO fragments processed in parallel. There is also no impact on the performance of the write path given that all zone write BIOs were already processed inline instead of in parallel. This change also does not affect in any way regular dm-crypt block devices. References: - https://git.kernel.org/stable/c/8864616719b6bbf92356bc89ff544b0cd484c656 - https://git.kernel.org/stable/c/52a2c4c60470352acf9cde7a2dfa661c1e67e796 - https://git.kernel.org/stable/c/e5496638
56 - https://git.kernel.org/stable/c/52a2c4c60470352acf9cde7a2dfa661c1e67e796 - https://git.kernel.org/stable/c/e549663849e5bb3b985dc2d293069f0d9747ae72
CVE ID: CVE-2025-39792 State: PUBLISHED Published: 2025-09-12T15:59:29.477Z Last Updated: 2025-09-29T05:59:31.150Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm: Always split write BIOs to zoned device limits Any zoned DM target that requires zone append emulation will use the block layer zone write plugging. In such case, DM target drivers must not split BIOs using dm_accept_partial_bio() as doing so can potentially lead to deadlocks with queue freeze operations. Regular write operations used to emulate zone append operations also cannot be split by the target driver as that would result in an invalid writen sector value r