Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2025-39734 State: PUBLISHED Published: 2025-09-07T15:16:22.015Z Last Updated: 2025-11-03T17:42:50.659Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "fs/ntfs3: Replace inode_trylock with inode_lock" This reverts commit 69505fe98f198ee813898cbcaf6770949636430b. Initially, conditional lock acquisition was removed to fix an xfstest bug that was observed during internal testing. The deadlock reported by syzbot is resolved by reintroducing conditional acquisition. The xfstest bug no longer occurs on kernel version 6.16-rc1 during internal testing. I assume that changes in other modules may have contributed to thi
s on kernel version 6.16-rc1 during internal testing. I assume that changes in other modules may have contributed to this. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/bec8109f957a6e193e52d1728799994c8005ca83 - https://git.kernel.org/stable/c/1903a6c1f2818154f6bc87bceaaecafa92b6ac5c - https://git.kernel.org/stable/c/a936be9b5f51c4d23f66fb673e9068c6b08104a4 - https://git.kernel.org/stable/c/b356ee013a79e7e3147bfe065de376706c5d2ee9 - https://git.kernel.org/stable/c/7ce6f83ca9d52c9245b7a017466fc4baa1241b0b - https://git.kernel.org/stable/c/bd20733746263acaaf2a21881665db27ee4303d5 - https://git.kernel.org/stable/c/a49f0abd8959048af18c6c690b065e
l.org/stable/c/bd20733746263acaaf2a21881665db27ee4303d5 - https://git.kernel.org/stable/c/a49f0abd8959048af18c6c690b065eb0d65b2d21
CVE ID: CVE-2025-39735 State: PUBLISHED Published: 2025-04-18T07:01:36.453Z Last Updated: 2025-11-03T19:58:46.112Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds read in ea_get() During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump(). Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped: int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); Although clamp_t aims to bound ea_size betwee
clamped: int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr)); Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328). The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iterat
he for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration: for (i = 0; i < len; i += rowsize) { linelen = min(remaining, rowsize); remaining -= rowsize; hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize, linebuf, sizeof(linebuf), ascii); ... } The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop: for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto
ess is done in hex_dump_to_buffer() in the following for loop: for (j = 0; j < len; j++) { if (linebuflen < lx + 2) goto overflow2; ch = ptr[j]; ... } To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3d6fd5b9c6acbc005e53d0211c7381f566babec1 - https://git.kernel.org/stable/c/50afcee7011155933d8d5e8832f52eeee018cfd3 - https://git.kernel.org/stable/c/78c9cbde8880ec02d864c166bcb4fe989ce1d95f - https://git.kernel.org/stable/c/46e2c031aa59ea65128991cbca474bd5c0c2ecdb - https://git.kernel.org/stable/c/a8c31808925b11393a6601f534bb63bac5366bab - h
/46e2c031aa59ea65128991cbca474bd5c0c2ecdb - https://git.kernel.org/stable/c/a8c31808925b11393a6601f534bb63bac5366bab - https://git.kernel.org/stable/c/0beddc2a3f9b9cf7d8887973041e36c2d0fa3652 - https://git.kernel.org/stable/c/16d3d36436492aa248b2d8045e75585ebcc2f34d - https://git.kernel.org/stable/c/5263822558a8a7c0d0248d5679c2dcf4d5cda61f - https://git.kernel.org/stable/c/fdf480da5837c23b146c4743c18de97202fcab37
CVE ID: CVE-2025-39736 State: PUBLISHED Published: 2025-09-11T16:52:11.772Z Last Updated: 2025-11-03T17:42:52.536Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lock When netpoll is enabled, calling pr_warn_once() while holding kmemleak_lock in mem_pool_alloc() can cause a deadlock due to lock inversion with the netconsole subsystem. This occurs because pr_warn_once() may trigger netpoll, which eventually leads to __alloc_skb() and back into kmemleak code, attempting to reacquire kmemleak_lock. This is the path for the deadlock. mem_pool_alloc() -> raw_spin_lock_
mleak code, attempting to reacquire kmemleak_lock. This is the path for the deadlock. mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags); Fix this by setting a flag and issuing the pr_warn_once() after kmemleak_lock is released. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c7b6ea0ede687e7460e593c5ea478f50aa41682a - https://git.kernel.org/stable/c/4b0151e1d468eb2667c37b7af99b3c075072d334 - https://git.kernel.org/stable/c/f249d32bb54876b4b6c3ae071af8ddca77af390b - https://git.kernel.org/stable/c
c075072d334 - https://git.kernel.org/stable/c/f249d32bb54876b4b6c3ae071af8ddca77af390b - https://git.kernel.org/stable/c/62879faa8efe8d8a9c7bf7606ee9c068012d7dac - https://git.kernel.org/stable/c/1da95d3d4b7b1d380ebd87b71a61e7e6aed3265d - https://git.kernel.org/stable/c/a0854de00ce2ee27edf39037e7836ad580eb3350 - https://git.kernel.org/stable/c/08f70be5e406ce47c822f2dd11c1170ca259605b - https://git.kernel.org/stable/c/a181b228b37a6a5625dad2bb4265bb7abb673e9f - https://git.kernel.org/stable/c/47b0f6d8f0d2be4d311a49e13d2fd5f152f492b2
CVE ID: CVE-2025-39737 State: PUBLISHED Published: 2025-09-11T16:52:12.519Z Last Updated: 2025-11-03T17:42:54.439Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup() A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134] The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its C
hen kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000. The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects. As kmemleak has been disabled in this case, the object removal and deletion process can be further opti
l these objects. As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9f1f4e95031f84867c5821540466d62f88dab8ca - https://git.kernel.org/stable/c/1ef72a7fedc5bca70e8cc980985790de10d407aa - https://git.kernel.org/stable/c/a04de4c40aab9b338dfa989cf4aec70fd187eeb2 - https://git.kernel.org/stable/c/
de10d407aa - https://git.kernel.org/stable/c/a04de4c40aab9b338dfa989cf4aec70fd187eeb2 - https://git.kernel.org/stable/c/f014c10d190b92aad366e56b445daffcd1c075e4 - https://git.kernel.org/stable/c/e21a3ddd58733ce31afcb1e5dc3cb80a4b5bc29b - https://git.kernel.org/stable/c/8d2d22a55ffe35c38e69795468a7addd1a80e9ce - https://git.kernel.org/stable/c/926092268efdf1ed7b55cf486356c74a9e7710d1 - https://git.kernel.org/stable/c/9b80430c194e4a114dc663c1025d56b4f3d0153d - https://git.kernel.org/stable/c/d1534ae23c2b6be350c8ab060803fbf6e9682adc
CVE ID: CVE-2025-39738 State: PUBLISHED Published: 2025-09-11T16:52:13.228Z Last Updated: 2025-11-03T17:42:55.377Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: do not allow relocation of partially dropped subvolumes [BUG] There is an internal report that balance triggered transaction abort, with the following call trace: item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0: tree block backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for i
t refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -117) WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs] And btrfs check doesn't report anything wrong related to the extent tree. [CAUSE] The cause is a little complex, firstly the extent tree indeed doesn't have the backref for 594526208.
tent tree. [CAUSE] The cause is a little complex, firstly the extent tree indeed doesn't have the backref for 594526208. The extent tree only have the following two backrefs around that bytenr on-disk: item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33 refs 1 gen 197740 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33 refs 1 gen 197522 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE But the such missing backref item is not an corruption on disk, as the offending delayed ref belongs to subvolume 934, and that subvolume is being dropped:
not an corruption on disk, as the offending delayed ref belongs to subvolume 934, and that subvolume is being dropped: item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439 generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328 last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0 drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2 level 2 generation_v2 198229 And that offending tree block 594526208 is inside the dropped range of that subvolume. That explains why there is no backref item for that bytenr and why btrfs check is not reporting anything wrong. But this also shows another problem, as btrfs will do all the orphan subvolume clean
ck is not reporting anything wrong. But this also shows another problem, as btrfs will do all the orphan subvolume cleanup at a read-write mount. So half-dropped subvolume should not exist after an RW mount, and balance itself is also exclusive to subvolume cleanup, meaning we shouldn't hit a subvolume half-dropped during relocation. The root cause is, there is no orphan item for this subvolume. In fact there are 5 subvolumes from around 2021 that have the same problem. It looks like the original report has some older kernels running, and caused those zombie subvolumes. Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshot deletion not triggered on mount") has long fixed th
nkfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshot deletion not triggered on mount") has long fixed the bug. [ENHANCEMENT] For repairing such old fs, btrfs-progs will be enhanced. Considering how delayed the problem will show up (at run delayed ref time) and at that time we have to abort transaction already, it is too late. Instead here we reject any half-dropped subvolume for reloc tree at the earliest time, preventing confusion and extra time wasted on debugging similar bugs. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/fa086b1398cf7e5f7dee7241bd5f2855cb5df8dc - https://git.kernel.org/stable/c/fcb1f77b8ed8795608ca7a1f650
rnel.org/stable/c/fa086b1398cf7e5f7dee7241bd5f2855cb5df8dc - https://git.kernel.org/stable/c/fcb1f77b8ed8795608ca7a1f6505e2b07236c1f3 - https://git.kernel.org/stable/c/f83d4c81bda3b7d1813268ab77408f7a0ce691ff - https://git.kernel.org/stable/c/39a93e1c9dbf7e11632efeb20fcf0fc1dcf64d51 - https://git.kernel.org/stable/c/125e94a4b76b7b75d194f85bedd628097d2121f0 - https://git.kernel.org/stable/c/4e403bd8e127d40dc7c05f06ee969c1ba1537ec5 - https://git.kernel.org/stable/c/4289b494ac553e74e86fed1c66b2bf9530bc1082
CVE ID: CVE-2025-39739 State: PUBLISHED Published: 2025-09-11T16:52:13.954Z Last Updated: 2025-09-29T05:58:25.752Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-qcom: Add SM6115 MDSS compatible Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot: arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iomm
.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed) ------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules
--- !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0
_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bu
a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_
0c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22 References: - https://git.kernel.org/stable/c/a11b6ee7cab87c4d75e95ac9e7443155f7cecb55 - https://git.kernel.org/stable/c
References: - https://git.kernel.org/stable/c/a11b6ee7cab87c4d75e95ac9e7443155f7cecb55 - https://git.kernel.org/stable/c/c62963370627f3aa22d991e0a3e93f5d61ad9b08 - https://git.kernel.org/stable/c/3d470cf40c9265092eb33c3d3d9dc8bad452bcc2 - https://git.kernel.org/stable/c/e52bbaa209ebff3bf7a10c17ba7d3e1d3cb0fe61 - https://git.kernel.org/stable/c/f7fa8520f30373ce99c436c4d57c76befdacbef3
CVE ID: CVE-2025-39740 State: PUBLISHED Published: 2025-09-11T16:52:14.638Z Last Updated: 2025-09-29T05:58:27.031Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe/migrate: prevent potential UAF If we hit the error path, the previous fence (if there is one) has already been put() prior to this, so doing a fence_wait could lead to UAF. Tweak the flow to do to the put() until after we do the wait. (cherry picked from commit 9b7ca35ed28fe5fad86e9d9c24ebd1271e4c9c3e) References: - https://git.kernel.org/stable/c/7e46fa64a4b94208563c3a5bf1d7f4346f94abea - https://git.kernel.org/stable/c/145832fbdd17b1d77ffd6cdd1642259e101d1b7e
CVE ID: CVE-2025-39741 State: PUBLISHED Published: 2025-09-11T16:52:15.353Z Last Updated: 2025-09-29T05:58:28.311Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe/migrate: don't overflow max copy size With non-page aligned copy, we need to use 4 byte aligned pitch, however the size itself might still be close to our maximum of ~8M, and so the dimensions of the copy can easily exceed the S16_MAX limit of the copy command leading to the following assert: xe 0000:03:00.0: [drm] Assertion `size / pitch <= ((s16)(((u16)~0U) >> 1))` failed! platform: BATTLEMAGE subplatform: 1 graphics: Xe2_HPG 20.01 step A0 media: Xe2_HPM 13.01
s16)(((u16)~0U) >> 1))` failed! platform: BATTLEMAGE subplatform: 1 graphics: Xe2_HPG 20.01 step A0 media: Xe2_HPM 13.01 step A1 tile: 0 VRAM 10.0 GiB GT: 0 type 1 WARNING: CPU: 23 PID: 10605 at drivers/gpu/drm/xe/xe_migrate.c:673 emit_copy+0x4b5/0x4e0 [xe] To fix this account for the pitch when calculating the number of current bytes to copy. (cherry picked from commit 8c2d61e0e916e077fda7e7b8e67f25ffe0f361fc) References: - https://git.kernel.org/stable/c/7257cc6644d540130a46a61531a07a0517cace89 - https://git.kernel.org/stable/c/4126cb327a2e3273c81fcef1c594c5b7b645c44c
CVE ID: CVE-2025-39742 State: PUBLISHED Published: 2025-09-11T16:52:16.339Z Last Updated: 2025-11-03T17:42:57.252Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask() The function divides number of online CPUs by num_core_siblings, and later checks the divider by zero. This implies a possibility to get and divide-by-zero runtime error. Fix it by moving the check prior to division. This also helps to save one indentation level. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9bba1a9994c523b44db64f63b564b4719ea2b7ef - http
: - CVE Program Container: References: - https://git.kernel.org/stable/c/9bba1a9994c523b44db64f63b564b4719ea2b7ef - https://git.kernel.org/stable/c/1a7cf828ed861de5be1aff99e10f114b363c19d3 - https://git.kernel.org/stable/c/9d3211cb61a0773a2440d0a0698c1e6e7429f907 - https://git.kernel.org/stable/c/4b4317b0d758ff92ba96f4e448a8992a6fe607bf - https://git.kernel.org/stable/c/89fdac333a17ed990b41565630ef4791782e02f5 - https://git.kernel.org/stable/c/9b05e91afe948ed819bf87d7ba0fccf451ed79a6 - https://git.kernel.org/stable/c/31d0599a23efdbfe579bfbd1eb8f8c942f13744d - https://git.kernel.org/stable/c/ac53f377393cc85156afdc90b636e84e544a6f96 - https://git.kernel.org/stable/c/59f7d2138591ef8f0e4e4ab5f1a
rnel.org/stable/c/ac53f377393cc85156afdc90b636e84e544a6f96 - https://git.kernel.org/stable/c/59f7d2138591ef8f0e4e4ab5f1ab674e8181ad3a
CVE ID: CVE-2025-39743 State: PUBLISHED Published: 2025-09-11T16:52:17.043Z Last Updated: 2025-11-03T17:42:59.121Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: jfs: truncate good inode pages when hard link is 0 The fileset value of the inode copy from the disk by the reproducer is AGGR_RESERVED_I. When executing evict, its hard link number is 0, so its inode pages are not truncated. This causes the bugon to be triggered when executing clear_inode() because nrpages is greater than 0. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/89fff8e3d6710fc32507b8e19eb5afa9fb79b896 - https
- CVE Program Container: References: - https://git.kernel.org/stable/c/89fff8e3d6710fc32507b8e19eb5afa9fb79b896 - https://git.kernel.org/stable/c/5845b926c561b8333cd65169526eec357d7bb449 - https://git.kernel.org/stable/c/8ed7275910fb7177012619864e04d3008763f3ea - https://git.kernel.org/stable/c/b5b471820c33365a8ccd2d463578bf4e47056c2c - https://git.kernel.org/stable/c/34d8e982bac48bdcca7524644a8825a580edce74 - https://git.kernel.org/stable/c/df3fd8daf278eca365f221749ae5b728e8382a04 - https://git.kernel.org/stable/c/2b1d5ca395a5fb170c3f885cd42c16179f7f54ec - https://git.kernel.org/stable/c/1bb5cdc3e39f0c2b311fcb631258b7e60d3fb0d3 - https://git.kernel.org/stable/c/2d91b3765cd05016335cd5df5e5c
nel.org/stable/c/1bb5cdc3e39f0c2b311fcb631258b7e60d3fb0d3 - https://git.kernel.org/stable/c/2d91b3765cd05016335cd5df5e5c6a29708ec058
CVE ID: CVE-2025-39744 State: PUBLISHED Published: 2025-09-11T16:52:17.725Z Last Updated: 2025-09-29T05:58:32.153Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rcu: Fix rcu_read_unlock() deadloop due to IRQ work During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up. This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly. irq_exit() __irq_exit_rcu() /* in_hardirq() return